最近看到了两篇文章，都是说系统重构/改造/升级的。一篇是《互联网架构实践：给飞机换引擎和安全意识十原则》，另一篇是《知乎社区核心业务 Golang 化实践》。这两篇虽然侧重点不同，但都涉及到一件事情：重构项目的项目路线。第一篇文章提出了三种重构方式：彻底重新做，直接从前到后抛弃老系统；大规模重构，保留对用户的这层皮，后面从服务到数据全部替换；小规模重构，保留对用户的这层皮以及数据结构，逐一替换核心逻辑到微服务。虽然原文是根据重构的彻底性来说的，但这三个划分其实也是三种项目路线。知乎的Golang改造选择了“大规模重构”的思路：保持新服务对外暴露的协议（HTTP 、RPC 接口定义和返回数据）与之前保持一致（保持协议一致很重要，之后迁移依赖方会更方便）；并且在重构早期新的服务没有自己的资源，使用待重构服务的资源。然后通过功能验证、灰度放量等方式逐步将老服务切到新服务上。
如果是我，我也会选择这样的路线。因为我以前用第一和第三种方式做重构时，都遇到了很大的问题。
先说第三种方式。小规模重构会面临进退维谷的两个问题。如果我们没有一个完整的业务和系统架构设计，那么零敲碎打的重构改造对系统的优化作用和性价比实在有限：船都进水了，刷刷甲板擦擦灯罩也改变不了什么。而如果我们拿出了完整的架构设计，小规模重构往往就满足不了整体重构的需要，而必须升级为大规模重构了。所以，小规模重构在整个系统的层面上比较鸡肋；它比较适合于针对某个单独功能点的优化。当然，这种方式也并非一无是处。它能够延缓系统腐化的趋势，也能帮助项目团队提高能力和增加经验。总之，在系统架构稳定之后或是大规模重构之前，小规模重构还是大有可为的。我之前参与过的一个重构项目中，项目团队在系统级别的重构完成之后，还在持之以恒地对一些小功能、小细节进行重构，就我所知，这个系统目前无论在业务上还是在技术上，都非常的健康。
对系统级重构来说，小规模重构有点像缘木求鱼，虽然抓不到鱼，倒也没有什么大的坏处。彻底重做却有点像饮鸩止渴，很多时候不仅无法达成目标，还会埋下重大的隐患。最主要的隐患是新系统的技术、业务架构都要在全部开发完成后才能得到验证。这会导致风险都被压缩到了测试和验收阶段这两个阶段中：这时已经是上线前的倒计时阶段了，加上开发阶段在所难免的延期，时间往往非常紧张。在这样短的时间内尝试检查和解决大量风险，其中的问题是不言自明的。有个同事总结说，这个时候发现问题了，系统上线要延期；没发现问题，往往更要延期——因为积压了太多的功能和代码需要测试验收，没有问题比有问题更让人觉得心慌。此外，新系统上线之前老系统发生业务需求变更也是不容忽视的一个问题。新需求会扩大新系统的范围，进而影响开发、测试和验收的工期，最糟糕的情况下还可能迫使新系统修改技术或业务架构：这样的后果就不堪设想了。我参与和见识过两个这样的项目，在团队成员辛苦忙活了半年、一年以后，系统却因为种种问题、风险而一再延期。
曾经有同事在讨论中提出用最快的速度、最短的时间把新系统推上线。这样，测试验收的时间比较充足；通过快速试错的方式来修改发现的问题；而且这样还可以避免出现第二个问题。这样做似乎可行，但我认为这种“快速试错”的方案并不可取。首先，老系统为什么会腐化到非重构/重做不可的地步的？长期地只重速度不重质量、“先上线再说”的开发模式难辞其咎。在市场快速扩张、业务快速增长阶段这样取舍还情有可原，在专门拿出时间精力来做重构时仍然一味地“唯快不破”，岂不是要重蹈覆辙、欲速而不达？其次，快速试错是在市场方向、业务需求不明朗的情况下，有一丝“无奈的”试探性做法。但对业务系统重构项目来说，功能需求和性能指标都可以从老系统中总结、提炼出来。在可以看清楚道路的情况下还要闭着眼睛“快速试错”，非常的得不偿失。
彻底重做的方式有点类似瀑布式开发模式，可能只适合于一些规模较小、功能简单或者功能长期不变的系统。对大型的、复杂多变的业务系统来说，更合适的方式应该是更接近敏捷开发的大规模重构。这种重构的路线可以参考《知乎社区核心业务 Golang 化实践》。与小规模重构相比，大规模重构有一个更加全局的、完备的规划，每一个模块、每一个功能的重构既是对原有功能的优化改造，同时也是更大蓝图中的一块拼图。与彻底重做相比，大规模重构更加的敏捷：新系统的风险和问题会在逐步替换的过程中暴露和解决，从而避免了近在咫尺时才发现冰山的可怕场景。而且，在重构过程中遇到新需求，我们也有了更好的解决方案：我们可以先对相关模块做重构，然后在重构后的基础上做新需求。这样技术业务两不误，开发和产品也皆大欢喜。
哲学中有一个“忒修斯之船”的命题：把忒修斯乘坐过的船上的每一块木板都换成新的，最后这条船还是忒修斯的那条船吗？相比这个哲学命题，我更喜欢研究如何对那条船进行翻新修缮：小规模重构就像是在风雨飘摇的大海上刷洗甲板、修理护栏；彻底重做是在船坞里建造一条新船；大规模重构则是在航行过程中把小木船逐步升级改造成大航母。就我而言，无论是期望还是经验，我都愿意选择大规模重构的方式。
联系客服
