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


中年|一名“码农”的心声:搞质量与写代码一样,体系是效率的保障
本文插图

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

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

中年|一名“码农”的心声:搞质量与写代码一样,体系是效率的保障
本文插图

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

每个人与生俱来的创造性 , 条条大路通罗马 , 可以得到结果的方法绝对不仅仅一种 。你有3种方法 , 我有8种方案 , 但在多人协作的工程中 , 如果没有规范的约束 , 大家自由发挥 , 项目就会杂乱无章 , 潜藏着兼容性bug 。也许有人会说 , 需求这不是完成了吗 , 没有出现问题 , 为什么要听这种束缚我创造力的规则? 因为多一种实现方式 , 就多一种出现bug的风险 , 如果遵循统一的标准规范 , 就可以收敛出错的情况 , 也利于之后重构改造 , “健壮”的流程是经得起反复改造与重构的 。现在用PYTHON的人很多 , 经常会发现这类问题 , 空格键用成了TAB键 , 或者TAB键用成了空格键 。这种代码风格的问题有正解吗? 没有 , 况且也没意义 。
中年|一名“码农”的心声:搞质量与写代码一样,体系是效率的保障
本文插图

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

中年|一名“码农”的心声:搞质量与写代码一样,体系是效率的保障
本文插图

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


推荐阅读