袋鼠云数栈前端团队代码评审工程实践文档

代码评审指南介绍

部分文档中会用到一些术语，特在此说明:

MR: "Merge Request."的缩写，代表正在进行代码评审的变更
LGTM: "Looks Good to Me."的缩写，评审者批准MR时会这么说
SGTM: “Sounds Good To Me."的缩写，评审者批准MR时会这么说
WIP: “Work In Progress.”的缩写，如果你有个改动很大的 MR，可以在写了一部分的情况下先提交，但是在标题里写上 WIP，以告诉项目维护者这个功能还未完成，方便维护者提前 review 部分提交的代码

代码评审者提出的都是一些编码风格和代码规范的东西？

编码规范应该交给工具去做，代码需遵循数栈代码风格指南
为什么要鼓励为主而不是责罚并举？

众所周知代码评审并不容易施行，因为它是团队和个人长期才能感受到好处的过程，即使不做似乎也看不到啥影响，业务也照跑，而惩罚是阶段性的反馈，所以现阶段还是以鼓励为主，但是由于对代码提交人和代码评审人要求不同，对提交人的责任要求更大点。对审核覆盖率有要求，也有责任推进评审进度。对于代码评审主要是鼓励，因为代码评审是利他行为。在某些情况下会有一些惩罚要求：该模块很重要，引发了故障。而此问题是可以通过明显的评审发现的，此时也要承担责任
某个需求（项目）留给开发时间非常紧张时怎么办？

可以不进行代码评审，优先保证按时需求（项目）上线
周末出现线上紧急 bug 要遵循代码评审流程吗？

可以不进行代码评审，以快速修复 bug 为主，或者采取 onCall 的方式让维护者尽快评审