系统级重构的体会

前言

最近刚刚帮助一个团队完成一个系统的重构和迁移的工作，又团队有进行一个老系统的架构重构。因此最近对于系统级的重构有所体会，在此记录一下。

重构过程

系统级重构由于涉及范围广，难度大，风险高，而且很难得到管理层的理解，成为大家避之不及的工作，于是各种老系统都难得得到浴火重生的机会，基本是修修补补，开发人员换了一批又一批，最终都避免不了成为一个大泥球型的架构，不得不推翻重做。

项目分析

在开始之前一定要跟团队认真的分析项目重构的必要性，一般来说重构原因不外乎下面的几点：
1. 遗留系统，无法维护；
2. 系统所用的技术体系严重脱离时代，没有足够的人员提供技术支持。
3. 所用的技术无法满足业务的需求，
4. 所用技术无法满足系统的新的性能要求
还需要更老板解释重构的好处，比如:提高运维与开发效率，提高可靠性等等.
此外还有一个重要的事情必须要做就是估计重构的工作量，这个是每个管理层都关心的问题，毕竟重构也是要给大家发工资的啊。

技术选型

既然是系统级的重构就往往避免不了技术上的更新换代，也就涉及到技术选型的问题，总的来说要根据实际情况进行选型。
这个实际情况主要包括三方面的因素：
1.业务需求和潜在需求
毕竟项目都是为了业务才进行的，偏离了这个本源重构的意义就无从谈起。
2.团队情况
重构是要团队来实现，重构后的项目也是团队来运维，重构选了一种团队没人会的技术，要么是准备挖坑然后跑路，要么是别无选择，所以技术选择要根据开发团队的实际情况来进行。
3.技术发展
这个就不必细说了，要贴合时代潮流 否则过一段时间还需要重构甚至是推倒重来。

工作量估计与制定计划

技术定型后要召集团队进行更为详细的工作量估算，然后制定开发计划，再然后上报管理层，这个过程是必不可少的。

初步迁移

既然是系统级的重构就避免不了系统的架构和框架上的调整，这个过程最好由一个人来完成，至少完成整个架子的搭建，同时找一个最有代表性的模块进行重构，在重构的过程中就重构的范围，重构后的标准达成一致，完成后正好可以作为一个示例给初级开发人员参考。
这个过程最重要的几点：
1. 框架搭建；
2.各层示例；
3.建立统一标准。

分工协作

接下来就是整个团队开始重构的工作，根据开发计划来查看进度，与测试人员一起查看重构后的项目质量。
重构过程千万别忘了与测试，测试能够给重构提供安全网，这将节省大量时间和人力。

验收

完成后，当然是给管理层进行一次演示，并且提供重构消耗的资源，最好还能提供重构后在什么地方更好，比如我们可以更快的响应用户的需求，比如我们的可靠度提高了多少。这将极大的转变管理层对于重构的态度。
与其希望管理层能够了解技术，不如将技术领域的问题转换为他们关心的指标。

注意点

控制范围的诱惑

重构也是分层级的，切勿盲目进行优化，系统级的重构主要关注的是技术体系的更替，核心框架的升级或架构的调整，而非重命名了多少个方法，要把注意力放到重要的事情上，一次只做一件事情。可以把发现的问题都记录下来，后面进行小型重构专注于技术债务的清理。

抵制技术的诱惑

没有最好的只有合适的，在技术选型时一定要结合业务需求以及开发团队的实际情况，切忌过分追求新技术，在进行新技术切换时一般是通过小型项目进行试验和论证，并给团队一定的时间进行缓冲，才能逐步在正式项目中展开，否则新技术只会带来混乱。

一切以业务为导向

在公司中一切是以业务为导向，项目尤其是大型项目不是进行技术研究的地方，所有的一切都要为用户为公司创造更高的价值才有意义，不能再技术中迷失方向。