制定代码规范并不难，但你知道如何让它可执行吗？

我在我们的前端项目里面就选择了 StandardJS 的规范,StandardJS 的出现初衷也正是为了解决上述“民主”引发的问题.除此之外,还有一个好处是这些第三方规范的成熟不只是规范本身,它的配套工具会成熟很多,可以节省自己很多成本.

代码规范从“立法”到“执法”

上面我们已经讨论了如何建立代码规范,主要强调了 代码规范不应只是一纸空文、代码规范要循序渐进、代码规范的制定需要“独裁”.这些都属于“立法”过程,接下来要讨论的必然是“执法”,代码规范的“执法”主要需要关注两点,一点是“违法”行为的判定,另一点是“违法”行为的责任追究,也就是代码规则检查以及发现不符合规范的代码应该由谁来负责.

代码规则检查通常直接使用现有成熟工具就好,例如前端开发常用的 ESLint,现在各种语言都有各自比较成熟的工具,我这里想强调的是几个检查代码的时机,一是写代码的时候,这是源头,配置一个好的 IDE 检查规则能从源头避免不规范的代码.二是提交时候,通常是设置 git/svn 的 hooks(PS: git 的 hooks 在 2.9.0 之前相当的难用,如果你用的版本低于 2.9.0,可以考虑升级并配置代码检查的钩子).三是 CI 的时候,这是最后一关,可以保证合流以后的代码不出现规范的问题.只要在上面三个点严格执行了,不规范的代码几乎已经无处可藏.

“违法”行为判定尽可能通过工具来判定,那如果出现了库里面提交了不合规则的代码应该由谁去改呢?如果有 CI,那只需要增加提交构建,即可在 push 后的第一时间揪出违规者.如果没有 CI,我建议是先建立 CI,如果实在没有,那可以考虑最后提交代码负责制,最后提交代码的人可以去找这份代码是 merge 了谁的,追溯到上游把“锅”丢出去,最终找到违规者并要求改进(不限于代码的改进,更重要的是各种代码检查环境的配置).这样的定义可以让所有开发知道遇到问题以后该如何走下一步,我认为是非常有必要的.

说到这里我猜必然有读者想到了 Code Review,实际上 Code Review 不应该是去关注代码风格的,所有到 Code Review 环节的代码必然是要过了代码风格检查的,Code Review 主要关注的是代码结构设计和代码逻辑,它是在代码规范上一层的东西.如果你的团队在使用 Code Review 来保证代码规范,那你们可能需要进一步完善自己的代码规范检查工具.

总结思考

代码规范的好处大家都知道,但是任重道远.真正去推行代码规范的人,如果按我上面说的几点去做,可能会有各方面的压力,特别是上面提到的“独裁”和“执法”两点,但是从我自己的实践经验来看,想象中的压力小于实际,主要还是需要向同事们解释清楚各种做法的理由,得到理解和支持.为了避免前期的推行的压力过大,可以考虑裁剪规则(特别是在没有很好代码规范文化的团队内),因为提升团队人员意识和养成代码规范的习惯应该是最最首要的任务,这两点有了以后,再逐步的把要求提高,应该会容易得多.这个过程有困难,但是我坚定的认为这是值得的.

文章来自微信公众号：聊聊架构

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!