上个月，有个以前的同事问我：“你在的时候，为什么不把原来的系统都重做了，我们明明有实力啊”。
我说：“我们也做了很多事情嘛，系统稳定性、安全性、增加冗余、理清各模块职责、API通讯机制的建立、内部分层的整理。”
他说：“对，但我还是想知道，你为什么不把系统重做了呢？”
于是我问：“我离职之后，后来似乎多投了不少人重做系统？结果怎么样呢？”
他说：“结果，结果就是做业务要同时操作三四套系统……”
就我所见，把原有系统“推倒重来”的喜好不只程序员有，使用者更有。拿我几年前的那份工作来说，刚入职老大们就来跟我讨论系统重做的打算：需要多少人，多少钱，多长时间，能把原有系统推翻重来。毕竟大家每天都忍受切肤之痛：速度慢、经常出错、不安全、客户抱怨、架构糟糕…… 所以都想拿出“敢叫日月换新天”的劲头，来个干脆的彻底解决。
这种心情可以理解，但在我任内“重做系统”一直没有被提上日程，整个技术团队所做的都是“改良”的工作，内容就像我上面说的：系统稳定性、安全性、增加冗余、理清各模块职责、API通讯机制的建立、内部分层的整理。这个选择我有充分把握，而且在我看来，如果断然“推倒重来”，我未必能比继任者做得更好，甚至可能更糟糕，因为“推倒重来”绝不是那么简单的事情。
众所周知，软件开发的难点之一就是控制复杂度。但是在不同的领域，复杂度有不同的表现。对于纯互联网业务，或者IT基础架构来说，其复杂度在于软件本身，架构的制定、类库的选择、编码的质量等等。对于其它IT系统——尤其是公司迅速成长，业务不断复杂化的IT系统——而言，其复杂度并不在于软件本身，安全、性能、负载的问题都套用现成的IT解决方案，真正的复杂度来自系统承载的业务本身，比如最简单的：系统里有哪些单据，各种单据承载什么信息，用在什么场景，这些单据是怎样流转的，各种单据存在怎样的约束关系，出现异常情况应当如何处理才能保证业务数据的一致性……这些问题没有准确而稳定的答案，IT再怎样努力也是白搭。
对于已经能在线下规范运行的业务，或者是有经典解决方案的工作（比如财务、仓库管理），这些知识都是现成的，可以直接拿来用。但对于新兴领域、新兴业务来说，往往不存在“经典解决方案”。加上很多公司成长速度飞快，一开始并没有构筑好的IT基础（其实是业务架构基础）。典型的情况就是：业务概念混乱不清，业务逻辑层也是杂乱无章，很多系统里干脆把数据库当作业务逻辑层（这可不是说笑，因为数据库无法推脱责任了）。结果，混乱的业务逻辑依附于糟糕的IT系统，乱上加乱最终成了一锅粥。对IT来说，已有业务的问题层出不穷，每次出问题都需要花费大量精力，寻找蛛丝马迹来“破案”；对业务来说，新增业务往往会影响到原有业务，但谁也不知道会不会影响，会如何影响。系统日渐庞大的另一面是内部日趋无序，复杂度和维护成本飞速增长，远远超过可控范围。
吊诡的是，许多人的解决办法不是针对问题的根本原因，评估业务复杂度、整理业务逻辑、整理业务关系，反而认为“推倒重来”、新做一套系统就能解决。持这种观点的人，通常对系统与业务的关系也有误解。
对希望“推倒重来”的人来说，系统和业务的关系，有点像车辆对人员：一辆车我开了一段时间觉得不好，就想换一辆车来开，这是很自然的。但是在信息化深入工作各个角落的今天，系统和业务的关系远不是“车辆对人员”那么疏远，而更像“心脏起搏器对人”，或者“人造骨骼与肌肉”的关系，已经如胶似漆缠在了一起，系统对业务的支持越多越广（暂时不论质量），双方纠缠得也就越紧密。更换心脏起搏器或者人造骨骼的难度，远远比换车的难度要大，所以需要慎重考虑，不能单纯因为心脏起搏器“不那么好”就轻率决定更换。对系统来说，也是如此。
如果要对基础不好的遗留系统做脱胎换骨的改造，我有几点经验可以参考：
第一，一定要有非常优秀的业务人员和开发人员。
对业务人员来说，不但要熟悉自己手头的操作，还必须明白操作背后的逻辑，并且需要超越本职工作，能从全局角度来思考自己的业务（有时甚至要让自己操作更复杂，来提高系统安全性等收益），这样才能真正把握住业务的复杂度。对开发人员来说，要能够完整理解领域知识，同时必须有高超的编程能力来应对遗留代码，敢于出手而不是畏缩不前，谨慎出手而不是贸然行动——如果原有系统开发人员的技术能力可以打30分，全新开发系统的技术要求是60分，那么要成功改造遗留系统的技术人员，往往需要有80以上的分数才能胜任。
第二，“推倒重来”往往不如“逐步改良”。
所谓“逐步改良”，指的是大家先通过讨论确认未来系统的设计蓝图，然后需要开发用于过渡的接口层。于是，新开发的模块一定要严格按照新的规范开发（这也就是我说的“理清各模块职责、API通讯机制的建立、内部分层的整理”），同时通过过渡的接口层与原有系统对接，原有的模块则在理清业务逻辑的情况下，按需切出合适的接口，逐部分在测试通过的情况下进行迁移。最终新的系统是像拼图一样慢慢拼出来到最后一天才成型的，而不是平底盖楼造起来的。在这个过程中，最关键的是找到合适的切入点，搭建出合适的接口或者接口层。这些工作就像盖房子的脚手架，哪怕之后不会用到，中途也不能省略，还必须仔细对待。当然，这是一个考验人的工作——我曾经遇到过数据库事务里跨库连表的查询，这个糟糕的设计严重阻碍了单数据库实例拆分成多实例的进展，回想起来真是如噩梦一般。
如果你对改造遗留系统有自己的见解，或者在这个过程中有什么有意思的经历，欢迎留言给我。
最后推荐一本有意思的书。其实不管是软件开发还是社会变革，对于不喜欢的现状，大家往往喜欢来个“干脆”、“彻底”的解决方案，但真正成功的往往不是这些方案。在第二次世界大战结束时，世界上到底发生了哪些事情，遇到了哪些问题，又是怎样重建社会秩序的呢？广西师大《理想国》丛书第9册《零年：1945现代世界诞生的时刻》，用翔实的文笔全面记录了“终战”之后的情景，许多画面相信会让读者大吃一惊——很多时候“文明”堪称被打回原形，“零年”这个名字可谓名副其实。
From Life Sailor, post “推倒重来”的讲究
注：原文发布于2023年1月16日 到1月份为止，我已经体验了几个月的全远程+共享空间办公了。有不少朋友听说之后很有兴趣，问我到底是什么感觉，所以我简单介绍下个人的体验。 背景 2019年末、2020年初开始在全球流行的Covid-19对远程办公来说，绝对是黑天鹅一般的存在。因为疫情导致的社交隔离措施，极大影响了各大公司的正常运转。 所幸，IT类公司受到的影响比较小，只要求员工“面对屏幕编程”，不必亲临现场。所以，许多IT公司也谨小慎微地开展了远程办公的试验。 从我所知道的结果来看，不少美国公司并不特别喜欢远程办公，比如Google，一旦社交隔离措施有所放松，就忙不迭要求员工回到办公室，盖因为公司认为远程办公严重影响合作效率。 与此相反，不少德国公司反倒是逐渐适应了远程办公的节奏，纷纷降低对员工“到办公室上班”的要求，许多公司甚至可以支持百分百的远程办公。 这里要提到的是，德国公司说的“远程办公”往往是货真价实的“远程”，而不是一些人理解的“家和办公室在同一个城市，只是不用去办公室”而已。 因为德国IT行业缺人严重，而且许多德国公司并没有那么“互联网”，而是依托实业开展业务，所以据我所知，目前不少公司非但没有裁员，反而都在大力招人。 (more…)
注：本文发布于2023年2月6日 最近硅谷几大公司都在裁员，看了些报道，被裁的员工真是不好过。损失经济来源不说，有些人还面临身份问题，这可真是屋漏偏逢连夜雨。 我也留意到，不少被裁的人会不停追问自己：为什么我会遇到这样的事情？为什么这样的不幸会降临到我头上？…… 实话说，我挺能理解这种态度。这挫折如此巨大，似乎又来得全无预兆，不由得让人对命运、对人生、对世界产生深重的怀疑。尤其是对已经走入社会，取得一定成就（如果非要抠字眼，那就用“进展”吧）的人来说，更是如此。 但是我更想说，如果被裁员了，当务之急是赶紧找到下一份工作，哪怕只是机械地行动。要知道，成年人找工作，容不下那么多愁善感。 我之所以这么说，是有切身经历为基础的。之前我讲过找德国工作的经历。最开始是信心十足的，因为虽然毕业多年，手艺没丢，基础还在，随时打开leetcode，中等难度题目基本都不在话下，不但能解对，解法也基本接近最优。既然网上都说“刷题就能找到工作”，估计自己应该没大问题。 没想到真的找起工作来，仍然充满了意想不到的挫折。如果不相信，我且举几个例子吧。 (more…)
虽然早就听说《园丁与木匠》是关于育儿的好书，但一直没开始读。最近终于翻开这本书，才发现属于“拿起就很难放下”的类型，加班加点读完，收获不少。 关于这本书的价值，已经有许多书评讨论过了，所以我想略过微言大义、长篇大论的叙述，谈谈我印象最深，也是最打动我的三点细节。 第一，儿童的学习方式 小孩子觉得拧螺丝很好玩，想自己动手拧一颗螺丝。于是，他打开了工具箱，对着琳琅满目的工具，他不知所措。一会儿摸摸钳子，一会儿试试扳手……这时候，旁边的父母应当怎么办？ 在大多数情况下，父母大概会直接告诉孩子，“亲爱的，你应该用螺丝刀，来，我告诉你”。耐心一点的父母，大概会潜心观察一段孩子的举动，再设法“引导”他到正确的工具上来。在父母眼里，孩子当然不可能一开始就找对正确答案，所以做各种尝试也是情有可原。但是另一方面，也不应该“在错误的路径上摸索太久，浪费时间”，应当“迅速识别出正确的答案”。 无论父母有多少耐心，在他们眼里，孩子找到拧螺丝的工具的过程，都是个“不断接近正确答案”的过程。这个过程越短，孩子就越“聪明”，或者说“学习效率”就越高。 (more…)
陈皓（Haoel，网名“左耳朵耗子”）上周六因为突发心梗去世了，享年47岁。 我跟他虽然聊过好些次，但只是微信好友，从未见过面。回看微信记录，当年稀松平常的一声“再见”，已经成了“再也不见”。 许多人在缅怀他，许多文章提到他的时候，会用到“骨灰级程序员”、“技术大牛”这样的称呼。但如果仅仅用这两个词描述他，断然难以解释，为什么他的突然去世，会引发互联网上怀念的狂潮。 所以，我更愿意按照自己的经验，把他描绘为“有坦诚追求，兼具趣味、操守、胸怀的技术人”。恰恰是因为这样的人在这个年代太稀少，而这些品质又让众多人赏识和受益，大家才会如此地怀念他。 这个年代，做技术（仅指狭义的IT）的人很多，愿意分享的人也不在少数，其中不少还可以算世俗意义上的“成功者”。 但是，若仔细去看他们分享的内容，总感觉不够真诚。总感觉作者希望往高深了靠，目的也没有那么纯粹。你若提一些小白问题，迎来的往往是“你怎么连这都不知道？”的反问，或者“要谈这个问题，你先去看几本书再说吧”。话是这么说没错，但无数的初学者也往往因此打了退堂鼓。 但是陈皓的分享不同。我已经不止一次地看到有人提起，他分享——更准确说，是“创作”——的内容质量很高，而且总能做到“深入浅出”。哪怕是小白读者，看完也确实能有收获，如果还有兴趣，更可以跟着文末的链接，顺藤摸瓜探究更广阔的世界。 这让我想起我佩服的一位记者说的：记者写文章的最高境界，就是不表达自己的观点，因为记者的观点应当来自于他的素材。只要把这些素材摆出来，读者读完报道，观点就自然形成了。要做到这一点，需要对素材有足够的信心和把握，外加真诚和坦荡。 能做到这一点的记者，着实不多。陈皓虽然不是记者，他写的技术文章却能让读者得到类似的结论——要知道，技术讨论往往是非常容易擦枪走火的——可见他运用素材和逻辑的功力，以及更重要的，他的真诚和坦荡。 (more…)
2022年我接手了一本技术图书的翻译，拖拖拉拉到现在，也快截稿了，现在能做的，就是反复审阅，查漏补缺。 但是，有个问题一直困扰着我，始终得不到解决，那就是“姑妈-姨妈”问题。 书的最前面有某业界大牛写的“丛书编辑前言”，里面提到my grandson is learning from his aunt, my youngest daughter。众所周知，英文里亲戚的称呼远比中文简单，grandson既可以指孙子，又可以指外孙，aunt既可以指姑妈，也可以指姨妈。 所以从逻辑分析，grandson可能是“孙子”也可能是“外孙”，那么my daughter对他来说既可能是“姨妈”也可能是“姑妈”，因为文中再没有相关的信息，任凭你分析，也不知道哪种组合才是对的。 因为之前一直忙着处理正文，这个问题一拖再拖。眼看要交稿了，没办法，我才给作者发电子邮件。对方是业界大牛，这个问题又如此的“细枝末节”，那么他会不会回复，有没有耐心回复，我完全不知道。…
注：原文发布于2023年12月22日。 上一篇文章（坚持了两年之后，小朋友突然不想去打冰球了…）发出来之后，出乎意料阅读量竟然创了近期新高，也收到了不少反馈，看来育儿确实是如今许多人关心的话题。 在我收到的留言中，有好几条都提到，小朋友“选择要学的东西之前应当谨慎认真，一旦自己做了决定，那么再苦再累也要坚持”，万万不能“半途而废”。这个说法我非常熟悉，“半途而废”这四个字更是深深触动了我。确实，我反复想过，也和家里领导讨论过这个问题：身为家长，你能接受孩子“半途而废”吗？ 答案当然是“不能”。 我写过自己小时候学手风琴的故事。那时候也有很多泪水、挣扎、反抗，每次闹到不可开交，我父亲就一本正经地说：“这是你自己选的，当时问你要不要学，你说要学，既然说了就必须做到……” 然而我还是没有能坚持下来，学了十年之后终于以“学习更重要”为理由自我解脱了。 等到再捡起来，已经是自己成为父亲之后。有更多时间练琴，更是到了欧洲之后的奢侈享受。虽然现在周围人都反馈我弹得还可以，也因此交到了不少朋友，但内心仍然有遗憾，一些很想弹的曲子，因为对我来说太难，实在是举步维艰。 如果当时没有半途而废，该是多好的一回事啊。 (more…)
View Comments
最近我们的老服务重构项目到尾声了，采取的策略就是：先维护和重构外围接入层的服务，灰度上线和回归来替换掉老服务；后续重构核心业务层；最后才计划动数据库。您的这篇文章值得我经常回顾，谢谢。
血泪的教训啊。我觉得最主要的是先明确定好要做什么以及详细了解清楚现在有什么，然后才是动手。