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

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

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

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

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

重构模式: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/

发布了649 篇原创文章 · 获赞 943 · 访问量 153万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 代码科技 设计师: Amelia_0503

分享到微信朋友圈

×

扫一扫,手机浏览