什么是重构？
重构是在不改变现有代码行为下，对代码的结构进行调整，提高代码的可读性，可理解性，降低我们在变更时候产生的成本，说白了应该定义为一种提升效率的行为，而不是由程序员自身道德驱动的行为。
什么时候应该进行重构？
随着业务发展到一定程度，可能大部分的开发者在阅读项目代码的时候都有相同的感觉：这个代码好难理解，冗余的代码写的到处都是，各种乱七八糟的命名，平铺直叙。其实在无形中已经提升了整个项目的维护成本了。新来的小伙伴刚接手这个项目，不能马上上手，可能要花费几周的时间去理解代码，稍有不慎的一点改动，就会引发一系列连锁bug，其实在无形中已经大大增加了整个项目的迭代成本。
- commit代码或者review应该就去考虑当前的代码有没有可以优化的地方
- 在代码已经非常混乱的情况下，建议说服产品作为内部需求来做
代码的坏味道
1 依赖传递：在我经手的一些项目中也遇到该问题，将一些代码抽成一个模块，为了是多个服务可以一起复用这个模块，一些共有的业务也就下沉到该模块。随着项目发展，不同的服务的相同业务产生了差异化，这个时候各个模块就产生了交叉耦合，牵一发而动全身。
2 变更放大：代码层次结构划分不清晰，各个模块之间耦合严重，开发一点新的业务，要去修改好几处地方，相信这也是大家经常遇到的问题。所以在设计功能模块的时候，要尽量让模块高内聚，低耦合。
3 代码的可读性：下面的场景开发者应该也遇到过，当你去修改现有业务的一点问题时候，发现要去通读上下文代码才能理解这个当初为什么这样写。这里很大一个原因就是代码没有进行封装，也没有方法抽取，直接平铺直叙。通过方法抽取，清晰的方法命名，我们能够很快去理解这一步是要做什么事情，而不需要去关注其中的细节
4 架构风格混乱：大型的项目在进行开发的时候一般会有很多开发者一起参与，每个开发者都有自己写代码的一套风格，可能每个人的风格都很好，但是杂在一起就成了泥团。所以还是要去制定开发标准，代码规约。
5 过度设计：代码的过度封装，超前设计，会带来业务代码的复杂度。因为业务并不是按照一种既有的路线去平稳发展，而是千变万化。
重构的流程：
- 代码分析：通读代码，发现复杂度存在的地方，根据复杂度梳理相应的整改文档，不同复杂度之间还要有优先级的划分
- 定目标：重构要达成什么目标
- 小步快跑：围绕文档开始进行工作量拆分，尽可能地细化成小任务，快速完成，快速交付。不一蹴而就，大范围整改，尽可能将风险控制在一定的范围内
- 提交规范：提交的时候要制定相应的规范，清晰地描述变更的内容
- 测试：很多人明明觉得一个代码不行，却不敢动它，根本原因还是怕引出问题。所以在重构的时候也要注重测试体系的建立。无测试，不重构，建立好单元测试，集成测试和自动化测试体系。有这些体系的支撑，能帮助我们更好地控制风险
