大规模系统重构

经年累月下来，系统通常会显得老态，具体症状是 1. 一个貌似非常简单的功能，开发团队居然要花很多时间才能把这功能加入系统 2. 办理促销活动前，技术人员如临大敌，尤其是维运团队。只要有上述这两个迹象，你基本可以判定，系统需要进厂大修了。这篇文章概略描述大规模系统重构的方法。

别急，想做大规模重构，你还必须先评估两件事：1. 重构或不重构 2. 开发能力是否足够。

你必须先评估系统重构所需要的时间是否太长、需要的资源是否太多、对长期的效益是否值得、以及整体风险是否可控。如果不做系统重构，还有没有其他选择？例如升级硬体设备、採购新系统、自行开发新系统，同样评估这些可能选项的时间、资源、效益、风险，才做决定。

在评估重构或不重构的同时，也必须对系统状态做全面的汇总，尤其是：每一个系统的目标、功能、介面、关联系统。全面的汇总资讯除了有助于评估重构或不重构，也有助于在决定重构后选择适合的重构目标。

重构也是一种开发，但这种开发比单纯的开发通常更困难，所以你必须评估现阶段团队的开发能力是否流畅。如果你的团队在单纯做开发时就已经搞得磕磕绊绊，那么还去做重构，无疑会人仰马翻，这时候，你需要的不是去重构，而是去提升开发流程、熟悉开发语言和框架、凝聚团队的向心力。也就是说，先「整军经武」。

如果上述这两点都明确了，就可以进入「重构循环」，这是一个四阶段持续轮迴迭代的过程：第一阶段是「选择目标」，第二阶段是「规划建模」，第三阶段是「开发测试」，第四阶段是「回顾总结」。第四阶段后，回到第一阶段，进入下一个循环。一个循环的长度最好控制在一个月到一个季度之间，因为短于一个月做不了有意义的事，而超出一个季度容易失控。

目标的选择，主要受到三个因素的影响：团队成员在重构方法的熟悉程度、主管（或业务方）的支持程度、客户的感受。如果团队成员对重构方法比较陌生，那么可选择比较简单、风险比较低的目标，例如API介面的重构。这时候真正的目标是：培养做事的方法和团队的默契。如果主管的支持程度比较低，且团队已经有方法和默契，可以选择他关心的问题作为重构的目标，来得到他的支持。如果明确知道有哪些地方重构后，可以提升客户的感受，也可以选为目标，客户的讚扬，会辗转化为主管的支持。

另外，打破系统之间的循环依赖，这也是非常值得做的重构目标，对长期体质的调养是有好处的。如何做到这件事，需要另写专文。

第二阶段是规划建模，把现在的系统现况分析清楚，对未来的目标建模，接下来设计如何分工完成。规划建模的部分包括逻辑重构、介面隔离、资料搬迁的具体方法。

第三阶段是开发测试，把前面的规划付诸实现。测试是关键，採用灰度发布是有必要的，也就是说，让新旧同时并行一段时间，比对验证，逐步切换，以避免不可挽回的错误。

最后的阶段是回顾总结。每个循环的过程产生的经验，要保留下来，扩散出去。问题提出来讨论，大家一起发想。这是提升个人能力和团队实力的时刻，千万不要放弃了这绝佳的机会。还可以把一些经验教训变成流程的一部分，甚至累积出一套一套好用的模式、工具库、框架。

你在变老，系统在变老，团队在变老，公司也在变老。透过良好的重构，你在回春，系统在回春，团队在回春，公司也在回春。但回春需要正确的方法，就怕採用的方法错误，导致崩坏加速