系统重构的最佳实践

1、 系统重构的最佳实践EGONetworks 微信号 egonetworks功能介绍 EGO是极客邦科技旗下高端技术人聚集和交流的组织，以CTO、技术VP等技术领导者为服务对象，采用实名付费会员制，严格审核会员资格，旨在组建全球最具影响力的技术领导者社交网络，线上线下相结合，联结杰出的技术领导者学习和成长。我们日常工作中，系统重构应该是最让人头疼的了，无论是错综复杂还是简单的系统，在发展的过程中都会经历重构，系统重构也是任何技术团队无法回避的问题，在我服务的多家公司，几乎每家公司都经历了一次甚至多次系统的重构，本文就我在多年的重构工作中总结出来的几点建议分享给各位朋友，希望能够给朋友们带来帮助。

2、重构确定并且聚焦目标首先我相信我们大家都确信，系统重构会有巨大的成本投入，业务可能需要暂缓、新系统引入的问题（ BUG ）会带来业务的不稳定，存在研发人员投入开销还有各种隐性成本等等。我们服务的商业公司，获取利润是最终目的，投入成本做一个项目肯定要获得收益。重构的目标一定要能够获得更大的提升，无论是业务流程、系统性能或是其他方面，如果仅仅一个很小的改善，完全没必要大费周章。因此重构之前权衡好成本，重构是否能够获得良好的收益？无论如何进行系统重构都是一次伤筋动骨的过程，是涅槃重生还是飞蛾扑火，完全取决我们项目执行的过程中是否明确了目标，且一直聚焦于目标的实现。保持目标的聚集是能否取得良好结果的必

3、要条件。如果我们仅仅确立了目标，但没有聚集于目标，反而在多个非重要的节点投入较大资源，必然会导致我们对目标的投入降低。工作中的原始资本投入都是 8 个小时，这就需要我们明确目标聚焦目标，把有限的资源投入到最重要的事情中，才能获得既定目标的良好结果。重构要有可量化的指标团队确认了重构的目标之后，下一步要将目标量化，确定好目标之后就能够确认边界，围绕在边界内将需要实现的事项一一罗列出来，尽可能对每个实现制定可以用数据清晰表现出来的指标，比如用户操作的响应时间缩短到 100 毫秒、单元测试的覆盖率达到 80% 、发现问题时长降低到 30 分钟以内等等。有了明确的数据指标我们才能评估最终是否获得了良好

4、收益，这些目标必须要在重构团队，包括产品、研发、测试甚至包括业务方在内达成一致，团队的目标需要清晰明了，防止出现过度或是不达标是最终不能获得良好收益。重构要有更好的质量既然决定了要对系统进行一次重构，那么我们肯定要做到的就是要比之前做的更好，如果之前接口响应时间在 100 毫秒，而经过重构之后反而到了 200 毫秒以上，那么大家辛苦付出的努力是不是也更加不值得。而进行重构往往是一件十分引人注目的事情，一个微小的问题反而容易在众人注目下变得非常严重的问题。为了减少引起不必要的麻烦，重构团队就更加要注重各个方面的问题，无论是系统性能、用户体验还是 BUG 数量等。重构之前要和业务方沟通技术团队进行

5、系统重构的工作的时候往往忽略掉了业务方，认为这是技术团队内部的事情，不需要知会业务方，这个想法是非常错误的，进行重构的目标就是为了改善改进业务流程，而不去和业务方提前沟通进行闭门造车，最后的结果很可能和进行重构的初衷背道而驰。进行系统重构首先我们必须了解现有系统的业务需求，是否有待改进的业务需求点，是否有新的业务诉求等，这些需求往往会影响到我们重构的进度和目标，甚至出现南辕北撤的事情。技术团队和业务方往往对待问题的出发角度不同，思考问题的方式也不同，在进行重构之前和业务方沟通获得业务方的支持，往往能够事半功倍。例如，我的团队在进行一块业务系统重构的时候进入到了系统切换的试运行的阶段，由于拿出的

6、方案给到业务方无法被业务方接受，业务方提出的解决方案我们还需要进行再次开发，对整个项目进度影响了足足一个月时间之多。吸取教训的我们在进行下一个项目的时候提前和业务方进行了沟通，业务方从他们的角度给予了很多的意见和建议以及业务未来的发展方向的指引，我们发现这些建议和意见帮助我们更好理解业务的同时也大大的降低了我们工作量，减少了我们很多冗余的设计。重构应该用迭代的方式参与过重构项目的朋友都知道，重构项目往往是个时间跨度很长的工作，少则一两个月多则一年半载都有，如果不将整个重构进行合理拆分，而是采用全部开发完成，再进行系统切换的方式会对整个重构引入很大的风险。首先长时间的时间跨度内业务会进行持续变更

7、，其次团队面临长时间没有结果输出面临来自各个方面的压力，还有系统问题持续累积，这种蒙头狂奔的方式往往造成了项目失败或是目标便宜。而采用迭代方式进行重构，可以以更小的颗粒度持续交付工作成果，交付 - 试用 - 反馈 - 调整，持续有交付，持续有反馈，持续调整能够保证团队的目标不会偏移，形成一个正向循环，保证最后的重构目标。重构要清晰了解旧系统知己知彼，百战不殆，系统重构是一个与旧系统对抗的过程，不对旧系统的弄的清清楚楚怎么能够比旧系统做的更好呢？其实了解现有系统是一个学习的过程，如果有旧系统的开发人员还在公司，那么就事半功倍了，旧系统的开发同学帮忙给做次分享，省去了我们重构团队很多的工作，比直接

8、去读代码更能清晰明了的了解到旧系统的相关知识，以及有哪些需求点和应该注意的问题等等，通过学习和了解旧系统设定目标基准值避免引入老旧问题，也是避免重蹈覆辙的一个好办法。重构要提前规划系统切换方案不知道朋友有没有遇到过，重构完系统发现，如果进行新旧系统的切换是个难题。我们以前遇到过由于没有提前做好规划和切换步骤，导致最后临时抱佛脚，开始使用各种奇葩办法做系统切换，有的还需要增加额外工作量，甚至各种办法的刷脸求人，总之这不是一个很好的体验。系统切换往往是在重构中被我们忽略的一个步骤，但是这是非常重要的一个环节，在做最初的计划就应该考虑到如何进行系统切换，一个设计好的切换方案也应该贯穿重构始终，避免因

9、为切换方案引起服务不可用或是引入系统 BUG 。尤其是前期整个团队付出巨大努力取得了一定成果的时候，在最后一步切换的时候出现问题，对团队是个非常大的打击，也使得业务方对团队失去信心，带来很不必要的麻烦。重构高度重视系统数据一次系统重构大多数情况下会涉及到数据结构的修改，对数据结构进行修改必然引入很大的风险，尤其在一些老旧的业务系统重构精简，业务去掉冗余数据的时候，往往需要将老数据的业务数据重新写入到新系统的数据库。重构的目标是为了比旧系统更好，无论是性能还是业务方面，如果我们对数据的操作导致外部依赖旧系统的业务无法正常运行，那将是影响 SLA 指标的问题。说到系统数据有些同学可能仅仅关注的是业

10、务数据，其实数据也包含了系统运行所产生的日志数据，无论新旧系统的日志数据，都是很重要的，如果因为重构影响到数据的读取、处理、分析，则是得不偿失的事情。重构要采用成熟的技术选型技术选型是重构工作的基石，选择一套成熟稳定的技术方案是重构项目完成的必要条件。有些时候我们引入最新版的数据库虽说会有性能提升但是也会引入一定的不稳定因素，之前我们团队在使用 MongoDB 的一个新版本的时候，发现主从库的数据并不能很好的同步，出现过丢失数据的情况，进入社区发现这个版本使用的用户很多都反馈了这个问题。这时候我们不得不选择了大多数人共同的一个选择，降低了一个版本来解决问题，相信此类情况比比皆是。在不是很成熟的

11、方案带来并不显著的性能提升，反而还会引入不确定的风险的时候，我们需要权衡利弊得失，重构更是要保证系统的稳定性。技术方案能否有足够强大的支撑也是我们需要考虑的一个方面，现在我们团队面对的重构是从单体式架构往微服务转变，旧系统的版本构建在是 PHP 语言上，新的系统我们由两个选择继续选择用 PHP 进行重构或是采用公司统一的微服务框架，我们毫不犹豫的选择了使用公司统一的微服务，这样做有几个显而易见的好处。和公司内部进行交互更加方便快捷；可以直接获取成熟的经验；基础服务有公司级的支持；以上的好处，显然对我们能否成功重构系统并且获得足够的帮助起到了显著的帮助，反而采用 PHP 进行微服务，公司内部并无成功经验可以借鉴，业内也并无太多可靠的方案可以进行选择。一个成熟可靠的的技术方案是我们能否更进一步的保障和基石。重构更加关注重视团队成员参与过重构的同学都知道重构工作是一项枯燥乏味的工作，往往周期长、复杂度、难度大、牵扯广、优先级低，而且很有可能是一件费力不讨好的工作。开发一个业务方期待的新功能、新模块往