谈谈系统重构

近来公司系统重构，我作为主力军之一，面对系统重构，既兴奋又恐惧。兴奋在于我可以将自己对设计模式、架构模式、编程理念、工作以来的开发教训等运用到系统重构中；恐惧在于我担心这次重构万一不成功岂不是打自己的脸。

关于系统重构，我极其小心，为此我花了近一天的时间阅读了许多重构文章，也仔细回顾自己以前做系统设计和二次开发的教训，力图使这次系统重构能够成功。其实做了以后发现这次系统重构并没有我想象的那么难，也许是如今的我比过去更强大的原因。

A架构:数据存取服务-业务逻辑服务-Web接口服务(号称三层架构体系)。

B架构:将要改造的，将数据存取服务、业务逻辑服务、Web接口服务合为一个。

一、系统重构的背景以及原因有哪些？

A架构是当前的架构，为了应对未来的需求以及解决当下的一些问题，不得不由A架构演变为B架构。其实A架构从当初的角度出发，也有其有利的地方，只不过唯一不变的是变化，所以必然要演变为B架构。也许B架构早晚有一天也得淘汰，得演变为新的架构。这就是系统重构得背景以及原因。

关于一些问题，其中比较突出的问题是，按照业务功能分类，从A架构的角度出发居然要有三个微服务(其实一个微服务就能搞定，没有必要写三个)，随着业务不断增加，微服务越来越多，这种多直接导致微服务管理的难度系数上升以及各种不利的连锁反应。

二、采用B架构的目的是什么？

• 让接口开发和接口调试变得更简单，减少不必要的步骤；
• 降低服务之间的通信成本；
• 减少代码冗余；
• 提高代码的可扩展性、增加代码的可读性；
• 日志统一，便于问题排查；
• 降低服务耦合，更体现职责单一原则。

三、从A架构演变为B架构的难点有哪些？

• 从低层(数据存取服务)到高层(Web接口服务)，需要重写代码，因为演变的过程中需要去除一些冗余；
• 演变的过程中确保前端系统不会因为后端系统的重构而发生大的改动或小的改动(前端不能动)；
• 需要通读代码，梳理业务，一点点调试，小步前进，需要有耐心，不能粗心大意，考虑尽可能要全面。

四、明确了目的和难点，你的方案是什么？

我的方案很简单，Web接口微服务特别是与前端密切相关的(参数和响应结果)保持不变，数据存取服务相关的XML和Dao进行复用，业务逻辑服务以及数据存取服务部分重写与合并。
最终归纳出具体的方案流程如下:

• (1)通读代码，理清业务，梳理流程(三个服务是如何交互的)；
• (2)自顶向下，复用Web接口服务的Controller；
• (3)自底向上，复用数据存取服务的XML以及DAO；
• (4)中间兼容，业务逻辑重写上层Web接口服务的Controller与数据存取服务的XML以及DAO，使其匹配上层Web接口以及下层数据存取；
• (5)完成(1)~(4)后，通过PostMan或集成Swagger这样的接口自动化工具进行测试，确保合并后服务的正常运行；
• (6)提交代码发布开发环境进行前端联调；
• (7)通过在前端系统操作验证，确保合并的最终成功和问题最小化；
• (8)基于(7)成功后，合并到主开发分支并推送。

主开发分支:相当于开发人员的正式分支，平时开发人员对于新的功能均在自己分支上开发-接口调试-最后合并到主开发分支并交由运维进行发布，让测试人员进行测试。

五、你觉得系统重构最重要的是什么？

最重要的我认为有这么几点:

• 明确重构的目的(为什么要重构)；
• 一定要通读相关代码，熟悉业务以及理清楚流程(业务不熟悉，流程不清楚可找相关人员请教)；
• 与直属领导进行沟通，沟通具体的方案以及重构优先级(有些功能优先级高，有些功能优先级低)；
• 落地方案并在实践中不断调整(具体问题，具体分析、具体解决)；
• 要克服畏难情绪并自我激励，因为系统重构会遇到各种各样的奇葩问题，这些问题很容易使你打退堂鼓；
• 小步前进，逐步迭代，拒绝贪多(慢即是快，稳妥第一，速度第二)。

六、小结

荀子有一篇文章叫《劝学》，其中有一句话我印象很深刻，那就是”君子性非异也，善假于物也”。在系统重构的时候，我没有盲目直接动手，过去盲目的例子太多了，人要学会吸取教训，这样才能不断进步，而是参考前人的经验教训并结合实际情况而落地具体系统重构方案。

感谢以下博友的文章给了我系统重构一些启发:

系统重构的十点经验

系统重构的道与术

遗留系统重构的三个原则

《系统重构与迁移指南》

重构不得不考虑的两个问题

有关系统重构那些事儿