制定代码规范并不难，但你知道如何让它可执行吗？
|
副标题[/!--empirenews.page--]
《制定代码规范并不难，但你知道如何让它可执行吗？》要点： 策划：erichua23 编辑：郭蕾 回想起来自己工作这么些年,也经历了不少团队,经历的项目更不算少了,但是要说到代码规范,问我我经历的这些代码规范是不是满意,我不得不如实回答：不是很满意.当然我自己的代码规范和风格也没有完全固化下来,近一年左右也开始关注到这个问题,为了让自己的代码风格能逐渐固化,我会专门用一个笔记来记录一些可能自己会纠结的写法,这样做了以后明显能感觉到自己代码风格的飘忽程度有所收敛.恰巧公司负责的项目也需要整理代码规范,正因如此我开始思考 如何制定可执行的代码规范 这个问题. 提到团队的代码规范,不止我经历过的,我和一些朋友也有聊过,有微软那个级别的,也有 BAT 这种级别的,项目大的也有,小的亦很多.其中不乏规范的做的比较好的,有规范、有工具、还会有 Code Review 来保证.但是大公司规范和流程真的适合所有团队吗?我所看到的是大部分团队参照某某公司的规范和流程,定义了一个非常严格的标准,然而实际上并没有严格实施下去或者没有持续实施下去.最后都会甩锅给“历史包袱太重”、“开发人员太多太杂难以推广”这样的理由. 近半年到一年在代码规范这一块我主要思考如何在中小团队没有代码规范的基础上制定代码规范.根据自己的思考也正在组内逐步实践,从目前实践情况来看我是比较满意的,所以把自己观点写出来,希望能对跟我有同样困惑的人有些帮助. 代码规范不应该被定为 KPI所有的规范,包括但不限于代码规范,都会包含规范制定、规范推广执行、规范修正的过程. 其中规范的推广和执行通常是最难的(这就是为什么有很多流程文档,但是流程还是非常混乱的原因),而制定了什么样的规范直接决定了推广执行的难度,所以我们先从代码规范的制定说起. 大部分团队应该都是有 KPI 的,而且一般重要的事情都会被定成 KPI,所以有些团队为了强调代码规范,将其定为某些员工的 KPI,这样重视代码规范行为我是非常欣赏的,但是我不认同,因为我认为 代码规范不应该是一个文档,代码规范应该是一种行为,一种持续的行为,而 KPI 是要求可以量化有明确目标的.若把代码规范当作 KPI,背了 KPI 的员工为了让 KPI 可量化,通常情况会写出来一个代码规范文档,众所周知文档最可 量化的当然是页数,故最终可能会产出一个几十页的代码规范,它可能是结合了 Google、Facebook、Tencent 等等大公司的代码规范,几乎面面俱到,看起来就很高大上. 代码规范文档出来了,KPI 看起来也完成得不错,那然后呢?如果我们把代码规范理解为一种行为,那这文档就仅仅只是一个行为准则,它就像是一部法律,要求大家都要如何做,所以接下来更重点的工作应该是去让这些文档落地,让大家理解认可执行它.并且还需要有相应的监督机制、审查机制来保证大家确实按规范在写代码.但是后面这些,也就是整个代码规范实施最难的点,要量化又极其不易.能如何量化呢?量化推广程度?量化大家对各条代码规范的理解透彻程度?难道用考试来量化吗?这就是把代码规范设定成 KPI 的尴尬,为了让 KPI 看起来丰满,产出了一个丰满的规范,而对于整个过程中最难的落地执行环节,丰满的规范为其增加了阻力. 以前我对于代码规范的理解是也是越丰富越好,但是在近半年推广代码规范的过程中我开始青睐简单一些的代码规范,因为我相信大部分人会赞同：一个被 100% 彻底执行了的 40 分代码规范应该是好于一个被执行了 40% 的 100 分代码规范. 制定代码规范要循序渐进这个观点可能会更比较多人的看法不太一样,因为很多人都认为规范应该前期就定下来,而且尽可能面面俱到,否则后面定规范容易背上历史包袱.前期就应该定规范的这个观点我比较认同,首先我们抛开你们团队已经有非常完善代码规范这种情况,因为如果是那样,你只需要按原有规范执行即可. 这里主要讨论新项目没有规范的情况下怎么做,我们可以复盘一下新项目开始阶段,通常情况新项目需求节奏都会非常快,基础框架、基础组件、大批量业务需求要开发,又因为是新项目,通常不会有特别多的人力投入,这种情况下,一个很严格冗长的代码规范,要求大家在拼命跑的过程中还要去理解执行你的规范,可能性大吗?所以这个时期的代码规范需要非常简单易于理解,要在所有人即使在赶需求,也能忍受的范围内制定规范.这个阶段最急迫的需求是用简单的代码规范让大家养成习惯,提升意识,宣告这个项目是有规范的. 我们拿前端项目来举例,首先应该先保证 JS 代码风格是对的,其次可能根据技术选型不同(例如 Angular,React),要遵循另外一批 Best Practice.按上述思路,我会在前期只要求大家 JS 代码格式规范就行了.因为把各种 Best Practice 一股脑的全丢进去容易绕晕大家. 如果你真的舍不得那些 Best Practice,我建议将其列为建议级别的,先不做必须,必须的条目尽可能精简. 制定代码规范需要”独裁”上面一段提到代码规范应该循序渐进,但是简单的规范从何而来呢?之前看到过的一种做法是：团队内大家一起讨论,民主决定某一些规范的细节,因为这样可以出来一个适配这个团队的代码规范. 这听起来很美好,非常民主,大家很平等,但是回想一下以前这么做的结果是什么?我猜应该会有很多人又回忆起“大括号应不应该换行”、“else 是否应该换行”、“是否允许空两行”、“JS 结尾带不带分号”等等类似的争论吧,然而这些争论是有必要的吗?说白了,大部分争论找的理由都只是在为自己的代码习惯争取更多空间.这样的争论还只是“民主”引发问题的开始,更严重的是这会在所有开发人员心中形成一种“规范是可以商量和讨论的”心理暗示,这必对后续规范的执行成为阻碍,特别是一些本身就有争议的点,总会有人伺机反扑. 另外,“民主”的规范其实很难做到让所有人心理上平衡,例如可能会让 B 开发觉得自己在遵从 A 开发的习惯,即使这种感觉可能不是那么强烈,它也会变成规范执行的阻力. 正因为上述原因,我非常建议制定规范时“独裁”.我们的目标很清晰,就是要求代码写法一致,“独裁”的基础上可以选择一个第三方的标准,例如细的条目可以完全选择 Google 或者 Facebook 或者其他一些大公司的标准(当然可能还需要考虑我上面提到的循序渐进,做裁剪,但是规则细则不要再去讨论和挑战).首先可以保证的是这些规范不会有太大的问题,跟着做不会犯大错；其次,“独裁”使用的规范来源于第三方,对团队内所有人公平；最后,这样的规范和行业更亲近. （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
