遗留系统重构的模式与原则

设计模式强调为开发大规模系统提供可复用的设计指南。 —— 《反模式：危机中软件、架构和项目的重构》

就重构的基本原则来说，倒也不是很复杂：

• 小步前进。走一小步，提交一次代码，方便回滚，有一天你会懂的。
• 随时可用。如果不能保证随时可用，那就说不上是重构了。
• 融入日常。

当你习惯了重构，记得在日常工作中使用。

重构模式：EPDCA

我尝试从书中找到一个合适的模式，但是都没有发现符合我的步骤。便在 PDCA 的前面加了个 E，代表了 evaluate：

1. 识别需要重构的地方
2. 制定重构计划，
3. 执行计划的重构任务
4. 使用测试对重构是否影响业务功能进行检察
5. 调整下一次重构策略

对系统进行大规模重构的过程中，最难的地方在于识别，因为代码坏味道多的地方不一定是价值最高的。寻找你的价值曲线，寻找价值高、实施难度低的部分，是最体现你价值的地方。

四级重构

实践的过程中，我们以拆解的方式，一步步由系统架构到代码级拆分。在某次吃饭的过程中，我发现不太对劲。我明明用的是敏捷式的重构方式，而非瀑布模式。它对应于四个不同的重构级别：

• 架构重构。在不改变业务逻辑的情况下，根据单一职责和依赖倒置原则的思想：对系统进行模块拆分与合并，以明确职责降低耦合度；对包进行重新规划，划分包之间的边界，减少代码间的耦合。
• 模型重构。在包含测试的情况下，通过识别和发现模型的行为，将行为聚合到模型中：根据方法名称、参数、返回判定内聚到模型中；从流程梳理是否符合业务场景 。
• 模式重构。对于特定代码坏味道产生的问题，通过结合架构模式、设计模式来提升可读性。如：使用工厂模式统一管理对象的创建；使用策略模式降低复杂度。
• 代码重构。对于一些小的代码坏味道，可以通过 IDE 重构来快速改善即有代码，而不会影响到业务功能。如：复杂条件语句的提取；使用参数对象重构参数过多。

对应的模式如下图所示：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xzU7BDon-1578581150861)(https://migration.ink/images/refactoring-levels.png)]

这一点倒是与我们设计系统的时候，采用的《架构金字塔》颇为一致的：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4HUMc1Lt-1578581150862)(https://migration.ink/images/architecture-primard.jpg)]

小步前进

小步前进，拉一下最新的代码。

不论改动的大小，一旦变动的文件多了，如移包、重命名用得广泛的类等等，记得随时提交。

多说无益，步子迈大的时候，你就会回到这句话上。

Git 工作流

如果你们使用的版本控制工具，还不是 Git 话，那么你们可能需要好好反思一下，为什么会到现在的这种地步？

Master 机制

或许因为我合作的同事主要是 ThoughtWorks 的员工，所以在项目合作上，代码水平并不会太差；或许因为我能容忍那些年轻的开发人员犯的错。

我是一个喜欢用 master 分支的开发人员，主要是作为一个 Tech Lead，我并不想成为一个专职的 code reviewew。

所以，在 master 分支上重构，对于每个人都是一个极大的考验。有没有足够的测试覆盖？有没有足够的工程支持？有没有配合的团队合作？

PR 机制

对于采用 pull request / merge request 机制的团队来说，重构并不会一帆风顺。

对于大的重构来说，如目录调整，你还能在花点时间重做。如果是代码重构，一旦重来的话，你可能会忘记你到底修改了什么。

也经常不得不找个夜深人静的时间，加会班，提交上代码。

所以，当你采用 PR 机制的时候，记得做一下笔记，写写你打算怎么改。

建立远景与方向

TBD

拉通：对齐目标

会遇到不一样的需求，有的是明确的重构需求，有的则是隐藏在需求之后，有的则是看上去没有而已。

明确潜在风险

你懂的。

人评估

并非很有的人都具备足够的能力参与到重构的过程中。

所以，在我们进入重构之前，需要：

• 确保对方有足够的能力
• 确保和对方对于重构有共同的看法
• 确保对方能配合你工作

为此，需要一些培训，又或者是激烈的讨论。

他/她们需要具备以下的基本技能：

• 理解面向对象设计
• 了解设计模式
• 了解写测试的重要性
• 了解为什么要重构
• 追求代码质量

当然了，在了解的基本上有更深入的理解也是不错的。

重构范围

对于一个大的系统来说，系统的每一部分并非都是等价的。

系统的核心就是系统的 core domain（核心域），一个有能力的管理者，能识别到哪一部分是系统的核心组成，并为它分配最好的开发人员；与此同时，对于支撑的部分来说，管理者只会分配少数的核心开发人员，只用于确保功能能按期完成。

按照 DDD 的思想来看，就是核心域、支撑域、通用域的区别。

产出物

KPI 度量

重建规范

团队赋能

原则与模式

详细内容见：https://migration.ink/