谈谈技术规范的制定

几乎所有的技术企业都会重视技术规范，但这些规范起到的实质作用就好比“请保持室内卫生，不准乱团垃圾，禁止随地吐痰”。

笔者工作15年，这是15年经历了很多，也在不同的公司任职过。几乎每到一家公司都会遇到各种规范，随着职业发展最后我也成为了规范的制定者，也曾经主持制定过开发规范，运维规范，测试规范等等。

我做过很多规范，文档无数，技术人员根本不会去看，通过开会向下传达，开会的人根本没有心思理会你的规范，规范执行阻力是很大的，效果也差。

终于有一天我意识问题的存在，开始反思，企业是否需要制定这些规范。我发现这与现环境有很大关系，与企业文化有很大关系。

有些强制的规范可以通过一些技术手段，避免出现。不会出现也就无需规范！

故事一

例如下面一个小故事，公司某部因为将开发数月的代码丢失了，导致测试无法进行，领导打发雷霆，某管理层制定了下面的规范，大意为。

1. 定期备份机制

2. 代码注释要求

3. 代码访问需要更高层的批准

4. 详细的部署文档 等等

我认为源码管理主要有两种手段，技术手段与管理手段。

我先谈谈管理手段： 例如通常通过规章制度，责任追究等等手段，要求员工达到规范标准，但通常执行力都会打折，无法达到预期，人的不稳定性因素太多。往往发现员工没有按照规范操作为时已晚，将该员工辞退也无法挽回公司的损失。

就如公司规章制度写的清清楚楚，要求员工提交代码到版本库，但各种原因没有被执行，当代码丢失，从上至下追究责任，公司的损失无法挽回。

所以我主张技术手段： 例如源码如果发布到线上，必须经过版本库，只能使用自动部署，不允许程序员私自将代码交给运维手工部署。另外发布代码的同事，可以不提供生产服务器登陆权限，他只能通过工具发布代码。 部署流程如下： 源码(程序员) 提交到development 分支UAT阶段 ----> 合并到 testing 分支Beta阶段（主管合并，程序员没有权限）------> master 分支(主管合并) -----> 自动部署系统(运维) ----> 生产服务器。 这样通过技术手段防止了代码因员工离职，硬盘损坏等等原因，导致代码丢失的可能。 代码发布者也无需对照部署文档，手动登陆服务器逐条按照部署说明书操作，防止了人员误操作，也提高了部署效率，节省了人力成本，通常在5分钟之内可以完成所有部署。

故事二

我再来举另外一个例子，就是开发中的编码规范，很多软件企业都有是不是？

例如要求程序员： if (){} 要写成 if () { ... } 等等要求不一一列举，甚至组织代码评审解决编码规范问题。

我的建议为什么不在IDE上设置自动格式化，或者在svn/git提交的时候通过hook调用格式化程序。

故事三

管理层要求运维每天发送服务器状态报告，运维人员需要登录每个服务器或者从cacti等工具中获得服务器运行状态数据，然后制作一个报告文档，每天给各位发送一次。

运维需要一个专职人员做这个报告，这种报告几乎没有人看，就像“人民日报” 人民从来不看。

当运维事故该出现的时候还是会出现，老板一个一个骂，扣工资，扣奖金，运维觉得委屈，公司受到损失。平日里的这些工作并不能避免运维事故，也不能改善运维工作。

故事四

在举一个例子，运维工作要求备份数据，A员工负责备份，B 员工负责检查A员工的备份，结果两年以后出事了，需要恢复数据，发现A没有备份，而B在一年前就再没有检查A的工作。起初前一年还是按流程备份，后来A发现B不再严格检查工作，备份工作逐渐减少，最后停止了备份，一直相安无事，直到事发。

故事五

我曾经遇到过一个兢兢业业的管理者，他制定规范，要求值班的同事7*24小时，每间隔一定的时间做一次操作，验证系统正常运行，以便能够第一时间通知运维处理故障。值班的同事而偶偷懒，他就半夜起来监控他们工作。一个打工者能做到如此，真让人佩服。 但是我们有更好的方法，真的不必如此操劳且效率低下。

这些故事是一个无休止的死循环

出问题 -> 发上制定规范 -> 无人看/看了慢慢淡忘/石沉大海 -> 继续出问题。连续出现问题，采用行政手段处分，扣奖金等等。很多管理者将其归咎为 “执行力” 弱，我并不这么认为。

我觉得很多规范是形式主义。我一向主张实用主义。

通过技术手段可能避免很多没有意义规范，开发自动化，测试自动化，运维自动化，这是趋势也是我的努力的目标。

本文摘自 https://www.linkedin.com/pulse/%E8%B0%88%E8%B0%88%E6%8A%80%E6%9C%AF%E8%A7%84%E8%8C%83%E7%9A%84%E5%88%B6%E5%AE%9A-neo-chen