系统重构的道与术

最近参与了很多重构项目，有以提高服务器资源利用率为目标的Gateway网关、AMAPS等服务的重构，也有以提升架构合理性和研发效率为目标的共享业务服务化拆分，借此机会把相关内容梳理一下，是分享更是自我总结和学习。准备以重构工作中容易产生误区的地方或容易被忽视的重点来聊聊，既不重复网上千篇一律的各种方案资料，也对重构工作有参考价值。

什么是“道和术”？个人简单的理解，道就是思想，术是方法。可谓有道无术，术尚可求也；有术无道，止于术。分别从重构的基本思路和原则，以及常见重构方案的应用来分别讲讲系统重构的“道与术”。

一、系统重构之道

现在是进行重构的恰当时机吗？重构前需要做什么准备？如何保障重构工作顺利完成并达成预期目标？从这几个大家都关心的问题，来谈谈重构工作遵循的基本思路和原则。

从实际问题出发

“不能解决实际问题的重构就是耍流氓 ”，从实际问题出发，切勿为了重构而重构，看似简单的道理，但现实中确实存在为了重构而发起的重构，或许是想应用诱人的新技术，或许是为了跟上流行趋势，甚至有自己主动YY需求而发起的重构。作为工程师我们需要谨记系统稳定高于一切，任何重构都存在风险，没有业务收益的重构相当于平白让业务承担非必要的风险，这是一种极不负责的表现。

所以，发起重构项目时，先想明白要解决什么实际问题，是为了提升性能？还是加强安全？或是为了快速的持续集成和发布？想明白再行动。

设定明确目标

目标是否明确很大程度上决定了事情的最终效果，重构项目也是如此。在组织管理、目标管理课程上经常会提及目标设定的SMART原则，同样，重构项目也要有具体的、可衡量、可执行、可实现、且有时间限制的目标，可执行、可实现、且有时间限制这三者好理解，重点讲讲具体可衡量，上面提到的待解决问题可不可以作为重构项目的目标吗？答案不可以，问题就出在具体可衡量上，就拿以解决性能问题的重构项目为例，目标应该是服务响应RT要降多少? 或是单核QPS承载量提升多少？甚至也可以是服务器资源