如何量化代码质量

Question

我的业务部门有大量的开发人员(大约100人)。由于各种原因，开发人员几乎完全专注于交付而不是质量。质量不好的代码已经开始伤害我们了。这些虫子已经很难辨认了。密码变得脆弱了。单元测试与需求完全脱节。诸若此类。

我正与管理层密切合作。在这一点上，我想要设备策略来奖励好的代码。我想提出一些方法，客观地测量下面列出的几个参数。我想衡量这一点的原因是为了创建一个环境，开发人员在编写高质量的代码时会感到被认可和赞赏。(我可以得到管理层的支持)。此时，管理与用于度量代码质量的out数字断开连接。

1. 代码可读性
2. 单元测试与需求相关的程度(而不是覆盖范围，开发人员能够用无意义的单元测试覆盖代码)
3. 设计的简单性

我们主要是在C# (移动、网络和桌面应用)中开发。

更新1: 2019年11月14日

基于这些精辟的答案，我知道有许多衡量质量的措施，而且这些措施都必须用一点盐来衡量。这是一个辉煌的洞察力由特拉斯廷。“当一项措施成为一个目标时，就不再是一个好的衡量标准”。这是给我的。

在这一点上，我确信我们必须在代码质量(尤其是可读性方面)考虑人工元素。如何使管理人员对代码质量的度量(主观和客观)感兴趣，是我面临的真正挑战。

Answer 1

在这一点上，我想要设备策略来奖励好的代码。

你不能。古德哈特定律将很快发挥作用，您的客观指标将成为您的开发人员关注的对象，而不包括所有其他指标。

如果您的管理层与您正在生产的实际产品脱节，或者不信任您的团队领导谁对代码有洞察力，那么度量标准就不会修复这个问题。您有管理问题，而不是代码问题。

Answer 2

Basics

衡量质量的方法有很多。没有一个是完美的:如果以绝对的方式开始思考，你就会产生新的问题。以下是一些常用的指标：

• 圈复杂度
• 测试覆盖
• 每个类/方法
• 重复计数

还有一些二进制度量可以用作“门”，例如符合标准或最低测试覆盖率。

我建议您不要自己动手，而应该尝试像SonarQube这样的东西。有了这个，您就可以获得一系列标准和度量，您可以将其构建到仪表板中。

我建议将您的代码放在一起，并对结果进行一些分析，并与您的管理人员共享它们。然后，您可以考虑调整一些规则，并使用它来破坏构建；假设您有一个构建服务器和用于交付的托管流程。然而，这部分将需要管理层的收购。

命名

根据你对命名的想法，这可能是不可行的。我不确定是否有一种方法可以编程地确定一个变量的名称是否正确。我能想出办法

• 名字的长度(太长，太短)
• 名称中的数字(坏符号)
• 它们应该是字典词

但最终，您可能需要一个评审小组来确保名称是有意义的。队里有谁同意你的意见吗？

测试

这可能有点争议，但我认为单元测试不需要与需求相关联。单元测试的目的不是确保代码完成它应该做的事情。关键是要检查代码是否按照您的意思执行。例如，对sum函数的测试应确保它正确计算和。在单元测试中，是否需要计算一个和是无关紧要的。这是一个微妙的区别，但它确实对您编写单元测试的方式产生了很大的影响。

对需求的测试应该在不同的层中进行。如果为此使用单元测试，则应该在组件或应用程序级别将功能测试套件和回归测试套件组合在一起。

超越覆盖范围的单元测试度量的挑战在于它们是否有意义。我认为使用分支覆盖比行覆盖是一种改进，但是如果测试可以简单地执行路径而不检查任何内容。

脑海中浮现的一个想法是，您可以在这里使用模拟或模糊测试工具。进行单元测试，并针对错误的方法定义运行它们。在这种情况下，好的测试应该失败。

Answer 3

能见度

• 重要的是，所有的代码库都是共享的，并且对团队是可见的。
• 促进同行评议。
• 促进配对规划。
• 使用静态代码分析器，这个工具是可配置的，并附带一组可以调整的预设规则。
• 将SCA集成到持续集成工作流中，并发布任何人都可以看到的自动信号量报告。
• 虽然代码质量不是100%可测量的，但是有可以测量类和方法长度的可见报告、圈复杂度、内聚力和大量参数，以及单元测试结果，然后将其转换为绿色、黄色或红灯，将使程序员了解他们的代码是否干净，并总结出代码库的总体质量，而不是相反。

但对我来说，神奇的词是能见度。人们通常在观察时表现得更好，程序员也不例外。代码应该是值得骄傲的东西，是在水冷却器上谈论的东西。说代码，呼吸代码，思考代码。

您还会说，即使100%的覆盖率，单元测试也不会满足需求。我不确定，需求或故事测试是接受测试或集成测试的问题，因此您不一定能够推断出为满足特定功能而编写的方法的名称和数量。一些单元测试可以测试给定某些输入的函数是否返回预期的结果，这可以针对数千个预先计算的值的整个列表来完成。不能通过它的代码被破坏了。我认为这确实是在强制满足需求。不过，还有其他要求，即集成测试、压力测试和验收测试。