代码覆盖率神话

我经常问潜在的软件工程候选人的一个问题是查明理想项目中代码覆盖率的百分比。有趣的是，其中许多人以超过90％的数字跃上蓝天。他们将开始讲讲经过良好测试的代码如何更加可靠，并为所有利益相关者带来更多价值。当我询问他们目前正在进行的项目时，现实看起来更加扎根。

产生这种情况的原因各不相同，但请直言不讳，我说每个软件项目的1/3代码无关紧要，有漏洞，过于复杂或只是很烂。它有其存在的理由，但很可能，在未来的一年中，它将成为一种责任。对测试保持教条主义并覆盖每一行只会使摆脱它变得更加困难。

看到，没有两行代码的价值和重要性相等。向现有应用程序添加新功能只会对其功能产生轻微影响。但是，由于现有的复杂性，需要花大量的时间进行开发和集成。复杂性越大，引入新功能所需的时间就越长。到功能投入生产时，它可能已经不相关了。

提高代码覆盖率（并由此保持软件相关性）的唯一可行方法是识别并删除不必要的代码。

您如何识别不相关的代码？不要搜索它。相反，让它向您展示自己。很少有人使用的软件的一维就是其历史。 Git是一个很棒的分析工具。开始使用它不仅可以防止将来出现问题，而且可以了解代码的某些部分随时间变化的位置和频率。

在很长一段时间内，您会发现代码更改所产生的变化少于其余代码。这些是您应用程序的基础-必须经过严格测试的2/3。

您还会发现其他每周或多或少发生更改的地方。从技术和业务角度，自问这些内容是否仍然有用。为了覆盖而添加测试将具有提高代码质量的相反效果。在设计完美的软件项目中，最经常更改的部分是配置。对代码更改频率的简单分析将显示情况是否如此。如果不是，请尝试将运动部件与核心逻辑分离。如果这也不可行，那么代码的那些部分很可能不属于代码库。将它们变成可互换的脚本（甚至存储在单独的存储库中）是一种独立解决它们的方法。

我们不要过多地了解技术细节。 我已经在我以前的文章中提到亚当·托恩希尔（Adam Tornhill）在代码分析方面的工作： 在以后的文章中，我将讨论我应用于此处介绍的简单git one-liner的一些新想法。