如何做系统重构

重构，是任何一个技术团队都无法绕过和回避的话题。记得10年前，我第一份正式工作，就经历了项目持续的重构历程，为了写好代码，当时还反复读了Martin Flower的《Refactoring》, 时到今日，这本书里的很多点，还给了我很多启示。回顾这10多年来经历的各类项目，还是有很多值得分享的点，准备分两篇文章，来过一下这些想法，抛砖引玉，期待有更多好的想法能冒出来。

1. 明确本次重构的目的

我的第一个观点，重构是有代价的，带来业务的不稳定（引入新的bug）和人力资源的投入（大家需要暂时放下业务的推进）。所以在我们动手之前，一定要明确我们本次重构的原因是什么？，是为了满足业务的需要或只是觉得架构有缺陷？每一次架构的重构都是“伤筋动骨”，就像做手术一样，即使再成功，也会伤元气。重构的首要目的一定是为了更好的满足业务需求，然后再考虑其他问题，这就意味着，如果本次重构对未来业务承接的促进很小的话（比如仅是引入新的框架和技术），那么本次重构需要慎重或者暂缓。同时，需要认真比较重构的各种方案的利弊，想清楚后再开始，任何时候都需要有方案B。

2. 明确当前系统的状态

决定要执行重构后，首要做的任务，并不是立刻动手执行重构，而是对当前的架构状态有清晰的了解，如果开发当前系统的同事还在本公司，一定要拉着同事好好的讨论一下，作者给大家讲讲当时的思路，比我们闷头看代码理解还是要强不少的，能清楚理解当前系统的设计初衷。除此之外，通过研究当前系统，才能记录目前系统的性能基准，为未来评估重构的效果做准备。过去，我遇到不少同学，还没吃透当前系统的设计和代码，就开始大刀阔斧的开始重构了，最终的结果很可能是引入regression BUG, 或者是执行过程中，发现重构不下去了，原来这块的架构是为了达到某某业务需求啊，这块不能动，得想别的办法。所以不吃透代码和架构，直接进行重构是很危险的，慎行。

3. 重构的目标必要被量化

如果确定要重构，那么要把目标明确下来，也就是重构的边界条件，明确列出本次重构需要完成的要点，目标要有数据量化（比如代码行数降为过去的一半，代码执行时间缩短为过去的百分之30等等），同时，重构后的代码能够被有效的测试。重构之前，需要有一个需求分析的过程，如果需求不明确，重构PRD不能写清楚，负责重构的团队也就很难有明确的目标。特别是重构工作被一个团队来执行的时候，所有的成员对重构的目标必须要达成一致，开发成员内部，还是开发和测试之间，谨防重构不到位或者过度重构。

4. 重构中必须建立或者维护业务数据流

大家有任何想法和建议，请加我的JAVA架构进阶群：554355695

现在任何一个后台系统，都会通过日志系统建立必要的业务流转记录，比如，我这几年前后带的几支团队，都会建立各类业务埋点。本质上的原因在于，业务都是以数据流为载体的，架构重构的本质就是让数据流更通畅。所以在重构过程中，我们务必保证以下两点，1. 重构后的系统，对于数据的存储、处理、分析等功能是否有影响；2. 在重构过程中或者重构后，我们能用数据来验证重构的效果，能不断的对系统进行优化。

5. 采用“迭代式”重构

做过重构的小伙伴都知道，做重构的复杂度并不亚于做一个全新的产品，和自己的小伙伴私下沟通下来，都愿意重新做，而不是在老的代码上改。在这里说这个话的意思在于重构并不是一个一蹴而就的事情，既然如此，那么我们就需要考虑将一次重构拆分为多次“迭代”行为，然后每一个重构步骤能快速部署上线并得到反馈，以便评估重构的效果，及时作出调整。从项目风险的角度来说，通过将重构分成多个迭代，能有效的控制迭代的风险，每一个步骤，重构团队（开发和测试）都能集中一点吃透，并进行充分的测试。如果直接将重构1，2个月后的版本，一下丢给测试同学去验证，效果可见一斑。

另外一方面，重构过程对bug的容忍性比新产品的研发更低，上一次重构迭代的结果，决定了下一次重构迭代的执行。不论团队多忙，一定要保证代码提交之前，是经过其他成员审核过的，短期来看会占用团队的时间，长期来看是事半功倍的好事。

至于如何来拆分重构，并没有一个统一的标准，但是我个人的看法，每次重构的工作量，不应该超过1个正常的迭代（2周时间）。

6. 重构首选团队熟悉的技术

在我们制定重构方案过程中，第三方技术框架的选择至关重要，这关系到重构最终的成败，毕竟最后判断重构成功与否的是上线正常运行，所以是选择最新流行的技术还是发展成熟的技术其实并不重要，重要的是我们团队能否驾驭这门技术，是否有对应的人才储备，我们是否清楚该技术里面的“坑”，是否可以找到对应的技术社区帮助我们应对执行过程中产生的问题，在这里可以和大家讲一个我自己经历的惨痛的教训，2年前，我们在缓存方案上选择了我们并不是特别熟悉redis cluster,  而不是常规的redis 2.x版本，或者阿里云的KVStore，上线后，踩了各种坑，每次都只能事后来修复，充分暴露了如果对该技术没有吃透，就将它推向生产线，那就有很大的潜在风险，当然，如果现在上Redis Cluster, 我是很有信心的，因为我已经掌握了 :) 。对技术的选择上，我们需要反复确认各种技术方案对系统重构的影响和效果，必须要有前置的技术调研，并拿到对应的调研数据，根据数据和经验来做决策。

7. 重构前务必和业务方沟通

很多技术团队认为，重构的事情就是技术团队内部的事情，但是从我过去共事过的多个团队看，这个想法过于天真了，重构的最终目的就是改进业务和更好的承接业务，所以如果不和业务方做充分的沟通，甚至不了解业务就开始做重构，结果就是很可能没有抓到重点，例如，我们需要知道哪些关键业务的架构是不能轻易碰的，哪些业务之间是互相关联的。所以，我自己的技术团队在执行重构前，会和产品团队，运营团队做充分的沟通。

与业务方沟通的目的有2点：

了解业务方的述求，并把这些点放入到重构过程中，梳理清楚代码中，各类业务的运行情况，清楚每一项业务的重要程度。

寻求业务方的支持和帮助，重构过程中，需要和业务保持积极的沟通，确保重构不会对业务产生影响。 反过来说，通过沟通，才能获得业务团队对技术团队做重构的支持和理解，重构过程中才不会碰到非技术层面上的障碍。

8. 重视重构中的非技术问题

这一点是我过去1年，理清楚的一些问题，趁这个机会分享一下：

舒缓团队的压力，给予团队更多的鼓励。说白了，重构对个人或者团队来说通常是一件费力不讨好的事情。和做一个新产品或者新功能，能够取得老板或各业务方的掌声相比，重构的成绩往往不受老板重视，而且出了问题还要承担很大的责任。 因此，重构之前，我会提前给团队做好心理准备，打预防针，帮助大家舒缓压力，并且将重构的成果量化和业务的变化关联起来，定期向各方同步状态，得到大家的理解和支持。

做好重构过程中各种非技术沟通，任何一次较大的技术重构，都会遇到一些非技术因素，而这些因素往往不是我们所能掌控的。我们能做的就是与相关利益方进行有效的沟通，坦诚地和他们交流，非技术因素的影响是客观存在的，从公司层面来说也是合理的，对于技术人来说要学会适应。