谈谈技术规范的制定

最新推荐文章于 2024-09-15 14:50:06 发布

weixin_34257076

最新推荐文章于 2024-09-15 14:50:06 发布

阅读量184

点赞数

文章标签：运维 python git

原文链接：https://my.oschina.net/neochen/blog/392762

版权

2019独角兽企业重金招聘Python工程师标准>>>

谈谈技术规范的制定

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

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

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

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

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

故事一

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

定期备份机制
代码注释要求
代码访问需要更高层的批准
详细的部署文档等等

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

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

就如公司规章制度写的清清楚楚，要求员工提交代码到版本库，但各种原因没有被执行，当代码丢失，从上至下追究责任，公司的损失无法挽回。在举一个例子，运维工作要求备份数据，A员工负责备份，B 员工负责检查A员工的备份，结果两年以后出事了，需要恢复数据，发现A没有备份，而B在一年前就再没有检查A的工作。起初前一年还是按流程备份，后来A发现B不再严格检查工作，备份工作逐渐减少，最后停止了备份，一直相安无事，直到事发。

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