一名“码农”的心声：搞质量与写代码一样，体系是效率的保障

什么是死海效应呢？比如我们参考一段程序，不知道这段代码想干什么，甚至不知道它怎么就运行起来了，但是这么多人都用过了，那么此段代码非同小可，删除了说不定会出现“惊喜”的bug，还是留着吧……然后随着时间的推进，这种代码就形成了死海效应，后续的越来越多的需求覆盖在这个功能上，这种“祖传”代码就更没人肯修改了。

可能这仅仅是“码农”的烦恼，那我们其他类的设计人员呢？设计的冗余，设计的繁杂，过度的参数，无用的数据，都是对后期工作的巨大阻碍。在前期，没有记录可能确实会快很多，但是，长期迭代的项目没有文档，你觉得还会对效率有提高吗？我们可能做的工作仅仅是某一个部位的螺丝钉，可是我们身在一个系统里，对于整个系统而言，牵一发而动全身，每一个螺丝钉多拧的一圈都会产生意想不到的蝴蝶效应。

但是，在多人协作的场景下，如果代码风格不统一，就会浪费大量的时间在争论冲突上。其实，就像开车行驶一样，全靠左开可以，都靠右开也没错，但是，每个人都随意开的话就很危险了，所以靠右行驶的规则才会诞生，目的是为了让大家开车安全。

所以规范不一定是宣布谁的观点正确，而是为了降低多人协作时的无意义分歧，让大家把时间更聚焦于解决问题上面。

随着需求的不断增多，各个模块的关系越来越复杂，往往牵一发而动全身，这时的研发效率是被复杂度所拖住的，因为工程的复杂度往往与需求的数量是指数关系。质量体质的构建就是让大家遵守相同的规则，而相同的场景在相同的规则下具有相同的解法，这样，项目复杂度不随需求而上升，只受场景的影响，收敛工程复杂度，提升持续迭代项目的研发效率。

在大型项目里，开发人员或者试验人员的能力往往良莠不齐。同一个试验，可能精准完成，也可能导致数据作废，而标准就像是最佳实践的抽象，如果发现自己的操作不符合标准，说明肯定是有问题了，可以考虑优化或者重新开始了，让整个团队像一个人在最优状态下完成的一样，也是质量体系的目的之一。

《重构》一书中说过，出现问题的代码往往散发着相同的“bad smell”。同样，错误或者误差也存在同样的味道，我们通过纠正措施，用RCCA的方法将问题追溯并解决。我们将各组的最佳实践与问题沉淀到规范中，就是为了可以提前发现隐藏的bug，如果违反了红线级别的规则，说明操作已经出现预见性的危害或严重的性能影响，而违反建议性规范，可能对现阶段没影响，但是日后的重构或是修改可能会困难重重。ISO9001:2015要求“基于风险的思维”进行风险识别，形成针对性的运行控制模式，有序衔接对应过程人机料法环测与体系运行的适宜性，有效降低过程质量体系运行失效风险。

质量体系是整个系统工程的保护者，从需求阶段的文档保证，到开发过程中的操作规范，最后开发结束后的审核，都是为了保证流程足够的健壮，质量足够有保证。所以，前期质量上的投入或许拖慢了研发的进度，但是，体系的建设是为了后期更快地扩展功能，避免陷入bug的泥潭中，更大程度地提升研发效率。