你的代码写得怎么样？如果你不属于平庸的80%，我敢打赌你的代码一定写得很棒。也许你正在维护遗产代码（不再被广泛支持的系统相关的源代码），这些代码究竟能有多糟糕？情况会有所好转吗？虽然有一套方法可以帮助评估你的代码，然而并非每个人都对此表示认可。

　　优点

　　我个人认为评估数据非常有用。通过类似Emma这样代码覆盖率计算工具，能够让你彻底了解你的代码中究竟哪些已经被测试覆盖，还有哪些没有被测试到。在开始着手某个包进行大规模代码重构之前，目标代码的覆盖率究竟如何？这些信息会告诉我，也许应该在改动代码前先提高一下这部分的代码覆盖率。

　　代码行数是另一个种有意思的数据。当你在遗产代码上工作的时候（谁不是在这样的代码上工作呢），如果你既能够保持开发速度（你肯定还在开发新的功能），又能保持与过去相同甚至更少的代码，那么你不但能够在交付价值而且同时还能让代码变得不那么糟糕。任何一个傻瓜都能够写出成堆的新代码以完成新功能，但是真正的高手能够在交付新功能的同时减少原有的代码。

　　缺点

　　任何数据都会面对一个问题，那就是利用这些数据的人。你最不想看到的恐怕就是过度渴望监控这些数据的经理了。

　　不能度量就无法控制。– Tom DeMarco

　　在你得到数据之前，报告缺陷数量就已经和奖金挂钩了。还有可能大家都希望代码覆盖率能够达到某个“期望值”。

　　只要管理层用数据作为目标，聪明人就会利用系统作弊。我已经数不清有多少次看到人们对代码覆盖率造假了。虽然初衷很好，但经理们受到错误思想的误导。为了讨经理开心，开发者会不断编写没有断言的测试。当然，代码依然能够运行而且不会出什么大问题。但这种行为有意义吗？天知道！当你的代码引入了新bug，那些测试能够检测到吗？见鬼，当然不会！因此，这种代码覆盖率毫无用处。

　　尽管达到了指标，但是潜在的目标即改进软件质量却被忽视了，而且未来也不会达到。

　　丑陋之处

　　任何评估的目标都是评测代码并从中得出有意义的数据。以代码覆盖率为例，我们真正感兴趣的是缺陷覆盖率。也就是代码中的所有可能的缺陷，有多少缺陷能够在测试中被发现？我们想知道，能够在怎样的程度上能够避免重写代码。

　　问题在于，我怎样才能衡量一个系统中“所有可能的缺陷”？基本上这是不可能知道的。为此，我们使用代码覆盖率作为近似。考虑到测试能够保证代码运行得到正确的结果，因此被执行代码率是对能够捕捉到bug数量的一个很好的预测。如果我的测试执行了50%的代码，最好的情况下我们能够捕捉到50%的bug。如果bug出现在另外50%的代码中，那么通过我的测试捕捉到这些bug的几率为0.代码覆盖率是测试覆盖率的一个上限。但假如你的测试代码很差，那么相应的测试覆盖率也会降低。至于没有断言的测试代码，它们基本上毫无用处。

　　这就是测量数据困难之处：测量那些真正管用的数据即我们的软件的质量。即便有可能，也是非常困难的。因此，我们要尽可能地进行测量，但并不总是能够清晰地知道哪些内容与我们真正目标相关。

　　这些数据意味着什么？

　　有很多类似Sonar这样的优秀工具能为你的代码进行各种常用的数据评测。通常的问题在于，开发者并不了解（或者在意）这些数据的含义。类的复杂度是17.0是好还是坏？我的代码关联系数是5.6%，但是也许有更好的理由这么做。怎样的数据对这段代码而言才算是合理的？LCOM4（缺乏内聚性的方法指标）是好事还是坏事？坦率的说，这听起来更像是治疗癌症。

Tags：郑州北大青鸟软件学院2018年招生要求,2018年河南的高考生选择什么专业好呢,郑州北大青鸟计算机编程序开发专业就业形势,2018年计算机互联网什么行业有前途,2018年没被录取学什么专业技术好呢,郑州Python培训学校哪家比较正规靠谱