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

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

commit a685d69080a7abde684e1d0707cbf410092e3173
Author: Phodal HUANG <h@phodal.com>
Date: Tue Oct 22 23:01:19 2019 +0800
first commit
commit c6b5a0c7f174c6a0ba233a1356aca5c370ba4315
Author: Phodal HUANG <h@phodal.com>
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？说白了，就是价值决定了一切。

对于重构而言，我们所要面对的是技术挑战；对于重写而言，我们所面对的是业务挑战。

重构的技术挑战

我们所面临的主要技术挑战是：

是否能确保过程的安全性？如何设计测试防护网
是否能想到更好的设计来取代现有的方案？
如何做一次有效的分析与评估？
如何渐进式的重构系统？如何保持小的、快速的提交
怎样支持未来业务的可扩展？即，支撑业务可扩展性
是否寻找最合适的重构技巧？比如通过 IDEA 的重构
如何让重构技能被传承？即，多数团队成员都能快速上手
……

重写的业务挑战

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

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