重构，是任何一个技术团队都无法绕过和回避的话题。记得10年前，我第一份正式工作，就经历了项目持续的重构历程，为了写好代码，当时还反复读了Martin Flower的《Refactoring》, 时到今日，这本书里的很多点，还给了我很多启示。回顾这10多年来经历的各类项目，还是有很多值得分享的点，准备分两篇文章，来过一下这些想法，抛砖引玉，期待有更多好的想法能冒出来。
关于做重构，我个人觉得可以按照以下这条线来执行：
1. 明确本次重构的目的
我的第一个观点，重构是有代价的，带来业务的不稳定（引入新的bug）和人力资源的投入（大家需要暂时放下业务的推进）。所以在我们动手之前，一定要明确我们本次重构的原因是什么？，是为了满足业务的需要或只是觉得架构有缺陷？每一次架构的重构都是“伤筋动骨”，就像做手术一样，即使再成功，也会伤元气。重构的首要目的一定是为了更好的满足业务需求，然后再考虑其他问题，这就意味着，如果本次重构对未来业务承接的促进很小的话（比如仅是引入新的框架和技术），那么本次重构需要慎重或者暂缓。同时，需要认真比较重构的各种方案的利弊，想清楚后再开始，任何时候都需要有方案B。
2. 明确当前系统的状态
决定要执行重构后，首要做的任务，并不是立刻动手执行重构，而是对当前的架构状态有清晰的了解，如果开发当前系统的同事还在本公司，一定要拉着同事好好的讨论一下，作者给大家讲讲当时的思路，比我们闷头看代码理解还是要强不少的，能清楚理解当前系统的设计初衷。除此之外，通过研究当前系统，才能记录目前系统的性能基准，为未来评估重构的效果做准备。过去，我遇到不少同学，还没吃透当前系统的设计和代码，就开始大刀阔斧的开始重构了，最终的结果很可能是引入regression BUG, 或者是执行过程中，发现重构不下去了，原来这块的架构是为了达到某某业务需求啊，这块不能动，得想别的办法。所以不吃透代码和架构，直接进行重构是很危险的，慎行。
3. 重构的目标必要被量化
如果确定要重构，那么要把目标明确下来，也就是重构的边界条件，明确列出本次重构需要完成的要点，目标要有数据量化（比如代码行数降为过去的一半，代码执行时间缩短为过去的百分之30等等），同时，重构后的代码能够被有效的测试。重构之前，需要有一个需求分析的过程，如果需求不明确，重构PRD不能写清楚，负责重构的团队也就很难有明确的目标。特别是重构工作被一个团队来执行的时候，所有的成员对重构的目标必须要达成一致，开发成员内部，还是开发和测试之间，谨防重构不到位或者过度重构。
4. 重构中必须建立或者维护业务数据流
现在任何一个后台系统，都会通过日志系统建立必要的业务流转记录，比如，我这几年前后带的几支团队，都会建立各类业务埋点。本质上的原因在于，业务都是以数据流为载体的，架构重构的本质就是让数据流更通畅。所以在重构过程中，我们务必保证以下两点，1. 重构后的系统，对于数据的存储、处理、分析等功能是否有影响；2. 在重构过程中或者重构后，我们能用数据来验证重构的效果，能不断的对系统进行优化。
（未完，更多内容会记录在下篇）
封面这本书是我非常喜欢的一本书，时常会拿出来翻翻，目前的最新版本已不是我10年前看到的第一个版本了，如果你还没看过这本书，建议深入阅读一下。
扫码关注 本订阅号： ForestNotes
网友评论