3种常见的代码规范类型

从事web开发已有7个年头,经历过几个团队和不少项目,也面试过一些开发者。
发现不同公司对代码规范这一块的要求相差很大,有的公司甚至没有规范。
究其缘由,无非是项目紧张,没有时间整理。
久而久之,随着项目不断变大,维护变得困难,各种问题暴露出来:代码可读性差、修改容易出bug、逻辑混乱。。。
所以在技术上稍有追求的团队都意识到规范的重要性。

代码规范的意义

先思考一个问题:什么是好的代码?

你可能给出很多意见,比如:

  • 少用全局变量。
  • 高内聚,低耦合。
  • 遵循单一原则。
  • 拥有注释说明。
  • 。。。

站在开发者个人层面来思考问题,所有这些“独善其身”的道理都正确。
但如果更进一步,站在团队的角度,考虑到维护代码的开发者会不断地变更;加入时间维度,考虑到代码会不断地被修改。

什么样的代码才是好代码?

曾经看到有位作者说“风格一致”的代码就是好代码,即团队所有人写出来的代码就像是一个人所写的。这个观点我非常赞同。

有的读者可能会反驳,代码写得一样就是好吗?要是团队成员水平很低,写得代码都很烂呢?

首先,如果团队成员水平都很低,那么写出来的代码不会是“风格一致”,而会是“风格迥异”。
回想自己最初编程的时候是不是经常在网上搜索代码,然后直接赋值粘贴再改改,发现能用就觉得OK了?
这种质量的代码不仅成员之间写的代码具有风格差异,就连同一个开发者写的代码也会有所不同。

“风格一致”背后的意义是什么?

现在的开发工作被不断分化,前端、后端、交互设计师、产品经理。。。
这符合英国经济学家亚当斯密在《国富论》中提出的“分工带来效率”,但是带来的最大问题就是沟通(这里的“沟通”指信息的交流方式)成本上升,例如前端和设计师沟通可能通过psd文件,和后端沟通会通过API。

所以会有REST API设计风格,会有GraphQL。本质上都是在形成共识,降低沟通成本。“风格一致”的代码规范的作用就和它们一样,旨在降低开发者因写作风格差异而带来的维护成本。因为代码虽然是运行在机器上,但终究还是给人看的。

为了形成好的代码规范,都有哪些方式?

看不见的规范

看不见的规范指的就是“靠人规范”。
这是最简单粗暴的方式,依赖开发者个人经验来指点入职新人进行代码编写,或者依靠偶尔进行的代码分享和评审。
所有的代码规范都在开发者脑袋里,基本靠语言传递。
这种靠“口口相传”的开发规范,对于学习者来说因为无文档可查,全凭个人记忆。
所以根据个人经验不同、记忆力不同,不同的开发者会有不同的规范,难以保证代码风格一致。

看得见的规范

很多团队都会用编写各种规范文档。
百度、谷歌上随手一搜“开发规范”,可以找到大量的文章。
这种方式解决了规范执行依赖“老员工靠经验,新员工靠记忆”的问题,因为形成了文字,一方面可以修订,一方面可以查看。
但是文档终究只是文档,即使文档写得再好,但代码还是可能写得一团糟。
执行效果的保障成了新的问题~

无处不在的规范

在这种情况下代码检验工具应运而生,开发者可以把编码规范写成配置文件,再配合工具对代码进行检验。
同时在开发环境中使用插件来实时提示开发者遵守校验规则。
即使开发者提交了不符合规范的代码,也可以在部署之前用多种方式阻止代码部署,比如利用git的钩子程序或者在持续集成中进行检验。
这种方式很具有工程思维,能合理利用工具解决问题,这样的代码已经基本具有“风格一致”的特点了。但校验工具的作用也是有限的,无法理解代码语义。

理想的代码规范

既然这些都不完美,到底有没有更好的解决方案?

没有~也有~

确实没有找到一劳永逸的工具或方法,但是值得庆幸的是我们可以把他们结合起来:使用静态校验工具来规范代码的基本书写规范,然后对于校验工具无法完成的规范写成文档,最后通过代码合并时的代码审查进行保障。

例如我为现在前端项目的规范就包括多种形式:

  • 对于脚本语言TypeScript和预处理语言Sass,直接省略了规范文档,采用的是使用对应的校验工具tslint和sasslint,编辑器集成的插件可以及时提醒开发者遵循规范,对于有疑问的错误信息也很容易在网上进行查找。
  • 对于比较灵活的部分,如变量命名、文件创建以及代码内容则采用文档描述加上代码评审的方式,评审方式为互评,先由其它开发者查阅代码进行评论,然后再转给管理员进行审核。

当然这种方式在初期的磨合成本是会略高一些,比如校验规则没有文档说明,评审耗费时间等。但是随着开发不断进行,这种成本会不断降低到趋近于0,因为代码写的越多对规范越熟悉,评审改进次数越多也能促进团队在编码上达成共识。

最后

懂得避免的问题胜过懂得解决问题,好的规范能避免写出糟糕的代码,为以后节省大量重构、修复bug的时间。


作者信息:朱德龙人和未来高级前端工程师。