从事web开发已有7个年头，经历过几个团队和不少项目，也面试过一些开发者。
发现不同公司对代码规范这一块的要求相差很大，有的公司甚至没有规范。
究其缘由，无非是项目紧张，没有时间整理。
久而久之，随着项目不断变大，维护变得困难，各种问题暴露出来：代码可读性差、修改容易出bug、逻辑混乱。。。
所以在技术上稍有追求的团队都意识到规范的重要性。
代码规范的意义
先思考一个问题：什么是好的代码?
你可能给出很多意见，比如：
· 少用全局变量。
· 高内聚，低耦合。
· 遵循单一原则。
· 拥有注释说明。
· 。。。
站在开发者个人层面来思考问题，所有这些“独善其身”的道理都正确。
但如果更进一步，站在团队的角度，考虑到维护代码的开发者会不断地变更;加入时间维度，考虑到代码会不断地被修改。
什么样的代码才是好代码?
曾经看到有位作者说“风格一致”的代码就是好代码，即团队所有人写出来的代码就像是一个人所写的。这个观点我非常赞同。
有的读者可能会反驳，代码写得一样就是好吗?要是团队成员水平很低，写得代码都很烂呢?
首先，如果团队成员水平都很低，那么写出来的代码不会是“风格一致”，而会是“风格迥异”。
回想自己最初编程的时候是不是经常在网上搜索代码，然后直接赋值粘贴再改改，发现能用就觉得OK了?
这种质量的代码不仅成员之间写的代码具有风格差异，就连同一个开发者写的代码也会有所不同。
“风格一致”背后的意义是什么?
现在的开发工作被不断分化，前端、后端、交互设计师、产品经理。。。
这符合英国经济学家亚当斯密在《国富论》中提出的“分工带来效率”，但是带来的最大问题就是沟通(这里的“沟通”指信息的交流方式)成本上升，例如前端和设计师沟通可能通过psd文件，和后端沟通会通过API。
所以会有REST API设计风格，会有GraphQL。本质上都是在形成共识，降低沟通成本。“风格一致”的代码规范的作用就和它们一样，旨在降低开发者因写作风格差异而带来的维护成本。因为代码虽然是运行在机器上，但终究还是给人看的。
为了形成好的代码规范，都有哪些方式?
看不见的规范
看不见的规范指的就是“靠人规范”。
这是最简单粗暴的方式，依赖开发者个人经验来指点入职新人进行代码编写，或者依靠偶尔进行的代码分享和评审。
所有的代码规范都在开发者脑袋里，基本靠语言传递。
这种靠“口口相传”的开发规范，对于学习者来说因为无文档可查，全凭个人记忆。
所以根据个人经验不同、记忆力不同，不同的开发者会有不同的规范，难以保证代码风格一致。
看得见的规范
很多团队都会用编写各种规范文档。
百度、谷歌上随手一搜“开发规范”，可以找到大量的文章。
这种方式解决了规范执行依赖“老员工靠经验，新员工靠记忆”的问题，因为形成了文字，一方面可以修订，一方面可以查看。
但是文档终究只是文档，即使文档写得再好，但代码还是可能写得一团糟。
执行效果的保障成了新的问题~
无处不在的规范
在这种情况下代码检验工具应运而生，开发者可以把编码规范写成配置文件，再配合工具对代码进行检验。
同时在开发环境中使用插件来实时提示开发者遵守校验规则。
即使开发者提交了不符合规范的代码，也可以在部署之前用多种方式阻止代码部署，比如利用git的钩子程序或者在持续集成中进行检验。
这种方式很具有工程思维，能合理利用工具解决问题，这样的代码已经基本具有“风格一致”的特点了。但校验工具的作用也是有限的，无法理解代码语义。
理想的代码规范
既然这些都不完美，到底有没有更好的解决方案?
没有~也有~
确实没有找到一劳永逸的工具或方法，但是值得庆幸的是我们可以把他们结合起来：使用静态校验工具来规范代码的基本书写规范，然后对于校验工具无法完成的规范写成文档，最后通过代码合并时的代码审查进行保障。
例如我为现在前端项目的规范就包括多种形式：
· 对于脚本语言TypeScript和预处理语言Sass，直接省略了规范文档，采用的是使用对应的校验工具tslint和sasslint，编辑器集成的插件可以及时提醒开发者遵循规范，对于有疑问的错误信息也很容易在网上进行查找。
· 对于比较灵活的部分，如变量命名、文件创建以及代码内容则采用文档描述加上代码评审的方式，评审方式为互评，先由其它开发者查阅代码进行评论，然后再转给管理员进行审核。
当然这种方式在初期的磨合成本是会略高一些，比如校验规则没有文档说明，评审耗费时间等。但是随着开发不断进行，这种成本会不断降低到趋近于0，因为代码写的越多对规范越熟悉，评审改进次数越多也能促进团队在编码上达成共识。
最后
懂得避免的问题胜过懂得解决问题，好的规范能避免写出糟糕的代码，为以后节省大量重构、修复bug的时间。