如何来一次说干就干的重构 (流程篇)

摘要： 科学的重构流程。

• 原文：如何来一次说干就干的重构 (流程篇)
• 做者：逐鹿 IT, 猛猛如玉

Fundebug经受权转载，版权归原做者全部。

前言

随着公司业务的爆炸式的增加，需求规模和用户规模也迅速地膨胀起来，这样给系统的三高(高性能、高并发、高可用)以及扩展性、可维护性都带来了考验。而旧系统由于早期设计的各类局限性（如早期参与人员的水平、架构设计的前瞻性、老板的急性子等等），逐渐知足不了现状和将来的新需求，暴露出各类问题。开发人员们像是拖着老破车上高速，苦不堪言。（说人话：老系统代码的坑太深了，开发们填不住了，要么被坑埋了，要么弃坑逃跑了…）

那么这个时候，一般要面临一个问题：是继续填坑仍是跑路走人 选择重构。填坑是不可能的，这辈子都不可能的。而选择重构是须要壮士断腕的勇气，由于重构是一项老大难、一件耗时耗力的事情，且多少会对现有业务开发形成影响，甚至是停滞。所以大多时候得不到产品经理和老板的支持，他们关心的只有一个：下个需求何时能上！至于其余的，都是大家研发该操心的。

本身选择的重构路，跪着也要走完。如何来一次就干就干的重构呢？根据互联网常见项目重构流程，以及个人亲身参与的重构项目经历，梳理大中小型系统的常见重构流程以下：

零：说服业务方

重构不单是研发团队的事情，更是整个项目团队的事情。重构能够提高系统的三高，也能够优化改善业务流程，知足新的业务诉求等等。重构须要投入大量资源，必需要获得业务方的支持。一般这个时候须要对他们晓之以理，动之以情，阐述清楚重构的利弊，以及不重构的要害。在获得他们的支持后，重构的工做便正式开展。

参与人员：技术 Leader

一：树立重构目标，有的放矢

重构是一项工程，是一场持久战，它不是一两个迭代、甚至一两个月能作好的事情，须要投入大量的人力、物力、时间精力等。那么在这场旷日持久的战斗中，咱们的目标是什么？是经过更优秀更合理的架构来知足系统三高的需求，仍是想经过重构来提升代码质量，或者引入新的技术和框架来升级整个系统，抑或经过重构来优化业务流程，实现原来实现不了的需求。有了目标后，才能作到有的放矢。

参与人员：技术 Leader，架构师

二：肯定重构的范围，并对重构做出预测

重构一般有如下几个级别的重构

• 平台级别重构。针对总体平台的重构，如阿里早期是 LAMP 架构，后来总体迁移到了 Java 平台。
• 系统级别重构。针对业务系统的重构，如经过引入微服务架构或者 SOA 架构，分解单体应用。
• 架构级别重构。如经过架构的调整和从新设计，改善原有架构的不合理之处。如经过分层使业务解耦，引入缓存设计提高系统高并发等。
• 业务级别重构。常见为某些业务需求由于系统设计的不合理性致使没法知足或有缺陷知足，须要经过业务系统的重构调整或数据库的重构来解决。
• 模块/代码级别重构。这是最多见的重构。一般指使用设计模式、封装继承、优化拆解代码，使得代码的结构更良好，运行效率更高。

肯定此次重构是属于什么级别，肯定重构的总体范围的大小，肯定重构的技术选型，进而对重构工做进行科学的评测和预估。好比须要投入哪些成本，须要投入的人力和时间是多少，在重构的过程当中可否支撑正常业务需求等等。在有了这些预测后，也对业务方有个交代，尤为是当他们追在后面问何时能上新需求。

参与人员：技术 Leader，架构师，研发人员

三：旧系统的熟悉和业务梳理

重构不是和旧系统说散就散，而是要不断和旧系统战斗的过程。知己知彼，百战不殆。重构不只须要清楚新系统的目标和将来，更须要对旧系统很是熟悉(尤为是坑)。此时须要参与重构的人员(尤为是参与旧系统的人员)来对旧系统业务和系统进行梳理，对原有资料信息进行收益和整理的工做，对旧系统的关键代码和数据库设计进行 Review 等等。

如下是重构旧系统前须要准备的常见工做：

• 旧系统资料和信息的收集，包含且不限于系统相关的设计文档和技术文档等文档资料，架构图、UML 图，数据库设计 ER 图等图形化资料
• 业务线和业务流程的梳理，整理业务线上的各大项目、业务流程，并输出为文档
• 旧系统关键代码的 Review

有相关疑难点及时与相关与业务线上的人员沟通，将问题解决在”襁褓”中。

参与人员：技术 Leader，架构师，研发人员

四：数据库重构

若是在重构中须要涉及数据库的重构，数据库的重构通常是最早开始的一步。系统须要重构的直接缘由，也大多和数据库有关。在数据库重构时，咱们清楚旧系统中数据库的各类设计缺陷和使用障碍，那么就能够对症下药，如经过三大范式或反范式来设计表，是否须要分库分表等等。

参与人员：DBA，架构师

五：后台系统重构

后台系统重构前，必须须要依照前文所述的一些设计和技术文档。这些文档输出后并经讨论成型后，架构师进行系统架构设计，后台开发人员进行具体编码工做。一般这个过程是耗时最长的，也是很是重要的一环。后台的架构设计水平，决定着系统重构的水平，业务代码的质量，决定着系统重构的质量。

由于这个过程比较漫长，且成果没法立竿见影。因此一般采用敏捷开发的模式，经过迭代的方式来进行后台系统重构。迭代的方式有几个好处：

• 须要将整个重构过程进行有效规划和量化，作到成竹在胸
• 每一个阶段能有可见的成果，确保团队在长时间的重构过程当中不陷于泥潭
• 对已重构好的部分能够及时进行联调测试或观察，不断在迭代中总结、在总结中迭代

另外在后台系统重构时，也须要有明确量化的目标和标准，好比各系统和业务模块支持多少 QPS，接口响应时间多长时间等，这样团队才能在重构的过程当中不至于为了重构而重构。

在重构过程当中，按期进行 Code Review，及时发现重构的问题和质量的问题，避免出现破窗效应，引入拙劣的设计或垃圾代码，进而破坏整个系统。

参与人员：技术 Leader，架构师，研发人员

六：数据迁移与检查

若是涉及数据库重构时，在新的数据库设计好后，就会有面临数据迁移的问题。通常分为全量迁移和增量迁移，全量迁移是将旧系统的数据一次性迁移到新的数据库中，增量迁移是在实行全量迁移后旧系统新产生的数据迁移到新系统上来，增量迁移一直到旧系统下线再也不产生新数据后。一般迁移都是经过编写脚本或程序来实现，拒绝人工操做。

迁移后天然须要对比新旧系统的数据，一样能够经过脚本或程序来进行对比，查缺补漏，定位分析。

参与人员：DBA，研发人员

七：系统检查、联调与测试

在后台系统重构到必定程度时，一样也须要编写脚本和程序来对新旧系统的业务接口进行检查，及时发现重构中的问题，必要时候进行架构调整和数据库调整。固然，在重构时，开发人员能提升单元测试覆盖率固然是更好不过。当各系统和模块的依赖解决的差很少时，能够开始联调工做。

固然最后还须要系统性的测试，如功能性测试、稳定性测试、性能测试，本地测试、模拟线上环境测试等。测试中发现的问题经验证修复后，达到上线的标准，便可灰度上线。

参与人员：架构师，研发人员，测试人员

八：灰度发布与观察

万里长征已经走到最后，也到了最紧要的关头。灰度发布时，只接入一小部分流量，并及时跟踪和分析线上的 log 与监控告警，一有问题及时解决。当新系统趋于稳定时，能够逐渐加大灰度发布的范围和接入的流量，同时继续跟踪线上 log 与监控告警。

参与人员：运维人员，测试人员，研发人员

九：系统切换

在系统切换时，须要提早制订系统切换方案，包含相应的规划与流程，甚至是应急预案与回滚方案，避免走一步看一步。切换完成后，新系统彻底替换旧系统，旧系统下线，完成重构。

参与人员：运维人员，测试人员

结语

经过上述几个步骤后，咱们成功对系统进行重构。

重构是一项大工程，但经历重构后的系统也并不是天衣无缝。重构不是终点，更像是起点。

关于Fundebug

Fundebug专一于JavaScript、微信小程序、微信小游戏、支付宝小程序、React Native、Node.js和Java线上应用实时BUG监控。 自从2016年双十一正式上线，Fundebug累计处理了10亿+错误事件，付费客户有Google、360、金山软件、百姓网等众多品牌企业。欢迎你们免费试用！