code-metrics - 软件指标是否双向起作用

Question

我刚开始在一家大公司工作。在最近的一次内部审计中，测量圈复杂度和文件大小等指标结果表明，包括我团队拥有的模块在内的几个模块具有非常高的指数。因此，在上周，我们一直专注于降低代码的这些索引。通过删除决策点和拆分文件。

作为新人，也许我错过了一些东西，但是，这将如何使我们的软件变得更好？，我知道软件指标可以衡量你的代码有多好，但是反过来呢？我们的代码会因为例如我们将 10000 行文件变成 4 个 2500 行文件而变得更好吗？

score 6 · Accepted Answer

指标的目的是更好地控制您的项目。它们本身并不是一个目标，但可以帮助提高整体质量和/或发现设计不和谐之处。圈复杂度只是其中之一。

测试覆盖率是另一个。然而众所周知，您可以获得很高的测试覆盖率，但仍然有一个糟糕的测试套件，或者相反，一个专注于代码的一部分的优秀测试套件。圈复杂度也是如此。考虑每个指标的背景，以及是否有需要改进的地方。

您应该尽量避免意外的复杂性，但如果处理具有必要的复杂性，您的代码无论如何都会更复杂。然后尝试编写可维护的代码，在方法的数量和它们的大小之间取得公平的平衡。

一本值得一看的好书是“实践中的面向对象度量”。

score 5 · Accepted Answer

这取决于您如何定义“更好”。较小的文件和较低的圈复杂度通常使其更易于维护。当然，代码本身仍然可能是错误的，单元测试和其他测试方法将对此有所帮助。这只是使代码更易于维护的一部分。

score 2 · Accepted Answer

代码更容易理解和管理更小的块。

将相关代码位分组到各自的功能区域中以提高可读性和内聚性是一个好主意。

将整个大型程序全部放在一个文件中将使您的项目很难调试、扩展和维护。我认为这很明显。

特定的指标实际上只是一个经验法则，不应该虔诚地遵循，但它可能表明某些事情并不像它可能的那么好。

是否应该触及和重构遗留的工作代码是需要评估的。如果您决定这样做，您应该首先考虑为其编写测试，这样您将很快知道您的更改是否违反了任何要求的行为。

score 0 · Accepted Answer

几个月后再也没有打开过你自己的项目吗？单个组件越大、越复杂，人们就越会问自己，是什么天才写了这段代码，以及他为什么要这样写。而且，从来没有太多甚至足够的文档。因此，如果组件本身不那么复杂且更小，则更容易重新理解它们

score 0 · Accepted Answer

这有点主观。分配最大圈复杂度指数的想法是提高代码的可维护性和可读性。

以单元测试的角度为例，拥有更小的“单元”确实很方便。避免长代码将有助于读者理解代码。您不能确保原始开发人员永远在代码上工作，因此从公司的角度来看，分配这样一个标准以保持代码“简单”是公平的

编写计算机可以理解的代码很容易。编写人类可以理解的代码更加困难。

score 0 · Accepted Answer

这将如何使我们的软件变得更好？

摘自与适用于 .NET 开发人员NDepend的工具相关的与制造复杂性作斗争的文章。NDepend 擅长帮助团队管理庞大而复杂的代码库。这个想法是代码指标很好，可以减少代码实现中的虚构复杂性：

在我对 Scott Hanselman 的 Software Metrics 的 Code Metrics 的采访中，Scott 发表了特别相关的评论。

基本上，当我解释冗长而复杂的方法会影响质量并且应该分成更小的方法时，斯科特问我：

看着这个太大太复杂的方法，我把它分解成更小的方法，业务问题的复杂性仍然存在，看我的应用程序我可以说，从方法的角度来看，这不再是复杂的，而是软件本身，它与其他代码位耦合的方式，可能表明其他问题......</p>

软件复杂性是相对于人类认知能力的主观衡量。当需要付出努力才能被人类理解时，它就是复杂的。事实上，软件复杂性是一个二维度量。要理解一段代码，必须同时理解：

业务问题的复杂性在于程序的规范，减少它意味着处理代码本身的行为。另一方面，当涉及到实现的复杂性时，我们谈论的是捏造的复杂性：它是捏造的，因为它可以在不改变代码行为的情况下减少。

score 0 · Accepted Answer

这将如何使我们的软件变得更好？

它可以触发重构，但遵循一个指标并不能保证所有其他质量指标保持不变。工具只能遵循很少的指标。您无法衡量代码可以理解的程度。

我们的代码会因为例如我们将 10 000 行文件变成 4 2500 行文件而变得更好吗？

不必要。有时较大的可能更容易理解，结构更好并且错误更少。

例如，大多数设计模式通过使其更通用和可维护来“改进”您的代码，但通常会增加源代码行的成本。

7 回答 7