摘要：前些日在阿里技術公眾號回復了一個開發規范如何推廣的問題，獲得了蠻多點贊。參與制定規范如果你直接把阿里開發手冊扔給開發人員，大多數開發是抵觸的。阿里的開發手冊很詳細，但不建議你直接作為你企業的規范。

前些日在阿里技術公眾號回復了一個“開發規范如何推廣”的問題，獲得了蠻多點贊。故寫此一篇文章細講一下我們的推廣方式，給困惑的朋友貢獻一點思路。

領導要一盤西紅柿炒蛋，交給A,B,C幾個團隊去實現。團隊A沒控制好火候把雞蛋炒老了，團隊B只放了糖未放鹽，團隊C選用了已經餿了的西紅柿... 領導大怒: “我們的愿景是做全國連鎖餐飲，這么搞下去很快就完蛋！”，團隊leader也委屈，沒人告訴我這樣不行啊！

規范就是要告訴團隊成員哪些做法不行，使團隊不同成員的代碼盡可能做到標準統一，提高代碼質量，降低維護成本。

大領導交辦的事情你加班加點也會盡力做好，同樣規范的推廣如果沒有上層支持，最終的落地效果肯定大打折扣。如果上層未能意識到規范的重要性，你就要說服上層支持。
比如：匯總現有IT系統暴露的問題，重點梳理出代碼不規范、標準不統一導致的問題，說服IT上層支持推動規范落地，以帶來IT系統開發質量的提升和維護成本的降低。

如果你直接把《阿里Java開發手冊》扔給開發人員，大多數開發是抵觸的。阿里的開發手冊很詳細，但不建議你直接作為你企業的規范。
因為：開發場景不同遇到的問題就不同，阿里不出現的問題很可能你的企業會出現，比如一些循環SQL等問題。另外阿里手冊也不涉及技術棧規約，這些都需要你去制定。其他對于阿里手冊里適用的規范建議直接吸收進來。

開發規范制定的過程最好讓各個團隊leader都參與進來，貢獻內容。有個詞叫“稟賦效應”，比起你直接扔給他的，他更愿意推動自己參與制定的。

規范制定完成，與各個團隊leader達成一致后就要組織統一的全員培訓。把規范的制定過程以及規范背后發生的故事講給開發人員。
統一培訓后續如有新人加入，可以組織1v1講解或新人反講。

規范還有一個重要目的是可作為code review的準則，基于規范去做代碼檢查，保證代碼質量標準統一。

后續如發現新的問題，需要加入規范的，可以由開發人員或leader去補充更新到規范中（規范可以放WIKI上），保持規范持續可用。

diboot 簡單高效的輕代碼開發框架