如何做系统重构(下)

前两天完成了《如何做系统重构》上半部分，今天的内容沿着上部分来继续展开下去。上半部分写了4点，那么下半部分继续写4点。

5. 采用“迭代式”重构

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

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

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

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

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

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

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

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

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

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

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

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

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

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

关于重构的话题就先告一段落了，大家有任何想法和建议，请留言与我联系，希望得到大家更多的反馈。

封面是我另外一本喜欢的重构相关的书，通俗易懂，将重构中常见的一些模式都介绍到了，而且还提出了很多有价值的建议，大家有兴趣的话，可以读读。

                                                 扫码关注 本订阅号： ForestNotes