规范在研发工作中的价值

在日常的研发工作中，经常会遇到一些规范。编码规范、代码提交日志规范、提测流程规范，版本号规范等等。

这些规范离我们很近，影响着研发过程中的不同的环节，因为工作的原因，我也负责或参与了一些规范的制定及发布，这些规范现也应用于研发过程的不同阶段。

有时我也在想为什么需要有规范，规范的价值到底是什么，研发的过程为什么需要有规范？

想来想去总结了以下这7条

规范制定是基于一定的历史背景，解决具体的问题作为目标而产生。规范符合当下团队大部分同学的需要，规范中的内容的产生有着背后的理由和逻关系。

规范是一种标准，这个标准适用于某一类人群，适应于某一具体的流程。当超过这类人群或流程范围，规范就有不同。同一个规范项，不同的角色理解也有不同。

规范是基线，部分规范低于这条线，在通常也不会产生什么问题，但是在特定的场景下就会产生问题。但养成了一种习惯，就会在特写的场景生效。

规范的传播效率高，传达的内容稳定，针对具体的问题的解决方案在个人的心中算是经验，经验经过多方的论证，形成了规规，以文本或富媒体的方式发布出来，那就可以快速的检索，可快速传播。对于团队的人员变动，新人增加，不需要重复的讲解。

规范是逐级优化持续化产生的产物，要定什么规范，规范的适用范围，在这个范围之内可以拆分多少个结点，每个结点应该遵守什么规则，每个结点还可以有子节点，每个结点的重要性，规则的等级，规则的示例等等。

规范在制定的过程，一般是多人共同参与完成，经过多轮的审核，试发布之后才会正式的发布。而发布之后的规范，也需要持续的优化与更新，这样规范的价值才可以持续。

在研发过程，规范可以是指导人与人协同的标准，也可以是指导人与机器的协同标准。这取决于将这个规范应用于团队协作和人机互动的流程中。

同时规范有三个核心的特性 1）可描述性；2）可实施性；3）可检测性；

可描述性：是指当前约定的内容，可以通过文字或其它载体方式描述，可以通过语言或媒体传播，并且内容对于适用范围中的人群是可以理解的。边界不清楚，定义不明确，约定不严谨，即使是描述清楚了，对于不同的人的理解也是有所不同。这里的可描述性，是指精确的描述规范；

可实施性：是指规范必须能在团队的日常工作当中使用到，可以针对一部分人群，也可以适用于某一个阶段的工作，如果一个规范，只是有理论的意义，而不能应用到具体的工作中，那这个规范就很难实施，则不具备可实施性。

可检测性：是指在规范的应用过程当中，每位相关人员的规范执行得好与坏可以检测的；对于规范的定制可以进行分级的约定，也可以在规范中举例，好的案例以及不好的案例。

如果这三个特性有一个不具备那么当前确定的约定就不能称为是规范，即使是规范确定下来了，在推进的过程中，也会遇到一些阻力，直到这三个特性确定了，规范自然就运转起来了。

总结来说，规范是由一类人群制定的，解决具体的或一系问题的，明文规定的标准；该标准适用的人群，指导其特定的场景下的工作方法。规范制定只是个开始，执行才是关键，在规范推进实施的过程中，规范优化的工作也会根据需要进行调整，规范从产生到作废，注定就是一个持续调优的过程。