共计 902 个字符，预计需要花费 3 分钟才能阅读完成。
前些日在阿里技术公众号回复了一个“开发规范如何推广”的问题，获得了蛮多点赞。故写此一篇文章细讲一下我们的推广方式，给困惑的朋友贡献一点思路。
开发规范很重要
领导要一盘西红柿炒蛋，交给 A,B,C 几个团队去实现。团队 A 没控制好火候把鸡蛋炒老了，团队 B 只放了糖未放盐，团队 C 选用了已经馊了的西红柿 … 领导大怒:“我们的愿景是做全国连锁餐饮，这么搞下去很快就完蛋！”，团队 leader 也委屈，没人告诉我这样不行啊！
规范就是要告诉团队成员哪些做法不行，使团队不同成员的代码尽可能做到标准统一，提高代码质量，降低维护成本。
如何推广开发规范？
1. 获得上层支持
大领导交办的事情你加班加点也会尽力做好，同样规范的推广如果没有上层支持，最终的落地效果肯定大打折扣。如果上层未能意识到规范的重要性，你就要说服上层支持。
比如：汇总现有 IT 系统暴露的问题，重点梳理出代码不规范、标准不统一导致的问题，说服 IT 上层支持推动规范落地，以带来 IT 系统开发质量的提升和维护成本的降低。
2. 参与制定规范
如果你直接把《阿里 Java 开发手册》扔给开发人员，大多数开发是抵触的。阿里的开发手册很详细，但不建议你直接作为你企业的规范。
因为：开发场景不同遇到的问题就不同，阿里不出现的问题很可能你的企业会出现，比如一些循环 SQL 等问题。另外阿里手册也不涉及技术栈规约，这些都需要你去制定。其他对于阿里手册里适用的规范建议直接吸收进来。
开发规范制定的过程最好让各个团队 leader 都参与进来，贡献内容。有个词叫“禀赋效应”，比起你直接扔给他的，他更愿意推动自己参与制定的。
3. 组织全员培训
规范制定完成，与各个团队 leader 达成一致后就要组织统一的全员培训。把规范的制定过程以及规范背后发生的故事讲给开发人员。
统一培训后续如有新人加入，可以组织 1v1 讲解或新人反讲。
4. 应用规范
规范还有一个重要目的是可作为 code review 的准则，基于规范去做代码检查，保证代码质量标准统一。
5. 更新规范
后续如发现新的问题，需要加入规范的，可以由开发人员或 leader 去补充更新到规范中（规范可以放 WIKI 上），保持规范持续可用。
diboot 简单高效的轻代码开发框架
