|
重构，是任何一个技术团队都无法绕过和回避的话题。记得10年前，我的第一份正式工作，就经历了项目持续的重构历程，为了写好代码，当时还反复读了Martin Flower的《Refactoring》。时至今日，这本书里的很多内容仍能给我很多启示。最近，回顾了一下10多年来经历的各类项目，发现还是有很多内容值得拿出来分享一下的，所以整理了这篇文章，抛砖引玉，期待大家有更多好的想法能冒出来。 关于做重构，我个人觉得可以按照以下这条线来执行。 1. 明确本次重构的目的 我的第一个观点，重构是有代价的，伴随着业务的不稳定（引入新的bug）和人力资源的投入（大家需要暂时放下业务的推进）。所以在我们动手之前，一定要明确我们本次重构的原因是什么，是为了满足业务的需要或仅仅只是觉得架构有缺陷。 每一次架构的重构都是“伤筋动骨”，就像做手术一样，即使再成功，也会伤元气。重构的首要目的一定是为了更好的满足业务需求，然后再考虑其他问题。这就意味着，如果本次重构对未来业务承接的促进很小的话（比如仅是引入新的框架和技术），那么本次重构需要慎重或者暂缓。同时，需要认真比较重构的各种方案的利弊，想清楚后再开始，任何时候都需要有方案B。 2. 明确当前系统的状态 决定要执行重构后，首要做的任务，并不是立刻动手执行重构，而是对当前的架构状态有清晰的了解。如果开发当前系统的小伙伴还在本公司，一定要和他好好的讨论一下，由作者给大家讲讲当时的思路，比我们闷头看代码理解还是要强不少的，还能清楚理解当前系统的设计初衷。除此之外，只有通过研究当前系统，才能记录目前系统的性能基准，为未来评估重构的效果做准备。过去，我遇到不少同学，还没吃透当前系统的设计和代码，就大刀阔斧的开始重构了，最终的结果很可能是引入regression bug， 或者是执行过程中，发现重构不下去了，原来这块的架构是为了达到某某业务需求啊，这块不能动，得想别的办法。 所以不吃透代码和架构，直接进行重构是很危险的，慎行。 3. 重构的目标必须被量化 如果确定要重构，那么要把目标明确下来，也就是重构的边界条件，明确列出本次重构需要完成的要点，目标要有数据量化（比如代码行数降为过去的一半，代码执行时间缩短为过去的30%等等）。同时，重构后的代码能够被有效的测试。 重构之前，需要有一个需求分析的过程，如果需求不明确，重构PRD不能写清楚，负责重构的团队也就很难有明确的目标。特别是重构工作被一个团队来执行的时候，所有的成员（包括开发成员内部，以及开发和测试之间）对重构的目标必须要达成一致，谨防重构不到位或者过度重构。 4. 重构中必须建立或维护业务数据流 现在任何一个后台系统，都会通过日志系统建立必要的业务流转记录。比如，我这几年前后带的几支团队，都会建立各类业务埋点。本质上的原因在于，业务都是以数据流为载体的，架构重构的本质就是让数据流更通畅。所以在重构过程中，我们务必保证以下两点： 1. 重构后的系统，对于数据的存储、处理、分析等功能没有影响； 2. 在重构过程中或者重构后，我们能用数据来验证重构的效果，能不断的对系统进行优化。 5. 采用“迭代式”重构 做过重构的小伙伴都知道，做重构的复杂度并不亚于做一个全新的产品，和自己的小伙伴私下沟通下来，都愿意重新做，而不是在老的代码上改。我在这里想要表达的意思在于重构并不是一个一蹴而就的事情，既然如此，那么我们就需要考虑将一次重构拆分为多次“迭代”行为，让每一个重构步骤能快速部署上线并得到反馈，以便评估重构的效果，及时作出调整。从项目风险的角度来说，通过将重构分成多个迭代，能有效的控制迭代的风险。每一个步骤，重构团队（开发和测试）都能集中一点吃透，并进行充分的测试。如果直接将重构1，2个月后的版本，一下丢给测试同学去验证，效果可见一斑。 另一方面，重构过程对bug的容忍性比新产品的研发更低，上一次重构迭代的结果，决定了下一次重构迭代的执行。不论团队多忙，一定要保证代码提交之前，是经过其他成员审核过的，短期来看会占用团队的时间，但是长期来看是事半功倍的好事。 至于如何来拆分重构，并没有一个统一的标准，我个人的观点是，每次重构的工作量，不应该超过1个正常的迭代（2周时间）。 6. 重构首选团队熟悉的技术 在我们制定重构方案过程中，第三方技术框架的选择至关重要，这关系到重构最终的成败，毕竟最后判断重构成功与否的标准是上线能否正常运行。所以，是选择最新流行的技术还是发展成熟的技术其实并不重要，重要的是我们团队能否驾驭这门技术，是否有对应的人才储备，我们是否清楚该技术里面的“坑”，是否可以找到对应的技术社区帮助我们应对执行过程中产生的问题。 在这里和大家讲一个我自己亲身经历的惨痛教训。2年前，我们在缓存方案上选择了我们并不是特别熟悉redis cluster, 而不是常规的redis 2.x版本，或者阿里云的KVStore，上线后，踩了各种坑，每次都只能事后来修复。这次经历再次说明了如果对该技术没有吃透，就将它推向生产线，将有很大的潜在风险。当然，如果现在上Redis Cluster, 我是很有信心的，因为我已经掌握了 。 对技术的选择上，我们需要反复确认各种技术方案对系统重构的影响和效果，必须要有前置的技术调研，并拿到对应的调研数据，根据数据和经验来做决策。 7. 重构前务必和业务方沟通 很多技术团队认为，重构的事情就是技术团队内部的事情，但是从我过去共事过的多个团队看，这个想法过于天真了。重构的最终目的就是改进业务和更好的承接业务，所以如果不和业务方做充分的沟通，甚至不了解业务就开始做重构，结果就是很可能没有抓到重点。例如，我们需要知道哪些关键业务的架构是不能轻易碰的，哪些业务之间是互相关联的。所以，我自己的技术团队在执行重构前，会先和产品团队，运营团队做充分的沟通。 与业务方沟通的目的有2点： 1. 了解业务方的诉求，并把这些点放入到重构过程中，梳理清楚代码中各类业务的运行情况，清楚每一项业务的重要程度。 2. 寻求业务方的支持和帮助。重构过程中，需要和业务保持积极的沟通，确保重构不会对业务产生影响。 反过来说，通过沟通，才能获得业务团队对技术团队做重构的支持和理解，重构过程中才不会碰到非技术层面上的障碍。 8. 重视重构中的非技术问题 这一点是我过去1年，理清楚的一些问题，趁这个机会分享一下： 舒缓团队的压力，给予团队更多的鼓励。 说白了，重构对个人或者团队来说通常是一件费力不讨好的事情。和做一个新产品或者新功能，能够取得老板或各业务方的掌声相比，重构的成绩往往不受老板重视，而且出了问题还要承担很大的责任。 因此，重构之前，我会提前给团队做好心理准备，打预防针，帮助大家舒缓压力，并且将重构的成果量化和业务的变化关联起来，定期向各方同步状态，得到大家的理解和支持。 做好重构过程中各种非技术沟通。任何一次较大的技术重构，都会遇到一些非技术因素，而这些因素往往不是我们所能掌控的。我们能做的就是与相关利益方进行有效的沟通，坦诚地和他们交流，非技术因素的影响是客观存在的，从公司层面来说也是合理的，对于技术人来说要学会适应。 本文转自：开发者头条 微信号：IdeaofSE |
|
|
