设计模式强调为开发大规模系统提供可复用的设计指南。 —— 《反模式：危机中软件、架构和项目的重构》
就重构的基本原则来说，倒也不是很复杂：
- 小步前进。走一小步，提交一次代码，方便回滚，有一天你会懂的。
- 随时可用。如果不能保证随时可用，那就说不上是重构了。
- 融入日常。
当你习惯了重构，记得在日常工作中使用。
重构模式：EPDCA
我尝试从书中找到一个合适的模式，但是都没有发现符合我的步骤。便在 PDCA 的前面加了个 E，代表了 evaluate：
- 识别需要重构的地方
- 制定重构计划，
- 执行计划的重构任务
- 使用测试对重构是否影响业务功能进行检察
- 调整下一次重构策略
对系统进行大规模重构的过程中，最难的地方在于识别，因为代码坏味道多的地方不一定是价值最高的。寻找你的价值曲线，寻找价值高、实施难度低的部分，是最体现你价值的地方。
四级重构
实践的过程中，我们以拆解的方式，一步步由系统架构到代码级拆分。在某次吃饭的过程中，我发现不太对劲。我明明用的是敏捷式的重构方式，而非瀑布模式。它对应于四个不同的重构级别：
- 架构重构 。在不改变业务逻辑的情况下，根据单一职责和依赖倒置原则的思想：对系统进行模块拆分与合并，以明确职责降低耦合度；对包进行重新规划，划分包之间的边界，减少代码间的耦合。
- 模型重构 。在包含测试的情况下，通过识别和发现模型的行为，将行为聚合到模型中：根据方法名称、参数、返回判定内聚到模型中；从流程梳理是否符合业务场景 。
- 模式重构 。对于特定代码坏味道产生的问题，通过结合架构模式、设计模式来提升可读性。如：使用工厂模式统一管理对象的创建；使用策略模式降低复杂度。
- 代码重构 。对于一些小的代码坏味道，可以通过 IDE 重构来快速改善即有代码，而不会影响到业务功能。如：复杂条件语句的提取；使用参数对象重构参数过多。
对应的模式如下图所示：
这一点倒是与我们设计系统的时候，采用的《架构金字塔》颇为一致的：
小步前进
小步前进，拉一下最新的代码。
不论改动的大小，一旦变动的文件多了，如移包、重命名用得广泛的类等等，记得随时提交。
多说无益，步子迈大的时候，你就会回到这句话上。
Git 工作流
如果你们使用的版本控制工具，还不是 Git 话，那么你们可能需要好好反思一下，为什么会到现在的这种地步？
Master 机制
或许因为我合作的同事主要是 ThoughtWorks 的员工，所以在项目合作上，代码水平并不会太差；或许因为我能容忍那些年轻的开发人员犯的错。
我是一个喜欢用 master 分支的开发人员，主要是作为一个 Tech Lead，我并不想成为一个专职的 code reviewer。
所以，在 master 分支上重构，对于每个人都是一个极大的考验。有没有足够的测试覆盖？有没有足够的工程支持？有没有配合的团队合作？
PR 机制
对于采用 pull request / merge request 机制的团队来说，重构并不会一帆风顺。
对于大的重构来说，如目录调整，你还能在花点时间重做。如果是代码重构，一旦重来的话，你可能会忘记你到底修改了什么。
也经常不得不找个夜深人静的时间，加会班，提交上代码。所以，当你采用 PR 机制的时候，记得做一下笔记，写写你打算怎么改。