每位开发者都希望拥有整洁的代码:易读、易维护、问题和缺陷少。而要实现这一目标并没有什么神奇的灵丹妙药:每家公司都有自己的最佳实践和编码规范,并努力制定一套流程来保持代码整洁。
衡量一个项目的代码质量并非易事;许多工具都提供了各自的评估算法,基于诸多因素:
- 静态分析工具检测到的问题。
- 代码覆盖率。
- 代码重复。
- 文档。
- 设计缺失。
有一个度量可以为我们提供一个近似反映代码库质量整体面貌的估计:技术债度量。
维基百科对技术债有一个简要的解释:
技术债(也称为设计债或代码债)是“编程中的一个概念,反映了当开发者采用短期内易于实现的代码、而非应用最佳整体方案时所产生的额外开发工作量”。技术债可以与金钱债务类比。如果技术债得不到偿还,它就可能累积“利息”,使以后的变更更难实施。未处理的技术债会增加软件熵。技术债不一定是坏事,有时(例如作为概念验证)需要借助技术债来推动项目前进。另一方面,一些专家认为,“技术债”这个比喻往往会弱化其影响,导致纠正它所需的工作得不到足够的重视。
从理论上讲,处理技术债是提升软件质量的一条有希望的途径,但在实践中并不容易施行。主要的挑战在于如何评估技术债。
无论使用什么工具或方法来评估,它都必须灵活且易于定制。公司必须能够根据自身情况校准算法。例如,一个团队也许可以容忍超过 50 行代码的方法,而另一个团队可能会选择 30 行作为上限。
敏捷算法来救场
有两种方式可以让技术债的计算变得灵活:
- 定义一个特定的算法,并允许根据开发团队的具体情况调整其参数。
- 不定义特定算法,而是为用户提供自定义计算公式的方法。
在CppDepend中,我们选择让算法保持灵活;它可以根据项目上下文针对每条规则进行调整。
例如,下面是由过大类型引入的技术债的计算公式:
下面是针对一个 Cppcheck 问题的另一个公式:
这样,每个团队都可以根据项目上下文配置自己的技术债计算方式,从而有助于减少技术债计算中的估算误差。
与基线对比
评估技术债是困难的:每种算法都会引入估算误差,而且校准可能很耗时,因为结果取决于许多因素。
然而,如果我们比较一个代码库两个迭代版本的技术债,就能很好地了解其代码质量的演变趋势。
两个版本之间技术债度量的差值可以将估算误差最小化,给出更准确的技术债度量。
用趋势图追踪质量演变
技术债之类的概念确实很有帮助。但没有什么比直观的可视化更能打动人。
例如,您可能想查看每个方法的平均圈复杂度和代码行数。一般来说,您会期望这些数字在代码库中保持相对平稳(且较低)。您可以用趋势图来确认这一点并持续跟踪。
趋势线是大体保持平稳、偶尔有小幅上升或下降,还是在缓慢而稳定地向上攀升?观察这样的趋势可以帮助您比以往更早地发现问题。每当我看到一个方法复杂度糟糕透顶的代码库时,我都明白,没有人是一下午就把它搞成那样的——那是多年来没有人注意到一个普遍而渐进趋势的结果。
结语
技术债度量是监控代码库质量的有力手段。不过,用户需要一种简便的方式来校准它并减少估算误差。而且,关注技术债的演变趋势,比关注技术债的绝对值本身更有用。