code-review 规范

CR 是什么？

字面意思，就是对他人的代码进行评审。

在团队的初期，我们经历了业务上的冲刺，赶代码的同时忽略了定期的 CR，有可能会引发如下问题：

1. 重复造轮子（如：咚咚来客 c 端的 qrCode 页面，重复的轮子高达 14 个）

2. 注释较少，比较难理解

3. 逻辑实现复杂 || 错误等

CR 的目的

提高团队代码质量，相互学习，团队互动

怎么做

1. 持续执行

每个迭代完结的时候进行一次 code review，交叉排查缺陷（绝大多数 BUG 都可以在代码层面被发现，甚至测试难以覆盖到的深层次 BUG 也可以通过团队成员相互审核而避免）

2.全员参与

代码是团队共有的知识财富，大家对所有代码的最终质量负责，完成功能只是开始，代码需要持续改进以成长为更好的研发人员。

3.及时的响应

reviewer 花费时间为你的代码提出更优的解决方案，我们应该尊重 ta 的成果，好的方案及时采纳修改并致谢，有不同的观点共同讨论成长。

要求：

说明 comment 等级。reviewer 对相应代码段提出评价时，需要指明对应等级，如

• fix: xxxxxxx 此处需强制修改，提供修改建议

• advise: xxxxxxx 此处主观上建议修改，不强制，可提供修改建议

• question: xxxxxx 此处存在疑虑，需要 author 作出解释

  友好 comment。评价注意措辞，可以说“我们可以如何去调整修改，可能会更合适。。。”，对于比较好的代码，也应该给与足够的赞美。

  享受 review。避免以挑毛病的心态 review，好的 reviewer 并不是以提的问题多来衡量的。跳出自己的编码风格，主动理解 author 的思路，也是一个很好的学习过程。

颗粒度：

1. 原则上不纠结于代码风格，交给 eslint/stylelint/tslint 处理（严重的写法错误除外）

2. 代码冗余，可读性差，注释少

3. 代码可扩展性，设计是否合理，是否有更优秀的方法。

4. 挑我们需要关注的问题，不求多但求精。

保持乐观的心态接受别人的 review。团队成员的 review 不是对你的批判，而是帮助你的提升，所以要尊重别人的 review，如果 review 你感觉不正确，可以在下面提出疑问，进一步解释。

对于 review 过程中发现的问题整理后会制成在线 docx 表格，处理对应内容后修改状态，如下图：

cr-detail