更少的代码==更高的质量

我们大多数人都听过“少即是多”这句话，但你有没有想过这对软件质量意味着什么？

如果您不熟悉，“少即是多”的定义如下：

用于表达以极简主义的方式处理艺术或美学问题更为有效的观点。

Lexico – 牛津在线词典

显然，这句话可以用于用户界面和用户体验等方面。简洁明了的用户界面能让用户专注于真正重要的事情。

对我个人而言，有趣的是将这个真理应用到代码和软件质量中。

我已成为死神，代码的毁灭者

本周早些时候，我发送了一个合并请求，其具有以下增量签名：

也就是说，我在单个合并请求中修改或添加了 138 行，并删除了多达 12,618 行。

我的审阅者感到非常尴尬，但值得庆幸的是，绝大多数更改都是彻底删除类和方法，并且审阅和工作项目都顺利进行。

此外，不到一周，我们就感受到了“少即是多”的好处。代码更容易查找，重复代码也大大减少，我们只需修改更少的地方，就能更快地完成修改。

无需赘述，所讨论的特定提交删除了与当前上下文不再相关的大量代码。

您可能认为未被调用的代码不会被改变、不会被破坏并且不应该有影响。

但那你就错了。

半死不活、如同僵尸般的代码仍然会消耗开发团队的精力。死代码不仅会增加代码量和构建成本，还会拖慢开发进度。

为了说明这是如何实现的，假设我正在考虑更改一个方法的签名。我可以使用编辑器中的内置工具，或者在文件中执行“查找”操作来查看其他代码调用了该方法，然后判断应该如何处理每个调用者。

如果不再相关且永远无法调用的代码调用了我的方法，它仍然会出现在搜索结果中，我仍然需要对此进行解释。在极端情况下，来自已死但尚未意识到已死的代码的调用可能会改变实施变更的整个策略，从而增加数天甚至更长时间的开发时间。

此外，死代码还会使扫描文件和查找相关信息变得更加困难。它会给代码添加不必要的噪音，而噪音又会让 bug 更容易被隐藏。

因此，如果您有大量可证明已失效的代码，请将此代码视为缺陷，并在发现时将其删除。

那么，我们如何找到死代码？

搜索您正在使用的方法或类的名称并查找任何没有匹配的代码。

请记住，继承和接口会使哪些方法未被调用变得更加模糊，因此请留意误报。

检查单元测试代码覆盖率，找出单元测试中遗漏的大块代码。请注意，只有当您的单元测试覆盖了目前使用的整个应用程序时，这种方法才有效，因此通常不太可靠。

使用Visual Studio或ReSharper等开发工具来识别未调用的代码。这些工具通常具有“查找用法”或“查找所有引用”选项。

总的来说，使用工具是我最喜欢的查找未调用代码的方法。

静态分析工具（例如SonarQube或NDepend）可以告诉你更多关于代码中哪些部分被使用、哪些部分未被使用的信息。这与基于开发工具的方法非常相似，只是这些工具通常是特殊情况的分析工具，它们很少在开发机器上运行，或者内置于构建过程中。

顺便说一句，这些类型的工具也有助于向其他人传达软件质量。

在我之前的示例提交中，我依靠 ReSharper 来帮助识别在浏览代码库时需要修剪的方法，然后依靠 NDepend 来查找未出现在任何代码覆盖率结果中的大型类。

结果看起来类似于过去版本的以下屏幕截图：

通过这样的视图，你很容易就能发现代码库中哪些地方根本没有经过测试，因为它们看起来更加稳固和统一。这就像给你的代码拍了一张 X 光片。

辅助功能说明：对于色盲人士，NDepend 提供颜色定制

产品披露：虽然我之前是 NDepend 的付费用户，但我目前的版本是作为评估版免费提供给我的

我喜欢这么说，但还是值得重复一遍：不存在的代码是不会被破坏的。

您要删除的代码可能包含明显的错误，并且通常无法正常运行。它也可能包含一些细微的边缘情况，等待被发现。它也可能完全没有错误。无论如何，删除它都可以解决代码中现有的所有缺陷，并防止新的缺陷进入该代码块。

当您删除死代码时，您会减轻所有未来开发人员的负担，他们要么接触过相关文件，要么搜索过代码库并找到与您删除的代码相匹配的代码。

死代码形式的噪音越少，意味着在调试过程中可以更加集中注意力，从而可以在过程的早期发现更多的错误。

回到我们的前提：少即是多。更少的代码带来更高的质量。

我敢打赌这也不是线性关系——肯定会有一个最佳点，如果你走错了那边，质量问题就会以惊人的速度增长。

最后，我对您的建议是尽可能地接受代码的消亡，并寻找方法不仅删除旧代码，而且找到更简洁（但仍然可读）的方式来表示您必须保留的代码。