G'day，

我正在考虑Kristopher Johnson关于我对有关软件开发质量的此问题的回答的评论。

我发布了一份我可以想到的软件质量指标列表，其中包括：

• McCabe循环复杂度-基本上是通过代码衡量线性路径数量的方法。
• 缩进级别-查看嵌套决策语句时的复杂性度量。
• 从声明到第一次使用的距离-在声明变量的位置和第一次使用变量的位置之间存在多少条语句。
• 注释百分比-与源代码相比注释的代码行数。
• 测试覆盖率百分比-作为代码行的百分比，测试套件将执行多少行。
• 路径测试范围-测试执行多少条执行路径。
• 单元覆盖率-单元测试可以行使多少个单独的单元，类，包等。

克里斯(Kris)的评论是：

Only the test-coverage metrics listed here could be considered a measure of "quality." The others are measurements of complexity and readability, which really has nothing to do with quality.

除了我完全不同意这一说法外，这还让我思考。

当我不得不回顾几乎没有任何相关测试的代码时，无论是单元测试，系统测试还是集成测试，与发现成功通过一套好的测试相比，我倾向于更加谨慎地对待代码。

对代码执行安全审核时也是一样。如果我看到Apache模块中使用了未使用的变量，庞大的功能，配置的奇怪混合，每个服务器，每个目录等，这也使我很谨慎地处理代码。

是否有其他人使用这种最初的"直觉"方法，并且会影响结果吗？

顺便说一句，我不同意Kris的评论，因为所有其他指标绝对是有效的指标，将有助于突出设计不良，执行不佳的代码。正如达米安·康威(Damian Conway)所说：

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.

解决方案

回答

我认为我们和Kris只是对质量的定义存在异议。举一个数学证明的类比。

我们可能会说，质量取决于证明是否正确，即从假设到结果都是正确的。但是，大多数数学家都会同意，有些证明要比其他证明更好，因为它们更短或者更精巧或者更容易理解，而这些都是质量的度量。只有第一个定义是形式上可定义的，但是我认为大多数数学家都说第二个定义是"更好的证明"。

克里斯(Kris)所说的在第一个定义下是正确的，只有测试才能真正衡量正确性，但是我认为包括我在内的大多数程序员也会将质量与衡量标准联系起来。

回答

发达的"直觉"是使初学者与专业人士区别开来的地方。在我们获得一些经验之后，"胆量感觉"将成为最终决定的主要因素之一。无论我们是在查看某人的代码还是在创建系统体系结构，都没关系，直觉可以指导我们。但是，务实的开发人员一定不能太自信。总有一个检查清单和其他方式的地方。

至于指标，我完全同意你的看法。指标如果对代码质量没有帮助，则毫无意义。

回答

是的，一旦我们有了一点经验，"肠子感觉"就是一个非常好的工具。我似乎记得亨特和托马斯在实用程序员中提到了这一点。他们说类似"我们有丰富的经验，所以请不要忽略这种na的感觉"(如果引用正确，或者来自另一本书，请更正我)。

卡尔