如何在企业各团队间推广开发规范？

摘要：前些日在阿里技术公众号回复了一个开发规范如何推广的问题，获得了蛮多点赞。参与制定规范如果你直接把阿里开发手册扔给开发人员，大多数开发是抵触的。阿里的开发手册很详细，但不建议你直接作为你企业的规范。

前些日在阿里技术公众号回复了一个“开发规范如何推广”的问题，获得了蛮多点赞。故写此一篇文章细讲一下我们的推广方式，给困惑的朋友贡献一点思路。

领导要一盘西红柿炒蛋，交给A,B,C几个团队去实现。团队A没控制好火候把鸡蛋炒老了，团队B只放了糖未放盐，团队C选用了已经馊了的西红柿... 领导大怒: “我们的愿景是做全国连锁餐饮，这么搞下去很快就完蛋！”，团队leader也委屈，没人告诉我这样不行啊！

规范就是要告诉团队成员哪些做法不行，使团队不同成员的代码尽可能做到标准统一，提高代码质量，降低维护成本。

大领导交办的事情你加班加点也会尽力做好，同样规范的推广如果没有上层支持，最终的落地效果肯定大打折扣。如果上层未能意识到规范的重要性，你就要说服上层支持。
比如：汇总现有IT系统暴露的问题，重点梳理出代码不规范、标准不统一导致的问题，说服IT上层支持推动规范落地，以带来IT系统开发质量的提升和维护成本的降低。

如果你直接把《阿里Java开发手册》扔给开发人员，大多数开发是抵触的。阿里的开发手册很详细，但不建议你直接作为你企业的规范。
因为：开发场景不同遇到的问题就不同，阿里不出现的问题很可能你的企业会出现，比如一些循环SQL等问题。另外阿里手册也不涉及技术栈规约，这些都需要你去制定。其他对于阿里手册里适用的规范建议直接吸收进来。

开发规范制定的过程最好让各个团队leader都参与进来，贡献内容。有个词叫“禀赋效应”，比起你直接扔给他的，他更愿意推动自己参与制定的。

规范制定完成，与各个团队leader达成一致后就要组织统一的全员培训。把规范的制定过程以及规范背后发生的故事讲给开发人员。
统一培训后续如有新人加入，可以组织1v1讲解或新人反讲。

规范还有一个重要目的是可作为code review的准则，基于规范去做代码检查，保证代码质量标准统一。

后续如发现新的问题，需要加入规范的，可以由开发人员或leader去补充更新到规范中（规范可以放WIKI上），保持规范持续可用。

diboot 简单高效的轻代码开发框架