上次讲到了“代码行，一个被用坏的高端指标”，也许标题应该改为 “代码行，其实也可以很高大上”。本文将接着介绍一些你已听过的无数遍，且应该“放弃的指标”。 从一个案例，重新思考指标的应用。
接下来，和大家解密一个10年前，悍马机器人项目的度量指标，看看HW的项目是如何进行度量的。
在正式介绍之前，先说一说如何看待当前知识大爆炸的年代。你曾经或现在，通过搜索引擎、线上线下、收费的、免费的获取大量的知识。如何把获取的知识构建自己的知识体系，不做认知界的“王语嫣”。这个，也许比度量本身更有用。
项目背景：这是一个全新的项目，从0开始构建，项目启动之后，客户提供的一个叫OR的东西，给我们讲解了一遍，后由开发和测试人员共同编写用户故事，并进行反串讲，客户项目经理和总架构师作为需求验收方听我们对用户故事讲解，理解存在差异的，及时提出修正或讨论，这个过程持续了三周左右。 后面基本按迭代的方式进行，在研发二个月后，我们还现场参观了生产线，了解现在机器人的运作方式，回来后对一些场景进行了修正，这也是当时客户架构师未识别到的。
我们来看一下，当时这个项目主要使用以下13个指标进行度量。 本文着重介绍和代码行作为基数参考的单元测试个数、CodeReview缺陷个数，SDV测试缺陷个数，SIT测试缺陷个数，SDV用例个数，SIT用例个数。
你是否觉得很奇怪，我写多少个单元测试、设计多少用例、发现多少个缺陷，与代码行有啥关系？
你是否还发现，居然发现缺陷的数据还有一个最小值，这又是什么神奇的东西。
为什么需要把千行代码行(KLoc)作为参考：我个人理解这是一个经验值，如果不以代码行参考，我们估计只能凭想像我们的案例是否写得差不多了，你是写10个案例呢，还是100个案例呢，要不要继续思考一下有没漏什么呢，等等都是一个问题。 当然你写够了数，也不代码你就真的覆盖全了，还是需要进行评审的。
为什么要设计最小值：拿缺陷来说，我们相信，是个开发就会埋下缺陷，聪明的会埋下聪明的缺陷，初级的会埋下低级的缺陷。没有找到只是你还没有发现，并不是你不会犯错。
再来看看这几个指标的责任人
指标责任人说明
看到此处，你是否明白了什么？我能不能少写几行代码，实现同样的功能。既节约自己寻找缺陷、编写SDV案例等的时间，也节约测试人员编写案例和执行案例时间。
如果哪位大哥有copy paste, 恭喜你，开发和测试是一样受累的，这里不详述。 测试也充分理解开发， 若非必要，他也不会难为自己，一起加班努力提高质量吧。
这些指标如何落地，真心不太容易。我们是经历过一个痛苦的过程去学习才最后得以达成的。前置指标达成，不能往后一步流程走。这又何尝不是一个实实在在的质量内健的案例。
团队里最开心的事：开发自己找到缺陷，测试自己找到缺陷，相互找到缺陷... 其实我们最开心的事，这个缺陷不会在生产上发生。
相信你也许看明白了，我们鼓励发现缺陷，我们认为本身就应该有这么多缺陷是正常的，我们也不相信神话。我们同时指标设计也是相互约束的，无公害的，高度协同的。
不再赘述太多，如果对你有所感，请思考未来如何有效在你所在场景的度量。也期望你能够成为高手，建立自己的知识体系。借用一代宗师里面的一句话：见自己，见天地，见众生。
也以此文献给一起在悍马机器人项目上奋斗的15位兄弟姐妹。一起让代码覆盖率、可维护指数超过了80%。
