软件指标是否兼容

Tom*_*Tom 6 code-metrics

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

也许我错过了一些新人,但是,这将如何使我们的软件变得更好?,我知道软件指标可以衡量你的代码有多好,但是相反,它的工作方式却相反吗?我们的代码会变得更好,因为例如我们将10000行文件制作成4 2500行文件吗?

ewe*_*nli 6

指标的目的是更好地控制您的项目.它们不是自己的目标,但可以帮助提高整体质量和/或发现设计不和谐.圈闭复杂性只是其中之一.

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

您应该尽量避免意外的复杂性,但如果处理具有基本的复杂性,那么代码将会更加复杂.然后尝试编写可维护的代码,在方法数量和大小之间取得公平的平衡.

一本值得关注的好书是" 面向对象的实践指标 ".


blo*_*art 5

这取决于你如何定义"更好".较小的文件和较少的圈复杂度通常使维护更容易.当然代码本身可能仍然是错误的,单元测试和其他测试方法将有助于此.这只是使代码更易于维护的一部分.