系统重构的未来：重构工具 Coca 一周年

谈系统重构的未来：重构工具 Coca 一周年

一年前，在公司大佬的指点之下，我开始写系统级重构工具 Coca (https://github.com/phodal/coca) 。哦，不，不对，是刚开始学习 Golang，因为我的第一次提交是从一个 Go 的 hello, world 写起的。

commit a685d69080a7abde684e1d0707cbf410092e3173
Author: Phodal HUANG <[email protected]>
Date:   Tue Oct 22 23:01:19 2019 +0800

    first commit

commit c6b5a0c7f174c6a0ba233a1356aca5c370ba4315
Author: Phodal HUANG <[email protected]>
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. 如何让重构技能被传承？即，多数团队成员都能快速上手

重写的业务挑战

与重构不同的事，重写时的挑战主要是来自于梳理现有业务：

1. 如何体系化的整理现有的业务？
2. 如何剔除已淘汰的业务？
3. 如何确保主干业务的完整性？
4. 是否能确保细小的业务功能不被遗失？
5. 能否设计出更完善的业务知识管理体系？

系统重构的未来

在 Coca 编写完成之后，我发布了《系统重构与迁移指南》一份短小、精悍的重构手册。从这个手册快速的自然增长率（GitHub star 指标，没有经过大量宣传），并且已经在 Google 的相关关键字下（如系统重构、重构策略等）排名第一，我发现了人们缺少一份这样的指南和工具。

所以，在未来一定会有更多的相关工具诞生，并配套有大量的实践指南。

方法论支撑

在开始重构之前，我们需要设计出可行的重构方案，这也就是方法论的支撑。

对于重构的方法论来说，实现上我们已经可以在市面上找到大量的相关书籍，只需要结合起来看就可以了：

• 《重构与模式》
• 《设计模式：可复用面向对象软件的基础》
• 《重构：改善既有代码的设计》
• 《领域驱动设计：软件核心复杂性应对之道》
• 《修改代码的艺术：构建易维护代码的 9 条最佳实践》
• 《代码整洁之道》
• 《架构整洁之道》
• 《数据库重构》
• 《遗留系统重构指南》
• 《前端架构：从入门到微前端》

市面上，已经充斥着大量代码级重构的工具，如 JetBrians 系列的 IDE。但是，对于系统级重构来说，基本上很少有工具可以直接能支撑现有的系统，哪怕是 Coca 也是有限的支持。主要原因就是：大部分的内部系统都绑定了组织中的模式。特别是对于大型组织来说，它们往往配套开发了自己的底层架构和 API。

也因此，对于系统级别的重构来说，我们要优先考虑的是定制一个工具，又或者是基于开源工具进行扩展。

操作指南支撑

同样的，我们也很难在市面上找到这样的指南，因为对于大部分的公司和团队来说，重写是更好的 KPI，而重构并不会带来如此丰富的价值。除此呢，对于有过重构经验的团队来说，他们也不一定会共享出自己的经验——受能力和保密协议影响。

于是乎，我开始不断丰富我的指南《系统重构与迁移指南》。

软件开发总成本 = 开发成本 + 维护成本；软件维护成本 = 理解成本 + 修改成本 + 测试成本 + 部署成本。—— Ken Beck