做我们的日常工作中系统重构都应该是最让人头疼的工作了，无论是错综复杂还是经意简单的系统在发展的过程中都会经历重构，而系统重构也是任何一个技术团队都无法回避的问题，在我服务的多家公司几乎每家公司都经历了一次甚至多次系统的重构，本文就我在多年的重构工作中总结出来的几点建议分享给各位朋友，希望能够给朋友们带来帮助。
1、重构确定并且聚焦目标
首先我相信我们大家都确信系统重构是会有巨大的成本投入的，业务可能需要暂缓、新系统引入的问题（BUG）带来业务的不稳定、研发人员以及配合人员的投入还有各种隐性成本等等，我们服务的是一家商业公司获取利润是最终目的，在投入具体成本做一个项目就肯定要获得收益的。重构的目标一定要能够获得更大的提升无论是业务流程还是系统性能或是其他方面，如果仅仅一个很小的改善完全没有如此的大费周章，权衡好成本是否能够获得良好的收益。
无论如何进行系统重构都是一次伤筋动骨的过程，是涅槃重生还是飞蛾扑火，完全取决我们项目执行的过程中是否明确了目标且一直聚焦于目标的实现，保持目标的聚集是能否取得良好结果的必要促销，如果我们仅仅确立了目标没有聚集于目标在多个非重要的节点投入较大资源必然会导致我们对目标的投入降低，工作中的原始资本投入都是8个小时，当然如果每个人都愿意乐于加班的话另外讨论，而我们的实际情况往往是8个小时都是不够用的，这就更加需要我们明确目标聚焦目标，把有限的资源投入到最重要的事情中，才能获得既定目标的良好结果。
2、重构要有可量化的指标
团队确认了重构的目标之后，下一步一定要将目标量化，确定好目标之后也就能够确认边界，围绕在边界内要将需要实现的事项一一罗列出来，并且尽可能对每个实现制定可以用数据清晰表现出来的指标，比如用户操作的响应时间缩短到100毫秒、单元测试的覆盖率达到80%、发现问题时长降低到30分钟以内等等，有了明确的数据指标我们才能评估最终是否获得了良好收益，这些目标必须要在重构团队，包括产品、研发、测试等等，甚至包括业务方在内达成一致，是团队的目标清晰明了，防止出现过度或是不达标是最终不能获得良好收益。
3、重构要有更好的质量
既然决定了要对系统进行一次重构，那么我们肯定要做到的就是要比之前做的更好，如果之前接口响应时间在100毫秒，而经过重构之后反而减低到了200毫秒以上那么岂不是很难看，大家辛苦付出的努力是不是也更加不值得。而进行重构往往是一件十分引人注目的事情，一个微小的问题反而容易在众人注目下变得非常严重的问题。为了减少引起不必要的麻烦，重构团队就更加要注重各个方面的问题，无论是系统性能、用户体验还是BUG数量等
4、重构之前要和业务方沟通
技术团队进行系统重构的工作的时候往往忽略掉了业务方，认为这是技术团队内部的事情，不需要知会业务方，这个想法是非常错误的，进行重构的目标就是为了改善改进业务流程，而不去和业务方提前沟通进行闭门造车，最后的结果很可能和进行重构的初衷背道而驰。进行系统重构首先我们必须了解现有系统的业务需求，是否有待改进的业务需求点，是否有新的业务诉求等这些需求往往会影响到我们重构的进度和目标，甚至出现南辕北撤的事情。
技术团队和业务方往往对待问题的出发角度不同，思考问题的方式也不同，在进行重构之前和业务方沟通获得业务方的支持，往往能够事半功倍。
例如，我的团队在进行一块业务系统重构的时候进入到了系统切换的试运行的阶段，由于拿出的方案给到业务方无法被业务方接受，业务方提出的解决方案我们还需要进行再次开放对整个项目进度影响了足足一个月时间之多。吸取教训的我们在进行下一个项目的时候提前和业务方进行了沟通，业务方从他们的角度给予了很多的意见和建议以及业务未来的发展方向的指引，我们发现这些建议和意见帮助我们更好理解业务的同时也大大的降低了我们工作量，减少了我们很多冗余的设计。
5、重构应该才用迭代的方式
参与过重构项目的朋友都知道，重构项目往往是个时间跨度很长的工作，少则一两个月多则一年半载都有，如果不将整个重构进行合理拆分，而是采用全部开发完成，再进行系统切换的方式会对整个重构引入很大的风险，首先长时间的时间跨度内业务会进行持续变更，其次团队面临长时间没有结果输出面临来自各个方面的压力还有系统问题持续累积，这种蒙头狂奔的方式往往造成了项目失败或是目标便宜，而采用迭代方式进行重构，可以以更小的颗粒度持续交付工作成果，交付-试用-反馈-调整，持续有交付，持续有反馈，持续调整能够保证团队的目标不会偏移，形成一个正向循环，保证最后的重构目标。
6、重构要清晰了解旧系统
知己知彼，百战不殆，系统重构是一个与旧系统对抗的过程，不对旧系统的弄的清清楚楚怎么能够比旧系统做的更好呢？其实了解现有系统是一个学习的过程，如果有旧系统的开发人员还在公司那么就事半功倍了，旧系统的开发同学帮忙给做次分享省去了我们重构团队很多的工作，比直接去读代码更能清晰明了的了解到旧系统的相关知识以及有哪些需求点和应该注意的问题等等，通过学习和了解旧系统设定目标基准值避免引入老旧问题也是避免重蹈覆辙的一个好办法。
7、重构要提前规划系统切换方案
不知道朋友有没有遇到过重构完系统发现如果进行新旧系统的切换是个难题，反正我是遇到过，由于没有提前做好规划和切换步骤导致最后临时抱佛脚，开始使用各种奇葩办法做系统切换，有的还需要增加额外工作量甚至各种办法的刷脸求人，总之这不是一个很好的体验。系统切换往往是在重构中被我们忽略的一个步骤，但是这是非常重要的一个环节，在做最初的计划就应该考虑到如何进行系统切换，一个设计好的切换方案也应该贯穿重构始终，避免因为切换方案引起服务不可用或是引入系统BUG。尤其是前期整个团队付出巨大努力取得了一定成果的时候在最后一步切换的时候出现问题对团队是个非常大的打击，也使得业务方对团队失去信心，带来很不必要的麻烦。
8、重构高度重视系统数据
一次系统重构大多数情况下会涉及到数据结构的修改，对数据结构进行修改必然引入很大的风险，尤其在一些老旧的业务系统重构精简业务去掉冗余数据的时候，往往需要将老数据的业务数据重新写入到新系统的数据库。重构的目标是为了比旧系统更好无论是性能还是业务方面，如果我们对数据的操作导致外部依赖旧系统的业务无法正常运行那将是影响SLA指标的问题还有，说到系统数据有些同学可能仅仅关注的是业务数据其实数据也包含了系统运行所产生的日志数据，无论新旧系统的日志数据都是很重要的，如果因为重构影响到数据的读取、处理、分析那么岂不是得不偿失的事情。
9、重构要才用成熟的技术选型
技术选型是重构工作的基石，选择一套成熟稳定的技术方案是重构项目完成的必要条件。有些时候我们引入最新版的数据库虽说会有性能提升但是也会引入一定的不稳定因素，之前我们团队在使用MongoDB的一个新版本的时候发现主从库的数据并不能很好的同步出现过丢失数据的情况，进入社区发现这个版本使用的用户很多都反馈了这个问题，这时候我们不得不选择了大多数人共同的一个选择降低了一个版本来解决问题，相信此类情况比比皆是。在不是很成熟的方案带来并不显著的性能提升反而还会引入不确定的风险的时候我们需要权衡利弊得失，重构更是要保证系统的稳定性。
技术方案能否有足够强大的支撑也是我们需要考虑的一个方面，现在我们团队面对的重构是从单体式架构往微服务转变，旧系统的版本构建在是PHP语言上，新的系统我们由两个选择继续选择用PHP进行重构或是才用公司统一的微服务框架，我们毫不犹豫的选择了使用公司统一的微服务，这样做有几个显而易见的好处。
1、和公司内部进行交互更加方便快捷；
2、可以直接获取成熟的经验；
3、基础服务有公司级的支持；
以上的好处显然对我们能否成功重构系统并且获得足够的帮助起到了显著的帮助，反而才用PHP进行微服务，公司内部并无成功经验可以借鉴，业内也并无太多可靠的方案可以进行选择。一个成熟可靠的的技术方案是我们能否更进一步的保障和基石。
10、重构更加关注重视团队成员
参与过重构的同学都知道重构工作是一项枯燥乏味的工作，往往周期长、复杂度、 难度大、牵扯广、优先级低而且很有可能是一件费力不讨好的工作，开发一个业 务方期待的新功能、新模块往往比一场翻天覆地的重构更能引起业务方的重视也 更容易获取良好结果与反馈，反而不需要承担大多的压力。而越是面对这样的情 况越是需要加大对团队的鼓励增强团队的信心，消除团队的疑虑困惑，给予团队 持续的鼓励，给整个团队注入正能量，让团队保持积极向上的团队氛围，即使面 对各种困难、问题，也始终对团队保持信心保持乐观，让大家轻松愉快的投入到 重构工作中，尽量不担负额外的压力。
以内内容均为工作中的总结反思，分享给大家希望以上的这些总结能够对大家有所帮助，文章所讲述的内容如有不足之处还望指出。
