1. 行为准则

2. 代码评审

2.1. 代码评审是一种给予和接受反馈的专门的形式

2.1.1. 大多数团队会在合并代码的修改之前进行代码评审

2.1.2. 评审不是一个证明你有多聪明的机会，也不是一个橡皮图章式的官僚主义障碍

2.2. 高质量的代码评审文化有助于所有具有不同经验水平的工程师的成长，并促进他们对代码库的共同理解

2.3. 糟糕的代码评审文化会抑制创新，减慢开发速度，并且导致滋生怨恨情绪

2.3.1. 执行不力的代码评审会成为一种有害的阻碍

2.3.2. 轻率的反馈不提供任何价值，还会拖慢开发人员的速度

2.3.3. 缓慢的周转时间会使代码的变化停滞不前

2.3.4. 如果没有正确的评审文化，开发人员可能会陷入反复拉锯扯皮的分歧中，这可能会毁掉一个团队

3. 为什么需要评审代码

3.1. 评审可以捕捉bug并保持代码整洁

3.1.1. 代码评审的价值不仅仅是让人来代替自动测试和代码质量检查工具

3.2. 优秀的代码评审可以作为一个教学工具，传播认识，记录实现的决策，并提供代码的更改记录以确保安全性与合规性

3.2.1. 你可以从别人评审你的代码给予的反馈中学习

3.2.2. 评审者会指出那些你可能不知道的有用的类库和编码实践

3.3. 代码评审也是了解你的团队的编码风格的一种简单方法

3.4. 评审整个代码库的变更可以确保不止一个人熟悉生产环境中代码的每一行，对代码库的共同理解有助于团队更有凝聚力地扩展代码

3.4.1. 让别人知道你在改什么，意味着一旦出现了问题，你不是团队中唯一可以仰仗的人

3.5. 被记录下来的评审意见也是一种文档

3.5.1. 解释了为什么事情会这样做

3.5.2. 需要以某种特定方式编写代码的原因并不总是显而易见的

3.5.3. 可以作为实现决策的档案

3.5.4. 有旧的代码评审作为参考，可以为开发人员提供一份书面的历史记录

3.6. 安全性和合规性政策通常规定了代码评审作为一项防范措施来防止任何一名开发人员恶意修改代码库

4. 当你的代码被评审时

4.1. 一个精心准备的评审请求可以使开发人员很容易理解你在做什么并提供有建设性的反馈

4.1.1. 保持单个代码的小幅改动，将特性和重构工作分到不同的评审中，并写出描述性的提交信息，务必将注释和测试包括在内

4.2. 用评审草案降低风险

4.2.1. 代码修改的草案是一种思考和提出相应修改的很棒的方式，这种方式不需要投入那么多时间来编写测试、打磨代码和添加文档

4.3. 提交评审请勿触发测试

4.3.1. 在本地调试某项失败的测试比在CI环境中更容易一些

4.3.2. 不能在远程计算机上附加调试器或轻松地获取调试信息

4.4. 预排大体量的代码修改

4.4.1. 预排会议

4.4.1.1. walk-through

4.4.1.2. 一种面对面的会议，开发人员在会上共享他们的屏幕，并引导队友了解正在进行的修改内容

4.4.1.3. 是启发想法和让你的团队适应代码修改的好方法

4.5. 评审意见是针对代码的，而不是针对你个人的

4.5.1. 甚至都不算是你的代码，将来整个团队会拥有这些代码

4.5.2. 得到很多评论是一种完全正常的现象，尤其当你是团队中经验不足的开发者之一时

4.6. 保持同理心，但不要容忍粗鲁

4.7. 不要羞于要求别人评审你的代码

4.7.1. 让代码评审一直悬而未决是不体谅他人的做法

5. 评审别人的代码时

5.1. 分流评审请求

5.1.1. 当你收到评审请求的通知时，你作为评审者的工作就开始了

5.1.2. 大多数的修改是不那么紧急的

5.1.2.1. 如果紧急度不明确，请询问提交者

5.1.3. 你不需要评审每一项代码修改，要专注于那些你可以从中学习的修改和你熟悉的代码

5.2. 给评审预留时间

5.2.1. 代码评审类似于运维工作，其规模和频率在某种程度上无法预知

5.2.2. 大型的代码评审可能需要进行额外的计划

5.3. 理解修改的意图

5.3.1. 不要一上来就以提交评论的方式开始你的评审工作，首先要阅读并提出问题

5.4. 提供全面的反馈

5.4.1. 需要对代码修改的正确性、可实施性、可维护性、可读性和安全性提供反馈

5.4.2. 指出那些违反代码风格手册、难以阅读或令人困惑的代码

5.4.3. 阅读测试用例并寻找bug以验证代码的正确性

5.4.4. 寻找OWASP十大违规行为

5.4.4.1. SQL注入攻击、敏感数据泄露和跨站脚本攻击的漏洞

5.5. 要承认优点

5.5.1. 代码评审不一定全都是负面的评论

5.6. 区分问题、建议和挑剔

5.6.1. 并非所有的评审意见都有相同的重要性

5.6.2. 重大问题需要比中性的建议和肤浅的挑剔投入更多的关注

5.6.3. 在反馈前加上“可选”(optional)、“接受或不接受”(take it or leave it)或“非必须”(nonblocking)的字样

5.7. 不要只做橡皮图章

5.7.1. 可能会迫于压力，在没有真正看清楚的情况下就批准了某项评审

5.7.2. 要抵制那种用草率批准的方式快速给评审盖上橡皮图章的诱惑，橡皮图章式的评审是有害的

5.7.3. 期望一次性就能充分评审一项巨大的代码改动是不合理的

5.8. 不要只局限于使用网页版的评审工具

5.8.1. 代码评审通常在一个专门的UI中处理

5.8.2. 代码评审本身也只是代码而已

5.9. 不要忘记评审测试代码

5.9.1. 评审者经常会忽略测试代码，特别是当变更比较大的时候

5.9.2. 测试代码应该像代码的其他部分一样被评审

5.9.3. 一定要检查测试代码的可维护性和清洁度

5.10. ⑩推动决断

5.10.1. 不要成为促成“夭折”的原因，要帮助提交者评审以迅速批准他们的代码

5.10.2. 坚持质量，但不要成为不可逾越的障碍

5.10.3. 尊重正在进行的修改的范围

5.10.4. 如果对代码修改有重大分歧，而你和作者又不能解决分歧的话，请主动提出把这个问题移交给其他专家，他们可以帮助解决相关分歧