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

本文插图
大学开始成为“码农”的一员，入职后成为一名兼职质量员。过程记录的规范性一直是内审中常见的问题，可能有人会说这个要求很简单，就是需要记录的太多，试验都做完了，结果是好的，写那么详细记录所花费的时间我都能做好几个试验了。
为什么“祖传”代码没人肯修改
的确，记录的完善程序的执行是一项耗时的事情，他是有成本的。但是，无论是我们试验的执行者还是代码的编写者，记录的完善一是为了溯源问题，二是为了应对变更。作为预研单位，需求的变更很是频繁，所研究的对象不稳定性不确定性也很高，如果没有详细的文档或者记录的沉淀，就会出现死海效应。

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

本文插图
可能这仅仅是“码农”的烦恼，那我们其他类的设计人员呢？设计的冗余，设计的繁杂，过度的参数，无用的数据，都是对后期工作的巨大阻碍。在前期，没有记录可能确实会快很多，但是，长期迭代的项目没有文档，你觉得还会对效率有提高吗？我们可能做的工作仅仅是某一个部位的螺丝钉，可是我们身在一个系统里，对于整个系统而言，牵一发而动全身，每一个螺丝钉多拧的一圈都会产生意想不到的蝴蝶效应。
规范并不一定是表明谁正确
每个人与生俱来的创造性，条条大路通罗马，可以得到结果的方法绝对不仅仅一种。你有3种方法，我有8种方案，但在多人协作的工程中，如果没有规范的约束，大家自由发挥，项目就会杂乱无章，潜藏着兼容性bug 。也许有人会说，需求这不是完成了吗，没有出现问题，为什么要听这种束缚我创造力的规则？因为多一种实现方式，就多一种出现bug的风险，如果遵循统一的标准规范，就可以收敛出错的情况，也利于之后重构改造， “健壮”的流程是经得起反复改造与重构的。现在用PYTHON的人很多，经常会发现这类问题，空格键用成了TAB键，或者TAB键用成了空格键。这种代码风格的问题有正解吗？没有，况且也没意义。

本文插图
但是，在多人协作的场景下，如果代码风格不统一，就会浪费大量的时间在争论冲突上。其实，就像开车行驶一样，全靠左开可以，都靠右开也没错，但是，每个人都随意开的话就很危险了，所以靠右行驶的规则才会诞生，目的是为了让大家开车安全。
所以规范不一定是宣布谁的观点正确，而是为了降低多人协作时的无意义分歧，让大家把时间更聚焦于解决问题上面。

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

本文插图
在大型项目里，开发人员或者试验人员的能力往往良莠不齐。同一个试验，可能精准完成，也可能导致数据作废，而标准就像是最佳实践的抽象，如果发现自己的操作不符合标准，说明肯定是有问题了，可以考虑优化或者重新开始了，让整个团队像一个人在最优状态下完成的一样，也是质量体系的目的之一。
怎样才能提前发现隐藏的bug
《重构》一书中说过，出现问题的代码往往散发着相同的“bad smell” 。同样，错误或者误差也存在同样的味道，我们通过纠正措施，用RCCA的方法将问题追溯并解决。我们将各组的最佳实践与问题沉淀到规范中，就是为了可以提前发现隐藏的bug ，如果违反了红线级别的规则，说明操作已经出现预见性的危害或严重的性能影响，而违反建议性规范，可能对现阶段没影响，但是日后的重构或是修改可能会困难重重。 ISO9001:2015要求“基于风险的思维”进行风险识别，形成针对性的运行控制模式，有序衔接对应过程人机料法环测与体系运行的适宜性，有效降低过程质量体系运行失效风险。

本文插图
质量体系是整个系统工程的保护者，从需求阶段的文档保证，到开发过程中的操作规范，最后开发结束后的审核，都是为了保证流程足够的健壮，质量足够有保证。所以，前期质量上的投入或许拖慢了研发的进度，但是，体系的建设是为了后期更快地扩展功能，避免陷入bug的泥潭中，更大程度地提升研发效率。
征文选登
责编、美编｜许淼校对 | 张晓帆
监制｜陈伟宁
【来源：大飞机】
【中年|一名“码农”的心声：搞质量与写代码一样，体系是效率的保障】声明：转载此文是出于传递更多信息之目的。若有来源标注错误或侵犯了您的合法权益，请作者持权属证明与本网联系，我们将及时更正、删除，谢谢。邮箱地址：newmedia@xxcb.cn