开发规约的意义与细则
作者：鸽子
出品：大淘宝技术
众所周知，制订交通法规表面上是要限制行车权，实际上是保障公众的人身安全。试想如果没有限速，没有红绿灯，没有靠右行驶条款，谁还敢上路。消防局最主要的工作不是灭火，而是为了不发生火灾建立很多规范。如果发生火灾，说明前面的工作没有做到位。同理，对软件来说，开发规约绝不是消灭代码内容的创造性、优雅性，而是限制过度个性化，推行相对标准化，以一种普遍认可的方式一起做事。
综上所述，开发规约的目标：
码出高效：标准统一，提升沟通效率和研发效能。
码出质量：防患未然，提升质量意识和系统可维护性，降低故障率。码出情怀：工匠精神，追求极致的卓越精神，打磨精品代码。
开发规约从无到有，只是短期的目标；使大家遵守开发规约的成本极大降低，发布上线的应用符合开发规约是中期目标；而远期目标是从有到无，因为人人自觉遵守，规约和谐地融入代码的字里行间，规约似乎消失了，但又无处不在。
最近，结合新品技术团队的现状，分析了系统架构背后的问题，并制定了一系列团队开发规约，可以从以下三方面展开。
大纲
- 开发规约之道
- 开发规约之术
- 开发规约执行方法论
开发规约之道
1.代码规范不应该被定为 KPI
大部分团队应该都是有KPI的，而且一般重要的事情都会被定成 KPI，所以有些团队为了强调代码规范，将其定为某些员工的KPI，但是这并不能达成好的效果，因为代码规范不应该是一个文档，代码规范应该是一种行为,一种持续的行为，而 KPI是要求可以量化有明确目标的。若把代码规范当KPI，背了KPI的员工为了让KPI可量化，通常情况会写出来一个代码规范文档，众所周知文档最可量化的当然是页数，故最终可能会产出一个几十页的代码规范， 几乎面面俱到，看起来很高大上。但是要求大家按照文档落地就很难，让大家理解认可执行它，并且还需要有相应的监督机制、审查机制来保证大家确实按规范在写代码。结合当前团队现状考虑，后者是整个代码规范实施的难点，
因为大部分人会赞同：一个被 100% 彻底执行了的 40 分代码规范应该是好于一个被执行了 40%的100分代码规范。
2.制定代码规范要循序渐进
代码规约的实施不是一蹴而就的，是一个过程，需要团队能够在编写代码过程完全做到规范是需要时间的，所以初期技术有必要在评估项目开发周期中做好时间buffer，后期慢慢形成一种行为意识时，便是做到从无到有的状态。 通常情况新项目需求节奏都会非常快，基础框架、基础组件、大批量业务需求要开发，又因为是新项目，通常不会有特别多的人力投入，这种情况下，一个很严格冗长的代码规范，要求大家在拼命跑的过程中还要去理解执行你的规范，可能性大吗？所以这个时期的代码规范需要非常简单易于理解，要在所有人即使在赶需求，也能忍受的范围内制定规范。这个阶段最急迫的需求是用简单的代码规范让大家养成习惯，提升意识，宣告这个项目是有规范的。
3.制定代码规范要独裁
上面一段提到代码规范应该循序渐进，之前看到过的一种做法是：团队内大家一起讨论，民主决定某一些规范的细节，因为这样可以出来一个适配这个团队的代码规范。
这听起来很美好，非常民主，但是这么做的结果是什么？我猜应该会有很多人又回忆起“大括号应不应该换行”、“else 是否应该换行”、“是否允许空两行”、“JS 结尾带不带分号”等类似的争论，然而这些争论是有必要的吗？说白了，大部分争论找的理由都只是在为自己的代码习惯争取更多空间。这样的争论还只是“民主”引发问题的开始，更严重的是这会在所有开发人员心中形成一种“规范是可以商量和讨论的”心理暗示，这必对后续规范的执行成为阻碍，特别是一些本身就有争议的点。
正因为上述原因，制定规范时需要“独裁”。我们的目标很清晰，就是要求代码写法一致，“独裁”的基础上可以选择一个第三方的标准，例如细的条目可以完全选择集团内部的标准。首先可以保证的是这些规范都是有理有据； 其次,“独裁”使用的规范来源于权威的标准体系，对团队内所有人公平；最后,这样的规范和行业更亲近。
带你读《2022技术人的百宝黑皮书》——开发规约的意义与细则（2）https://developer.aliyun.com/article/1339988?groupCode=taobaotech
