作者：丁仪

来源：https://chengxuzhixin.com/blog/post/xi_tong_zhong_gou_ji_qiao_gao_ding_yi_liu_dai_ma.html

前几天偶然看到一位网友发的内容，说是老系统改了一行代码就崩溃了，着实令人头秃。越是成功的公司，越是有大堆的老系统和无法统计的遗留代码，尤其是基础服务相关的代码，那简直是按下葫芦浮起瓢的现实版本。创业公司倒是好一点，没有历史包袱。我们也经常重构老旧代码，不为别的，就是怕放太久发霉。恰好最近也在做系统重构，总结下我们在做的事情和一些技巧。

代码也会发霉

会发霉的不只是食物，代码也会。我们通常称为腐化。腐化的过程每天都在发生，一个紧急需求，一个新同事加入，一个变态的问题修复，一个共建项目，等等。腐化，是永远无法避免的，就像宇宙的熵增不可逆一样。面对腐化，架构师往往会加上一个防腐层。如果你的系统还没有防腐层，赶紧考虑考虑。即便有防腐层，也招架不住岁月的摧残，就像头上那日渐稀少的秀发，这就是命啊。

所以，我们需要重构。逆熵增需要做大量的功，要对混乱的代码重新梳理，使其恢复条理清晰、架构分明的优良状态。

梳理，还是梳理

重构前花大量时间对历史逻辑做梳理，而且要细致。古人曰“工欲善其事，必先利其器”。梳理好的逻辑就是重构的指路明灯。哪些要丢弃，哪些要优化，哪些要重构，哪些要产品重新定，哪些是风险点，在梳理好后就基本明了了。梳理带来的不只是逻辑的浮现，可能还有架构的方向。通过梳理，能够明确发现业务逻辑，甚至可以定义出新的领域模型、值、事件等。想想银河纪元时代，拿着银河系实时星图作战，就知道梳理有多重要了。

回放，对比变化

重构之后，测试要全面覆盖。这时候，回放就非常重要了。阿里也开源了一个回放工具 jvm-sandbox-repeater。GitHub 地址https://github.com/alibaba/jvm-sandbox-repeater。通过回放，可以在预发环境 debug 线上问题，可以看到线上真实流量在预发环境的实际表现。通过对比，可以发现重构后哪些地方和之前不一样了，尤其是页面渲染和持久化的数据。

回放做好以后，还可以作为日常发布的快速验证。只要本次回放和上次正常回放差异不大，基本上风险就已经很小了。

架构，以终为始

既然做重构了，架构方面就要好好设计。尽量摒弃错综复杂的历史逻辑，设计新的架构方案。以提高研发效率、降低维护成本为最终目标，所有的重构设计都围绕着这个目标展开。没有什么是不能改的，如果不能，那就加两个更牛逼的程序员。如果重构后还保留一坨屎一样的遗留代码，真不知道重构的意义是什么。重构就是要以终为始，在新的架构设计中，让遗留代码重新投胎以获得新的生命。

改善，代码重构

优秀的程序员是需要不定期对已有代码做或多或少的重构的。在《重构 改善既有代码的设计》一书中，作者已经给了很多重构的具体方法。重复代码抽出、过长函数拆分、模型重新设计、封装字段、封装集合、以State/Strategy取代类型码、方法移动位置等诸多技巧，这里就不展开了。我觉得每个程序员都应该好好学习下这本书，然后深入实践下代码级重构。正如书评所说“虽不应翻着重构手册干活，但需对本书中提到的70多个重构方法成竹在胸”。

速度，速战速决

遗留代码很多已经像网贷一样了，越陷越深。投入资源做重构所获得的回报，实际上比继续维护老代码高的多。重构的过程要快，过程中日常需求尽量暂停。重构的工作量很大，但是对速度要求也很高。如果一边重构，一边线上还在做需求变更，很可能陷入困境，甚至在重构后丢失线上逻辑。梳理做好了，回放做好了，程序员就可以按照计划快速重构，多上几个人，确保快速完成。

心态，胆大心细

前面的工作都做好了，那接下来就是干了。

放心大胆地干，不要怂。这段代码看不懂怎么办，改！看回放。这段代码又臭又硬怎么办，改！看回放。

改的时候，也要心细一点，好好理解下原有的业务逻辑。在战略上藐视敌人，也要在战术上重视敌人。做好 code review，让了解的人一起看改动，或者团队成员一起把把关。