我刚开始为一家大公司工作。在最近的内部审计中，衡量Cyclomatic complexity和文件大小等指标，结果发现包括我的团队拥有的模块在内的几个模块都有非常高的索引。所以在上周我们一直专注于为我们的代码降低这些索引。通过删除决策点和拆分文件。
也许我错过了一些新人，但这将如何使我们的软件变得更好？，我知道软件指标可以衡量你的代码有多好，但是它可以用另一种方式工作周围？我们的代码会变得更好，因为例如我们将10000行文件制作成4 2500行文件吗？
答案 0 :(得分：6)
指标的目的是更好地控制您的项目。它们不是自己的目标，但可以帮助提高整体质量和/或发现设计不和谐。 圈复杂度只是其中之一。
测试覆盖率是另一个。然而众所周知，你可以获得高测试覆盖率，但仍然有一个糟糕的测试套件，或相反，一个伟大的测试套件，专注于代码的一部分。圈复杂度也是如此。考虑每个指标的背景，以及是否有需要改进的地方。
您应该尽量避免使用accidental complexity，但如果处理时间为essential complexity，那么您的代码无论如何都会更复杂。然后尝试编写可维护的代码，在方法数量和大小之间取得公平的平衡。
要看的好书是“Object-oriented metrics in practice”。
答案 1 :(得分：5)
这取决于你如何定义“更好”。较小的文件和较少的圈复杂度通常使维护更容易。当然代码本身可能仍然是错误的，单元测试和其他测试方法将有助于此。这只是使代码更易于维护的一部分。
答案 2 :(得分：2)
代码更容易理解和管理更小的块。
最好将相关的代码位分组到自己的功能区域中，以提高可读性和凝聚力。
将一个完整的大型程序放在一个文件中将使您的项目很难调试，扩展和维护。我认为这很明显。
特定的指标实际上只是一个经验法则，不应该被虔诚地遵循，但它可能表明某些东西不尽如人意。
是否应该触及和重构遗留工作代码是需要评估的事情。如果您决定这样做，您应该考虑为它首先编写测试，这样您就可以快速了解您的更改是否违反了任何必要的行为。
答案 3 :(得分：0)
几个月后再也没有打过你自己的一个项目？单个组件越大越复杂，就越会问自己，这个代码是什么样的代码以及为什么他用这种方式编写代码。 并且，从来没有太多甚至足够的文档。因此，如果组件本身较复杂且较小，则更容易重新理解它们
答案 4 :(得分：0)
这有点主观。分配最大化Cyclomatic复杂性指数的想法是提高代码的可维护性和可读性。
作为单元测试的一个例子，拥有较小的“单位”非常方便。避免使用长代码将有助于读者理解代码。您不能确保原始开发人员永远处理代码，因此在公司的角度来看，分配这样的标准以保持代码“简单”是公平的
编写可以由计算机执行的代码很容易。编写一个人类可以理解的代码会更加困难。
答案 5 :(得分：0)
这将如何使我们的软件更好？
摘自与.NET开发人员Fighting Fabricated Complexity工具相关的文章NDepend。 NDepend擅长帮助团队管理庞大而复杂的代码库。我们的想法是，代码指标很好，正在减少代码实现中的伪造复杂性：
在Scott Hanselman关于软件度量标准的Code Metrics访谈中，Scott有一个特别相关的评论。
基本上，虽然我在解释长而复杂的方法正在扼杀质量并且应该分成更小的方法，但斯科特问我：
看着这个太复杂了 方法，我把它分解成更小的 方法，复杂性 业务问题仍然存在， 看着我的应用我可以说， 这不再复杂了 方法透视，但软件 本身，它的耦合方式 其他代码，可能表示其他 问题...
软件复杂性是相对于人类认知能力的主观测量。当需要努力让人理解时，某些事情是复杂的。事实是软件复杂性是一个二维度量。要理解一段代码，必须理解两者：
业务问题的复杂性在于程序的规范，减少它意味着处理代码本身的行为。另一方面，当涉及到实现的复杂性时，我们正在讨论制造的复杂性：它是在可以减少而不改变代码行为的意义上制造的。
答案 6 :(得分：0)
这将如何使我们的软件更好？
它可以是重构的触发器，但遵循一个指标并不能保证所有其他质量指标保持不变。而且工具只能遵循很少的指标。您无法衡量代码可以理解的程度。
我们的代码会变得更好吗？ 因为例如我们正在做一个 10 000行存入4 2500行 文件？
不一定。有时较大的一个可以更容易理解，结构更好，并且有更少的错误。
大多数设计模式例如通过使代码更加通用和可维护来“改进”代码，但通常会增加源代码行的成本。