探索性重构：可行方案

软件开发是一种团队活动，当组织缺乏强有力的 新鲜血液时，代码便会以相同的模式编写。该组织设计出来的架构，也从某种意义上出现了大量的趋同 —— 创新反而可能不好。在这种统一的模式之下，组织的代码也会呈现相似的坏味道。代码中的坏味道的模式也往往极为相似。

也因此，我们能快速地通过一小部分代码，了解整个项目的情况。

为此，我们只需要根据《重构：改善既有代码的设计》一书提出的 23 种代码坏味道，整理出系统中的常见坏味道。

随后，我们便能有针对性地对代码进行重构。

C4 Model 是一个非常不错的架构可视化工具，它从系统 System、容器 Container、组件 Component 和代码 Code 四个层次，由顶至底来介绍系统的架构：

所以，我们可以根据 C4 模型的思路来查看整个应用的架构设计和代码情况。

举个例子，从 API 入手：

针对于那些使用 Spring 框架的后端项目来说，可以尝试使用 coca api 来生成项目 API 调用图。

作为一个碳基生物，我们要承认我们并非是全知的。我们所能做的事，来到一个新的领域时，能快速学习相关的知识。

简单来说，就是你知道对系统有一个初步的认知，它包含了：业务架构、技术架构、开发组成等等。

根据开发人员介绍的各种概念，抽象出一份系统的领域名词表。它的来源是：

也因此，当你需要到一个新的项目实施重构计划时，一定需要有一个能与你结对编程的人。一个领域专家，一个代码专家，双方的无间配合，才能快速落地完成重构工作。

我们所要做的一个努力是，让文档、架构、元模型概念与代码实现一一对齐。这并不是一件容易的事情。从大多数项目的实践来看，架构师的设计和模型的实现往往是脱离的。因为设计架构的人和实现模型的人，往往不是同一些人。

我正在尝试根据它来编写这样的一个功能，但是它不是一件容易的事。只是呢，已经有一个小的雏形，通过 coca concept 从函数名称中抽取出部分的对应模式

但是，这只能是构建领域名词表的一个 hello, world，并不足以承担起真正的领域名词活动，也无法构建真正的领域名词表体系。

除此，我还在寻找一种更高效的构建领域特定语言方式，它用于帮助我们高效地进行软件开发，这种社会学活动。

经常修改的代码，并不是见得是件好事。我们可以从中看到一些代码的坏味道，把它朝合适的方便引进，如类库，如包内聚等等

如果你使用的是 Git，可以通过 coca git -t 识别到高修改的文件：

上述的代码是 Spring Framework 中最常修改的文件，前面三个文件看上去是合理的，但是 AnnotationUtils.java 显然有问题。

对应的 DefaultListableBeanFactory.java 也有 2000+ 行左右的规模。

从代码的行数和修改次数来看，它们都是上帝类，并且经常出现 Bug。

下表是 Spring 源码中引用最多的方法：

从代码上来看，还是 Util 方法被引用得最多。似乎我们仍然需要一个更可靠的算法，来保证被引用的正常度。