作者: Phodal Huang 2020年10月26日 20:25

一年前，在公司大佬的指点之下，我开始写系统级重构工具 [Coca](https://github.com/phodal/coca) (https://github.com/phodal/coca) 。哦，不，不对，是刚开始学习 Golang，因为我的第一次提交是从一个 Go 的 `hello, world` 写起的。 ``` commit a685d69080a7abde684e1d0707cbf410092e3173 Author: Phodal HUANG Date: Tue Oct 22 23:01:19 2019 +0800 first commit commit c6b5a0c7f174c6a0ba233a1356aca5c370ba4315 Author: Phodal HUANG Date: Tue Oct 22 23:06:04 2019 +0800 learn: add hello world ``` 时过境迁，这个小工具已经不小了 —— 即使是这个项目的作者，我也要看我写的 README，才会想起来有这么一些功能。这一年来，根据我的一些工作上的需要，陆陆续续地也添加了一些颇为有意思的特性。这些小特性除了不限制编程语言，还可用于指导重构，还可以用于写 PPT 的时候讲述故事： - 高频修改文件查找 - 包结构分析（不限于 Java，大部分的语言是以目录划分包结构的） - Todo 分析（可结合历史） 当然了，如果你的系统是 Java 语言主导的话，那么 Coca 能提供更强有力的支撑，具体见：https://github.com/phodal/coca 。只是呢，不管我们使用的是什么工具，我们方法论都是类似的。也因此《系统重构与迁移指南》（https://migration.ink/) 成为了系统重构不可多选的材料，Google 『系统重构』 和 『重构工具』会有惊喜。 ## 系统的必然之路：系统重构 or 重写 没啥说的，部分的系统都是要被重构或者重写的。那么另外一部分呢？他们被淘汰了——要么是产品，要么是公司，笑~。 真相就是这么简单。如果系统不被指南，和进行频繁的代码级重构的话，那么系统被取代的速度就更快了。 ## 重构 vs 重写 关于系统级别的重构，我们先要讨论的第一个问题其实蛮简单的：我到底是要重构还是重写？选择哪个主要取决于：你要的是技术挑战，还是业务挑战？ 哦，不，不对，它取决于你要的是 KPI 是技术 KPI，还是非技术 KPI？ 说白了，就是价值决定了一切。 对于重构而言，我们所要面对的是技术挑战；对于重写而言，我们所面对的是业务挑战。 ### 重构的技术挑战 我们所面临的主要技术挑战是： 1. 是否能确保过程的安全性？如何设计测试防护网 2. 是否能想到更好的设计来取代现有的方案？ 3. 如何做一次有效的分析与评估？ 4. 如何渐进式的重构系统？如何保持小的、快速的提交 5. 怎样支持未来业务的可扩展？即，支撑业务可扩展性 6. 是否寻找最合适的重构技巧？比如通过 IDEA 的重构 7. 如何让重构技能被传承？即，多数团队成员都能快速上手 8. …… ### 重写的业务挑战 与重构不同的事，重写时的挑战主要是来自于梳理现有业务： 1. 如何体系化的整理现有的业务？ 2. 如何剔除已淘汰的业务？ 3. 如何确保主干业务的完整性？ 4. 是否能确保细小的业务功能不被遗失？ 5. 能否设计出更完善的业务知识管理体系？ ## 系统重构的未来 在 Coca 编写完成之后，我发布了《系统重构与迁移指南》一份短小、精悍的重构手册。从这个手册快速的自然增长率（GitHub star 指标，没有经过大量宣传），并且已经在 Google 的相关关键字下（如系统重构、重构策略等）排名第一，我发现了人们缺少一份这样的指南和工具。 所以，在未来一定会有更多的相关工具诞生，并配套有大量的实践指南。 ### 方法论支撑 在开始重构之前，我们需要**设计出可行的重构方案**，这也就是方法论的支撑。 对于重构的方法论来说，实现上我们已经可以在市面上找到大量的相关书籍，只需要结合起来看就可以了： - 《重构与模式》 - 《设计模式：可复用面向对象软件的基础》 - 《重构：改善既有代码的设计》 - 《领域驱动设计：软件核心复杂性应对之道》 - 《修改代码的艺术：构建易维护代码的 9 条最佳实践》 - 《代码整洁之道》 - 《架构整洁之道》 - 《数据库重构》 - 《遗留系统重构指南》 - 《前端架构：从入门到微前端》 ### 工具支撑 市面上，已经充斥着大量代码级重构的工具，如 JetBrians 系列的 IDE。但是，对于系统级重构来说，基本上很少有工具可以直接能支撑现有的系统，哪怕是 Coca 也是有限的支持。主要原因就是：大部分的内部系统都绑定了组织中的模式。特别是对于大型组织来说，它们往往配套开发了自己的底层架构和 API。 也因此，对于系统级别的重构来说，我们要优先考虑的是定制一个工具，又或者是基于开源工具进行扩展。 ### 操作指南支撑 同样的，我们也很难在市面上找到这样的指南，因为对于大部分的公司和团队来说，重写是更好的 KPI，而重构并不会带来如此丰富的价值。除此呢，对于有过重构经验的团队来说，他们也不一定会共享出自己的经验——受能力和保密协议影响。 于是乎，我开始不断丰富我的指南《系统重构与迁移指南》。 ## 其它 > 软件开发总成本 = 开发成本 + 维护成本；软件维护成本 = 理解成本 + 修改成本 + 测试成本 + 部署成本。—— Ken Beck

标签:
• coca
• legacy-system

作者: Phodal Huang 2020年7月20日 20:19

最近，因为公司项目的原因，对一个大型的系统做了一个简要的架构分析。由于，时间上的限制，所以在这里我也只能做一个快速的分析，并没有其它的可能性。 太长不看版步骤： 1. clone 项目的代码，以及相关的依赖 2. 尝试编译系统 3. 借助目录 + 编辑器进行初步分析 4. 借助工具进行可视化分析 5. 配置 IDE，进行源码分析 6. 绘制架构图 7. 从用户旅程验证架构正确性 8. 总结输出 9. 回溯版本，进一步验证 PS：这里所针对的情况是，没有现有架构图的情况。如果已经有现成的架构，那么它的步骤应该是不一样的。依我之间的经验来看，它应该是这样的： 1. 寻找架构图 2. 寻找相关的阅读代码文档、日记 3. 其它同上 ## 0. clone 多数情况下，把远程的代码 clone 到本地，是一件非常简单的事情。但是，并非所有的情况都是如此，因为对一个大型的系统来说，我们要面对着这么一些情况： 1. 代码库过多 2. 代码量过大 于是，在我所需要分析的这个系统里，它采用了 Google 的多仓库管理工具 Repo。这样就从一定程度上解决代码库过多的问题——对于我们来说，我们只需要执行一个 `repo sync`，它就可以帮助我们把所有的代码 clone 下来。而后，我们只需要等待几小时，或者几天，就可以下到我们的代码库了。 ## 1. 尝试编译系统 有了代码之后，我们就可以尝试按文档的步骤来构建应用。期间，我们还需要解决一些工具上的问题，又或者是按官方的 issue 来处理一些异常情况。 与此同时，你还可能会遇到我在这个项目上遇到的问题：当前版本是无法成功构建的。 于是，我还需要重新花一天时间，再找到某一个特定版本的代码……。 ## 2. 借助目录 + 编辑器进行初步分析 与此同时，在我们进行编译的时候，还可以同时简单地对项目进行分析： 1. 目录结构分析。通过查看目录名称和目录结构，分析项目的组成关系。 2. 代码简单分析。嗯，从一个入口点，一步步查看调用关系等。 之所以，我们还不能用 IDE 进行分析的一个原因是：对于这样的一个系统来说，IDE 是一个庞大的吃内存怪物。而在当前时刻，我们还在尝试构建这个系统，它不仅吃内存，还吃 CPU。甚至于，你的电脑还会因此而卡住。 ## 3. 工具可视化 进一步地考虑到了项目的代码量的问题，简单地靠人力分析起来比较困难。我们就需要借助于一些工具来对代码进行分析。 由于这是一个 Java 项目，我就可以用我之前写的系统分析工具：[Coca](https://github.com/phodal/coca)。用它来绘制基本的架构图：  还有某一个方法或者是类的上下调用关系：  ## 4. 配置 IDE，进行源码分析 在腾出了足够的 CPU + 内存资源之后，我们就可以轻松愉快地打开 IDE，进行源码分析。于是，很快地，我就需要等待 IDE 把代码索引完。 好了，IDE 卡住了。 ### 模块分析 接着，我尝试了另外一种可能性，打开其中的某一个工程查看源码，但是很快地我发现了：**缺少依赖**。因为总体的构建失败，导致了总工程的一些依赖无法构建成功。 于是乎，我尝试了另外一种可能性：提取生产环境的依赖。毕竟，我所需要的依赖是一些 jar 包，而 jar 包会伴随着系统一起分发。这样一来，我就能从发布包中复制依赖到工程中使用，然后愉快地继续阅读代码了 —— 顺便地也能从依赖分析项目的情况。 ### 工程内依赖分析 嗯，对于某些模块来说，它的产出是一个 jar 包，那么我们不一定需要阅读它地源码。只需要理清单个模块的构建产物，以及它的作用即可。 ## 5. 绘制架构图 嗯，有了上面的基础之后，我们就可以绘制架构图了。 暂时没啥好的工具推荐，Google Slides、Sketch 这一类的都可以。 如果是调用关系的话，可以用 Graphviz 来绘制。只是呢，我已经用 Coca 来自动化绘制这个依赖关系了。哈哈 ## 6. 用户旅程验证 我们阅读代码时，都是从入口开始验证。如基于 Spring 的微服务项目，都是从 API 注解作为入口点，一步步分析这个系统的架构；如 Angular 开发的前端应用，是从 `main.ts` 开始的。如 IDEA 插件，是从 plugin.xml 开始的，从 Action 绑定用户行为。 以类似的方式，我们就可以在不能调试的情况下，进一步验证架构的提炼是否合理。 ## 7. 回溯版本，重复 考虑到我使用的版本是不能成功编译地版本，所以又花了点时间再下一个旧版本的系统，以验证部分关系是否是正确的。 毕竟只有成功编译地版本，才是正常的版本。 ## 8. 总结输出 这些相关的产物可以有： 1. 过程日志 2. 问题总结 3. 架构图 4. 仿制的 MVP demo 在这里，我们还是强调一下最后一个，我经常拿这种方式来创造轮子。

作者: Phodal Huang 2019年12月23日 20:50

如我在先前的文章所说，我最近的工作主要是在做架构重构、代码重构。所以，一如既往地，我又写了个工具来帮助我完成相关的工作。这样一来，下次我可以更快速地完成相关的工作。