为度量寻找合适的数据，有点像科学，有点像艺术，但更多的是试错。当决定使用哪些数据时，我们会面对很多选择。显然，你可以提出多种多样的测度，能获得相同的结果，或者发生几乎等同的一件事。例如，要决定一个程序员的质量测试有多好，我们可以选择去测量编写的测试用例数、代码的测试覆盖率，或者发现的bug数量和严重性。我们也可以测量所有这些。一般来说，当我不得不在多个可能使用的测度中去选择时，我基于以下经验法则来决定最优方案：选择最容易获得的数据。选择最容易让非程序员解释和理解的数据。第一条经验法则或许平淡无奇，但第二条法则看起来就有点古怪了。为什么要关心非程序员能够解释和理解那些测度和数据呢？这条法则对清晰性、简单性进行了专门测试，也就是说非程序员（例如测试人员或者技术作者）应该也可以理解那些数据，并且知道这个数据是怎样关联到软件开发的。因为好的度量的一个关键好处是它们具有很好的描述性，以及随之而来的沟通改善和合适行为的驱动。度量和之后的数据能够易于理解是非常根本的。这条法则可以重写为“选择更简单的测度”，或者只是“保持简单”。但是我喜欢用非程序员能够解释和理解的测度和数据进行测试。例如，考虑如何测量代码的复杂度。一个办法是通过源代码的统计分析，产生可供分析的各种数据，比如关键字频度、方法的长度、嵌套层级和圈复杂度。你也可以通过程序员用于改变特性、修复bug的时间，或者一定时间里bug出现的比率来测量代码复杂度。就我而言，相对于自动代码分析，我更赞成通过花费的时间和发布后的问题数量来测量复杂度。这是因为这个数据一般更容易获得，并且更易于让哪些非程序员或类程序员解释和理解。在我看来，这些数据能够让度量也变得更易于解释和理解，从而也更强大而有用。