重构评估与度量

如 Robert Nord 提出的 “技术债务全景图”（Tech Debt Landscape） 所示：

技术债对于软件的影响：可维护性（Maintainability）、可演进性（Evolvability），而这些技术债对于非技术人员来说都是不可见的。它们源于生活，藏于黑暗中。

在重构开始之前，我们可以进行技术债的头脑风暴，收集每个开发人员每迫切解决的技术痛点。并按照优先级来评估这些技术债，列入我们的重构范围中。

如我的同事在《技术债治理的四条原则》 一文中所介绍的，我们可以在对应的限界上下文里，可视化技术债：

再根据 “核心领域优于其他子域” 的原则，及其严重程度，来划分出技术债的优先级。

如我在那篇 《分层架构重构》 中所说，在大量的现有系统中，我们发现了 MVC 架构模式被落地为三层分层架构（controller-service-model）。开发人员对它们的错误等同，导致了架构上的一系列错误。

对于简单的系统来说，CSM 的包结构问题不大。或者说，对于非常简单的系统来说，大泥球架构也没有问题。我们所针对的是那些中大规模的系统。在这些系统里，系统并非一次性的，开发出来就不再维护了。因此，它们需要对更合适的架构设计和包的拆分分。

借助于 Tequila 这样的架构可视化工具，又或者是 coca arch，便可以得到项目的调用关系图，它可以在某种层面上反应出系统的架构。根据它，我们可以知道：

结果如下图所示：

通过调用关系图，我们也可以查看类之间、包之间是否存在相互依赖。

对于这部分内容来说，你可以直接采用成熟的商业工具，如 SonarQube 便可以完成这方面的工作。

你也可以通过 coca bs 来做一些简单的 Bad Smell 收集：

{
   "dataClass": [
      {
         "File": "examples/api/BookController.java",
         "BS": "dataClass"
      }
   ],
   "lazyElement": [
      {
         "File": "examples/api/model/BookRepresentaion.java",
         "BS": "lazyElement"
      }
   ]
}

而后，再生成对应的重构建议。

代码中的 Todo 注释，是一些本应该发生的事情，本应该做好，但是我没有立即去做。换句话来说，Todo 都是项目中的技术债务，就了可能就永远不会做。

所以，我们需要有工具来查找项目的 Todo，如笔者编写的 Coca，可以寻找代码中的 Todo，包含其对应的日期、作者、提交信息、文件名及对其的行数等信息：

随后，我们只需要根据真实的情况，更新项目中的 Todo，以确认出我们需要完成的技术债务。

不过，写好一个 Todo 并不是容易，万一以后大家都不写了呢？

根据不同的项目，侧重点有所不同。但是毫无疑问地，我们可以统计：

你都懂的。我暂时就不 copy 了。

在我遇到的一个重构项目中，项目中经常抛出Null Pointer Exception的问题。于是，我便写了一个简单的工具，来查找项目中返回Null Pointer Exception的代码，并对调用的地方进行评估。

随着评估的进一步深入，我在工具中加入了更多的功能，如：

只需要运行 coca evaluate，就能得到以下的结果：

笑，你只要加强使用 TDD，那么上述的大部分问题，都能得到进一步的缓解。

Java 世界流行的几个找问题工具：

试试你就知道了。

尽管有越来越多的项目将测试覆盖率作为一项考核指标。但是，对于诸多编程实践本身就好的公司为说，测试覆盖率也往往不是真的。

我们编写测试的其中一个目的是用于快速反馈，即当我们的功能出现问题的时候，我们可以快速通过测试来定位到问题所。然而，如果那些是没有断言的测试，那么我们就无法通过它来进行快速反馈。即，如果我们重构过程中，修改了某一块的功能，可能会进一步导致出现 bug。

为此，你可以借助于 Coca 的 Test Bad Smell 功能，来找到对应的问题。只需要执行 coca tbs，便能帮助你找到代码中的坏味道。它可以在你进入重构之前，帮你看看是否有对应的风险。

如下是 Coca 扫描出来的 Arduino 开源项目测试问题：

好在上述的测试代码中，没有出现诸如于下面场景的测试坏味道：

如果你的代码中出现了大量的上述问题，你需要好好反思一下，你的测试覆盖率是真实的吗？

代码本身是缺乏测试的，那么它就是一个遗留系统。

根据《精益软件度量》对于度量的定义：

你懂的。