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

笔者工作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