0
0
前言:
Adam Thornhill 的算法模型中的 Hotspots, 代表的是产品中复杂度高并且是提交到配置库频率高的模块、文件。
Hotspots 是经由计算两个纬度的度量而获得的:
- 模块、文件的代码行数; 代表著模块、文件的复杂度。
- 模块、文件提交到配置库的频率; 代表著模块、文件的变更频率。
图二是由 CODESCENE 所分析出的 ASP.NET Core MVC 的 Hotspots。
让我们看看 ASP.NET Core MVC 的 Hotspots 里面的故事。
敏捷开发 技术债务：
由 CODESCENE 所分析出的 ASP.NET Core MVC 的 Hotspots 当中, 我们找到了 Top Hotspot; 图三中最大的红色圆圈。
Top Hotspot 代表的是:
在 ASP.NET Core MVC 中代码行数最多 (复杂度最高) 并且是提交到配置库的频率最高的模块、文件。
因为, ASP.NET Core MVC 是个中等大小的模块; 整个 ASP.NET Core MVC 的代码行数是 200,000 行, 大部分是用 C# 开发。所以, 我们便可直接由 CODESCENE 去分析 ASP.NET Core MVC 的 Top Hotspot 内部所发生的故事, 而获得可大幅改善 ASP.NET Core MVC 质量的启发。
如图四所示, 模块 ASP.NET Core MVC 中 Top Hotspot 中的文件是: ControllerActionInvokerTest.cs; 大约 1,400 行的代码, 超过 100 次的提交配置库的变更。
因为, Hotspot 构成的主要的要素是来自于:
- 模块、文件的复杂度
- 模块、文件的变更频率
所以, 我们就先看看 Top Hotspot: ControllerActionInvokerTest.cs 的复杂度的趋势图。
从图五所显示的复杂度的趋势当中, 我们很容易的就发现在 2016 年 五 月, ControllerActionInvokerTest.cs 的代码行数并没有明显的增加, 但是复杂度却明显的飙升。
另一方面, 我们审视 ControllerActionInvokerTest.cs 的代码, 我们发现, ControllerActionInvokerTest.cs 复杂度上升的原因, 并不是因为开发人员在 ControllerActionInvokerTest.cs 中加入了可帮助开发人员理解代码、提升代码维护效率的 “代码注释”。
所以, 我们可以确定的是: ControllerActionInvokerTest.cs 的复杂度的上升, 将会使得 ControllerActionInvokerTest.cs 更加日益的难以维护, 而影响到 ASP.NET Core MVC 开发的效率、产品的质量。
CODESCENE 使得我们能从 200,000 行代码的 ASP.NET Core MVC 模块中, 专注到大约 1,400 行代码的ControllerActionInvokerTest.cs 文件中, 去分析值得投入人力、时间去进行整改的技术债务; 而不致于在 ASP.NET Core MVC 模块中盲目的整改技术债务。
我们继续的分析下去…
从图五复杂度的趋势图当中, 我们只是知道 ControllerActionInvokerTest.cs 的复杂度, 将会使得ControllerActionInvokerTest.cs 更加日益的难以维护。但, 我们尚无法得知, 该从何处下手去解决这个问题? 因为, 我们尚无法得知是什么样的开发者行为, 会发生代码行数并没有明显的增加, 但是复杂度却明显的飙升?
所以, 我们将使用 CODESCENE 的 X-Ray, 进行 ControllerActionInvokerTest.cs 文件的代码分析; 找出使得ControllerActionInvokerTest.cs 复杂度明显的飙升的开发者行为。
首先, CODESCENE 的 X-Ray 帮我们分析出在 ControllerActionInvokerTest.cs 文件中的 Top Hotspot 函数; 在 ControllerActionInvokerTest.cs 文件中复杂度最高、变更频率最高的函数。
ControllerActionInvokerTest.cs 文件中的 Top Hotspot 函数:
- CreateInvoker; 大约 180 行的代码, 超过 80 次的提交配置库的变更。
同样的思路、方法:
Top Hotspot 函数: CreateInvoker 的代码, 一定有著是值得我们投入人力、时间去进行分析、整改的技术债务。
我们就先看看 Top Hotspot 函数: CreateInvoker 的复杂度的趋势图。
由 Top Hotspot 函数: CreateInvoker 的复杂度的趋势图当中, 我们可以很容易的看到:
Top Hotspot 函数: CreateInvoker 在 2016 年 五月时, 新增了少量的代码, 却使得复杂度急遽的上升。
所以, 我们找到了使得 ASP.NET Core MVC 模块, 在代码行数并没有明显的增加, 但是复杂度却明显的飙升的开发者行为:
- 在 2016 年 五月时, 开发人员在函数 CreateInvoker 中新增了少数的代码, 但却造成函数 CreateInvoker 复杂度急遽的上升, 当然, 也就使得 ControllerActionInvokerTest.cs 文件、ASP.NET Core MVC 模块的复杂度也就急遽的飙升。
结论：
CODESCENE 分析出了开发者在配置库中的行为:
- 使得我们能从 200,000 行代码的 NET Core MVC 模块中, 专注到大约 1,400 行代码的ControllerActionInvokerTest.cs 文件中。
- 再从大约 1,400 行代码的 ControllerActionInvokerTest.cs 文件中, 找到值得投入人力、时间去进行整改的 Top Hotspot 函数: CreateInvoker。
- Top Hotspot 函数: CreateInvoker 虽然有大约 180 行的代码, 但已比 200,000 行代码的 NET Core MVC 模块、1,400 行代码的 ControllerActionInvokerTest.cs 文件少了许多。
分析出了开发者在配置库中的行为, 我们终于可以高效、低成本的付清技术债务; 在 200,000 行代码的模块里, 找到最值得优先关注的 180 行代码！
相关阅读:
产品中的 Hotspots: 基于配置库中代码所隐藏的开发者行为, 高效的提升产品的质量与开发的效率
Proximity: 付清技术债务; 不消除重复代码, 却能提升产品开发的效率、质量
别再傻傻的写单元测试了; Hotspots 告诉我们单元测试的真相: 单元测试是负债? 还是资产?
