软件指标是双向的吗
我刚刚开始在一家大公司工作。在最近的一次内部审计中，测量了循环复杂度和文件大小等指标，结果发现，模块（包括我团队拥有的模块）具有非常高指数。因此，上周我们一直致力于降低代码的这些索引。通过删除决策点和分割文件。
也许作为新人我错过了一些东西，但是，这将如何使我们的软件变得更好？，我知道软件指标可以衡量您的代码有多好，但是它是否可以反过来呢？我们的代码会因为例如我们将 10000 行文件变成 4 2500 行文件而变得更好吗？
I just started working for a large company. in a recent internal audit, measuring metrics such as Cyclomatic complexity and file sizes it turned out that several modules including the one owned by my team have a very high index. so in the last week we have been all concentrating on lowering these indexes for our code. by removing decision points and splitting files.
maybe I am missing something being the new guy but, how will this make our software better?, I know that software metrics can measure how good your code is, but dose it work the other way around? will our code become better just because for example we are making a 10000 lines file into 4 2500 lines files?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
指标的目的是更好地控制您的项目。它们本身并不是目标，但可以帮助提高整体质量和/或发现设计不和谐之处。 圈复杂度只是其中之一。
测试覆盖率是另一回事。然而，众所周知，您可以获得很高的测试覆盖率，但仍然拥有一个糟糕的测试套件，或者相反，一个专注于代码的一部分的优秀测试套件。圈复杂度也会发生同样的情况。考虑每个指标的背景，以及是否有需要改进的地方。
您应该尽量避免意外的复杂性，但如果处理有基本复杂性，无论如何，你的代码都会更加复杂。然后尝试编写可维护的代码，在方法的数量和大小之间取得公平的平衡。
一本值得一看的好书是“面向对象的度量练习”。
The purpose of metrics is to have more control over your project. They are not a goal on their own, but can help to increase the overall quality and/or to spot design disharmonies. Cyclomatic complexity is just one of them.
Test coverage is another one. It is however well-known that you can get high test coverage and still have a poor test suite, or the opposite, a great test suite that focus on one part of the code. The same happens for cyclomatic complexity. Consider the context of each metrics, and whether there is something to improve.
You should try to avoid accidental complexity, but if the processing has essential complexity, you code will anyway be more complicated. Try then to write mainteanble code with a fair balance between the number of methods and their size.
A great book to look at is "Object-oriented metrics in practice".
这取决于你如何定义“更好”。较小的文件和较低的圈复杂度通常使其更易于维护。当然，代码本身仍然可能是错误的，单元测试和其他测试方法将有助于解决这个问题。这只是使代码更易于维护的一部分。
It depends how you define "better". Smaller files and less cyclomatic complexity generally makes it easier to maintain. Of course the code itself could still be wrong, and unit tests and other test methods will help with that. It's just a part of making code more maintainable.
较小的代码块更容易理解和管理。
将相关代码位分组到各自的功能区域中是一个好主意，以提高可读性和内聚性。
将整个大型程序全部放在一个文件中将使您的项目非常难以调试、扩展和维护。我认为这是很明显的。
特定的指标实际上只是一个经验法则，不应严格遵循，但它可能表明某些事情并不那么好。
是否应该触及和重构遗留工作代码是需要评估的事情。如果您决定这样做，您应该考虑首先为其编写测试，这样您就可以很快知道您的更改是否破坏了任何必需的行为。
Code is easier to understand and manage in smaller chunks.
It is a good idea to group related bits of code in their own functional areas for improved readability and cohesiveness.
Having a whole large program all in a single file will make your project very difficult to debug, extend, and maintain. I think this is quite obvious.
The particular metric is really only a rule of thumb and should not be followed religiously, but it may indicate something is not as nice as it could be.
Whether legacy working code should be touched and refactored is something that needs to be evaluated. If you decide to do so, you should consider writing tests for it first, that way you'll quickly know whether your changes broke any required behavior.
几个月后再也没有打开过自己的项目吗？单个组件越大、越复杂，人们就越会问自己，这段代码是哪位天才写的，为什么他要这么写。
而且，永远不会有太多甚至足够的文档。因此，如果组件本身不太复杂且更小，则更容易重新理解它们
Never ever opened one of your own projects after several months again? The larger and more complex the single components are the more one asks oneself, what genious wrote that code and why the heck he wrote it that way.
And, there's never too much or even enough documentation. So if the components themself are lesser complex and smaller, its easier to re-understand 'em
这有点主观。分配最大循环复杂度指数的想法是为了提高代码的可维护性和可读性。
举个例子，从单元测试的角度来看，拥有更小的“单元”确实很方便。避免长代码将有助于读者理解代码。您无法确保原始开发人员永远处理代码，因此从公司的角度来看，分配这样的标准以保持代码“简单”是公平的
This is bit Subjective. The idea of assigning a maximim Cyclomatic complexity index is to improve the maintainability and the readability of the code.
As an example in the perspective of the unit testing, it is really convenient to have smaller "units". And avoiding the long codes will help the reader to understand the code. You cannot ensure that the original developer works on the code forever so in the company's perspective it is fair to assign such a criteria to keep the code "simple"
摘自文章对抗制造的复杂性 与 .NET 开发人员工具相关NDepend。 NDepend 擅长帮助团队管理大型且复杂的代码库。这个想法是，代码度量可以减少代码实现中人为制造的复杂性：
在我对 Scott Hanselman 的软件度量的代码度量进行采访时，Scott 有一个特别相关的评论。
基本上，当我解释冗长而复杂的方法会降低质量并且应该分成更小的方法时，斯科特问我：
软件复杂性是相对于人类认知能力的主观衡量标准。当某些事物需要人类努力才能理解时，它就会变得复杂。事实上，软件复杂性是一个二维度量。要理解一段代码，必须了解以下两点：
业务问题的复杂性在于程序的规范，降低复杂性意味着研究代码本身的行为。另一方面，当谈到实现的复杂性时，我们正在谈论制造的复杂性：它是制造的，因为它可以在不改变代码行为的情况下减少。
Excerpt from the articles Fighting Fabricated Complexity related to the tool for .NET developers NDepend. NDepend is good at helping team to manage large and complex code base. The idea is that code metrics are good are reducing fabricated complexity in the code implementation:
During my interview on Code Metrics by Scott Hanselman’s on Software Metrics, Scott had a particularly relevant remark.
Basically, while I was explaining that long and complex methods are killing quality and should be split into smaller methods, Scott asked me:
Software complexity is a subjective measure relative to the human cognition capacity. Something is complex when it requires effort to be understood by a human. The fact is that software complexity is a 2 dimensional measure. To understand a piece of code one must understand both:
Business problem complexity lies into the specification of the program and reducing it means working on the behavior of the code itself. On the other hand, we are talking of fabricated complexity when it comes to the complexity of the implementation: it is fabricated in the sense that it can be reduced without altering the behavior of the code.
它可以触发重构，但遵循一个指标并不能保证所有其他质量指标保持不变。而且工具只能遵循很少的指标。你无法衡量代码的可理解程度。
未必。有时，较大的代码可能更容易理解、结构更好并且错误更少。
例如，大多数设计模式通过使代码更加通用和可维护来“改进”您的代码，但通常会增加源代码行的成本。
It can be a trigger for a refactoring, but following one metric doesn't guarantee that all other quality metrics stay the same. And tools are only able to follow very few metrics. You can't measure to which degree code is understandable.
Not necessarily. Sometimes the larger one can be more understandable, better structured and have lesser bugs.
Most design patterns for example "improve" your code by making it more general and maintenable, but often with the cost of added source lines.