问测量软件项目度量在今天的行业中流行吗？

EN

你的大学图书馆可能有一些关于指标的书，其中包括软件度量和软件质量工程中的度量与模型。那两个应该给你一个起点。在工业世界中，很少有公司有任何度量程序。

大多数公司是否都有某种方式，不一定非得是一个优雅的程序，才能衡量有意义的指标？

Visual包括一些代码分析工具，可以帮助您入门。大多数公司甚至没有最坏的度量标准:代码行。“只管完成”似乎是整个行业的压倒性动力，而对于可维护性的担忧却很少关注经理们的担忧：“我今年会得到奖金吗？”“这会在我承诺的时间内完成吗？”即使产品年复一年地进行增量更改，这两个关注点也使开发人员对可维护性和bug检测/预防的关注相形见绌。

哪些度量标准，单一的还是综合的，帮助您缩小您的项目范围和评估？

我发现圈复杂度和联轴器是一个强有力的指标，可以说明代码有多糟糕或者有多难维护。如果圈复杂度在20左右，我发现测试几乎是不可能的(因为它将有多达2^20条路径通过代码)，并且应该被分解成更小的部分。您不能消除复杂性，但可以将其分割成更易于管理的块。

如果您正在寻找估计值，您可能想要调查函数 积分。

代码覆盖率%正在大幅降低每次迭代，您是否提醒您的开发人员这个问题

我发现大多数经理都关心签入的数量和修复错误的数量。我的现任经理反对单元测试(他认为这是浪费时间)，而我的前任经理认为，花在单元测试上的时间本来应该花在编写它上。

开发人员使用的规范论点是，如果您测量某件东西，这只是您将得到的。这个论点源于这样的观点:唯一的衡量标准是代码行。

我在一次关于软件度量的演讲中，演讲者提出了一些有见解的观点，IMHO。我本人对这些事情没有什么经验，我仍然很好奇，也很有灵感，但我不能说它是错的还是对的。

主要的想法是：

• 任何单数度量本身都是有用的。
• 设置绝对目标(即XX %代码覆盖率)是没有意义的。
• 没有历史的度量是有用的。

因此，要解决这个问题：

• 显示几个指标，如：
  • of line总计/更改的
  • of提交
  • 代码覆盖率%
  • of test
  • 圈复杂度
  • 档案/包裹/..。依赖性
  • ..。

• 显示QA/CI中的数据:
  • of bug/增强/更改(我个人认为这种分类很重要)
  • total/added/fixed

• 在显示随时间变化趋势的图表上显示这些指标

这样，当票被迅速固定时，我们就可以看到代码质量是否下降。此外，当bug数据库似乎不会发生太多事情时，随着重构的完成，代码质量可能会提高。

总结一下:重要的是这种类型的动态行为，以及提供信息而不是原始数据的内容(这将是单个度量的值)。

我计划把一些图表，根据这个计划，在宽屏电视旁边，我们的CI连接熔岩灯。;)