对于系统重构有迫切需要，一般是从技术人员发起的，很少由上层领导主动要求。如果真的出现了，那说明架构设计和代码细节暴露的缺陷已经足够明显，需要认真审视和重新设计。
重构出发点
最近团队中某位成员开发的功能上线时带有BUG，导致了业务流量快速陡降。虽然最后及时回滚，没有对业务造成较大的影响，但是这件事引起了CTO的警觉。CTO后面要求技术同学对开发的代码进行当面review，发现代码整体设计较混乱，然后要求团队暂停需求的开发，对系统先进行一次重构。
重构这件事情由上层领导来推动，是比较被动的，甚至会影响团队整体的绩效；但是对于项目长时间的发展来看却是一件有利的事情。项目很多问题其实都是历史遗留下来的，技术人员本身就需要承接很多业务功能的开发，很难说服上层领导，暂停业务开发进行大的重构。这其实也间接否定了领导的能力，说明他之前设计的系统是有问题的，要进行大的改动。这种大的重构，如果由技术人员来推动，可想而知是很困难的。
幸好上层领导是技术出生，并且也关注技代码的质量，从而让这次重构有了时间和资源。
重构的出发点是代码质量出现了问题影响了开发的效率，而真正能够落地的出发点却是让领导也认可了。
如何进行重构
重构定义：在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构。本质上说，重构就是在代码写好之后改进它的设计。
1、和整个团队建立共识
对于要重构整个系统这种大型的重构，可能要耗费几个月的时间，这个时候有必要和整个开发团队建立共识，让整个团队意识到，咱们有一个大型重构正在进行，每个人都应该相应地安排自己的行动。
2、梳理现有系统的问题
和整体开发团队讨论和梳理现有系统的问题，不限定范围，只要是不合理的点大家都可以踊跃提出，确保前期能够尽量收集大家完整的意见。
从不同的维度，对现有系统的问题进行分类，把不合理的问题点都分类清楚。比如：
- 流程设计不合理：中间多了不必要的冗余流程，或者流程错乱的问题
- 数据库选型不合理：本来使用关系型数据库就能解决的问题却用了非关系型数据库
- 数据结构不合理：很多废弃和冗余字段，数据结构没有分层全是平铺的方式
- 能力设计不合理：本应该使用算法的能力，却使用工程化的方式实现了
- 代码设计不合理：重复代码多，业务逻辑和代码逻辑混在一起，日志打印不规范等等
3、优化现有系统的问题
按照问题的分级从大到小设计优化方案，先确认好优化后的技术选型和整体方案，再确认各个模块的边界和领域模型，最后再针对具体的细节优化设计。
- 确认好重构后的技术选型，比如从Java->Go, MongoDB->MySql
- 确认好优化后的整体业务流程
- 确认好优化后各个工程的边界和职责
- 定义好优化后数据模型和交互接口
- 定义好各个工程的模块设计和关键类图
- 规划对当前系统的兼容设计 从整体到细节各个流程的相关设计都完成后，拉通团队进行评估，确保大家都明确了相关的开发任务。
4、设定时间和上线计划
整体重构时间周期较长，一般基于大的模块来划分工作量，不会细化到每个功能的工作量。团队每人领取一个模块后，再进行更细粒度的设计和工作量的评估，然后每人负责的模块给出一份细化的开发计划。
确认好任务的划分和计划后，要提前规划好上线的流程，确保在业务无感知的情况下平滑过渡。
- 确认好重构系统上线的清单列表
- 确保好重构系统上线的先后顺序
- 确认好重构系统灰度上线的验证
- 确认好重构系统出现问题的兜底措施
- 如何把原来系统一步步切换到重构后的新系统
重构效果评估
重构效果的评估有几种不同方式
站在业务的角度评估：
- 后期业务需求的上线速度明显提高了
- 业务感知系统响应速度更快了
站在运维的角度评估：
- 系统性能变好了，高延时的接口明显变少了
- 系统出BUG的概率变低了，稳定性更高了
- 系统查问题的速度更快了，能够快速支撑业务的各种疑问
站在开发的角度评估：
- 代码更加简洁，职责更加明确，理解代码更容易
- 相关能力都已经抽象，后续开发效率更高
- 代码的可扩展性很强，后续业务需求开发很简单
大家有没有进行系统整体重构的体验，欢迎一起讨论交流。
