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

正文

请到「今天看啥」查看全文

代码规范文档出来了，KPI 看起来也完成得不错，那然后呢？如果我们把代码规范理解为一种行为，那这文档就仅仅只是一个行为准则，它就像是一部法律，要求大家都要如何做，所以接下来更重点的工作应该是去让这些文档落地，让大家理解认可执行它。并且还需要有相应的监督机制、审查机制来保证大家确实按规范在写代码。但是后面这些，也就是整个代码规范实施最难的点，要量化又极其不易。能如何量化呢？量化推广程度？量化大家对各条代码规范的理解透彻程度？难道用考试来量化吗？这就是把代码规范设定成 KPI 的尴尬， 为了让 KPI 看起来丰满， 产出了一个丰满的规范， 而对于整个过程中最难的落地执行环节， 丰满的规范为其增加了阻力。

以前我对于代码规范的理解是也是越丰富越好，但是在近半年推广代码规范的过程中我开始青睐简单一些的代码规范，因为我相信大部分人会赞同：一个被 100% 彻底执行了的 40 分代码规范应该是好于一个被执行了 40% 的 100 分代码规范。

制定代码规范要循序渐进

这个观点可能会更比较多人的看法不太一样， 因为很多人都认为规范应该前期就定下来，而且尽可能面面俱到，否则后面定规范容易背上历史包袱。前期就应该定规范的这个观点我比较认同，首先我们抛开你们团队已经有非常完善代码规范这种情况，因为如果是那样，你只需要按原有规范执行即可。

这里主要讨论新项目没有规范的情况下怎么做，我们可以复盘一下新项目开始阶段，通常情况新项目需求节奏都会非常快，基础框架、基础组件、大批量业务需求要开发，又因为是新项目，通常不会有特别多的人力投入，这种情况下，一个很严格冗长的代码规范，要求大家在拼命跑的过程中还要去理解执行你的规范，可能性大吗？所以这个时期的代码规范需要非常简单易于理解，要在所有人即使在赶需求，也能忍受的范围内制定规范。这个阶段最急迫的需求是用简单的代码规范让大家养成习惯，提升意识，宣告这个项目是有规范的。

请到「今天看啥」查看全文