软件度量与软件质量间本就不该有 "直接" 的关连

软件度量一直是软件开发中最容易引起争议、也最难能说服团队的一项吃力又很不讨好的工作。

@ 定个测试覆盖率的指标；每个团队的测试覆盖率都是 90% 以上，但在这 90% 以上的测试覆盖率，所形成的测试防护网里，却往往连个 “有效” 测试线上运维的测试用例都没有。

@ 定个单位代码行的缺陷率的指标；团队就总是只纠结着那个 “分母”；到底应该是百行还是千行。

@ 定个告警为零的指标；团队就总是在熬夜清告警，却又总是忘了应该要思考下，清完了一个告警，所会真正带来的商业价值为何？更忘了市场所要求的响应速度与自己的身体健康状况。

@ 定个用户满意度的指标；团队又总是只为了获得高的用户满意度，而忘了市场所需要的创新与创新所需要的试错。

我不是说软件度量这件事情有问题、不对。

而是软件度量这件事情，是很容易就被 “个人的利益”、“个人的主观意识”，甚至是 “个人的自尊心” 所给扭曲、所给区解的。

所以，我们也许该换个角度看看 “软件度量” 与 “软件质量” 之间的关系。

@ 首先，也许我们就该认为软件度量与软件质量之间是 “没有” 任何 “直接” 的关系的；也就是说，没有任何的软件度量能 “完全、直接、正确” 的界定软件质量的好、坏、优、劣。

@ 当软件度量与软件质量之间没有任何直接的关系时，那软件度量要拿来做什么？软件质量又要从何而来？

@ 软件度量应该是要用来做 “决策”的。

@ 软件质量的界定；好、坏、优、劣；应该是来自于 “决策”，而不是直接的来自于软件度量。

也就是说，当团队知道如何的针对自身产品、团队的问题，而能制定出所需的软件度量时，并能从软件度量中做出适当的决策，自然而然就能把握有限的开发人力与时间，却能产出符合用户预期与市场竞争力的产品。更重要的是，能保证团队成员的身体健康状况的良好。

所以，我们不应该将软件度量与软件质量直接的就藕合在一起；而是要将软件度量与软件质量之间，以 “决策” 将两者给完全的隔离。

因为，只有这样，才会使得软件度量成为软件开发上的一个相当有用的 “决策工具”。当软件度量成为一个有用的决策工具时，软件度量才不会因为前述的人类行为上的偏差，而被扭曲、而被曲解。