why

1. 为什么要做code review
• 技术讨论和互相学习：show the code，互相学习、共同进步
• 增强团队协作：Pair Work，互相backup，了解大家的context，避免出现重复工作
• by技术规约：code是否负责团队的规约
• by design：设计上有没有问题或者风险
• by code：是否readable & 是否有smell & 核心逻辑review。Code Review 有可能能够帮助发现一些隐含问题，但是寄希望于code review去发现所有的bug是不太现实的

2. code review不是为了什么
• 不是为了指责或者盯某个人的代码；
• 不是为了增加大家的工作量；
• 不是为了故障追责；

what

Review什么

1. by unit test
• 所有的测试用例是否都通过了
• 新feature测试用例的合理性
• 测试用例的完整性，corner cases是否有覆盖
• 是否符合团队的测试规范，比如哪里该mock数据，哪里该集成测试
• 单测的用例是否完整、合理，以及测试覆盖率这个关键数据。
• 可能需要回答的问题：

2. by 技术规约
• 主要指的是团队内部讨论和共识的一些标准和规约，比如API design规约、日志规范、事务规范等
• 当发现同样的功能，大家使用的库、写法不一样时，就需要有人拉起一个技术讨论，形成规约。如缩进、风格、thrift生成命令等，需要的是统一format

3. by design
• 当前的修改 会不会 对之前的某个feature/fix 不兼容，是否会让系统丧失演化能力
• 是否过度设计
• API 设计是否合理，是否符合规范，是否向前兼容，是否能不增加API (如无必要，不增实体)
• API as small as possible, as large as needed?
• Data Model设计、database设计，有没有更简单的方式
• Review code design方面，比如API设计、data Model设计，兼容性设计，演化能力确认、过度设计等
• 可能需要回答的问题：

4. by code
• 坏味道review，比如Optional代替 Null check，重复代码、冗余代码、深层次嵌套代码、修改不彻底的代码等。
• 可读性：类/函数/变量 命名、关键位置的注释、代码自解释性。可读性见仁见智，可以遵循的一个标准是`「如果我来改这个代码，我会有什么困难」`。在这个标准下，遇到变量名不足以表达意义、过度表达意义、变量名意义变更等情况，都需要修改变量名。
• 通常性问题：比如for循环中io，数据一致性问题、性能问题等
• SOLID原则，算法review
• 最后才是代码细节的review
• 需要回答的问题：

不Review什么

1. by code-lint
• 团队应该有自己的代码检查工具，大家的代码都符合这个工具，如果提交上来的代码，lint检查有smell，就不允许提交

2. 单次修改，以后再也不变动的，不需要review

3. 救火情况，可以先上线 再补review

4. 单次修改很多内容，reviewer无法在短时间内梳理清楚，reviewer可以直接说不review。大部分开发者的commit是不值得被review的，没有艺术感的commit，review下来完全是在浪费时间。

5. 没有单测 或者 单测覆盖率不够的代码 是可以不review的。

How

如何在团队的协作流程中执行下去

1. 代码和服务 需要有Owner。任何人都可以 review 他人代码，指定owner和reviewer，完全是为了避免三个和尚没水喝，不是只有指定的人可以review。

2. Code Review过程中 积极反馈和建议，对于反馈和建议 committer需要及时跟进处理，保证不断优化和改进：
• Reviewer千万不要吝啬你的反馈，即使反馈的是错的，你也得到一次纠正自己错误认识的机会，这太宝贵了。Reviewer和Committer重视沟通和交流，看代码的目的是为了得到代码之外的很多其他东西
• Reviewer的反馈需要出于善意，希望帮助到对方，希望这个系统更好，而不是恶意攻击别人
• Reviewer的反馈需要具体而且可以被执行。比如“这个地方写的不太好” 就是一个糟糕的反馈，“我觉得这个地方不太好，是不是这么这么重构一下会更好？” 就是一个具体且有举措的反馈
• Reviewer的反馈 也需要得到committer的行为反馈，该改进的 需要及时改进，该感谢的要敢于表达，感拜服的就拜服

3. 避免commit过大，单一职责，少量、多次、可work的方式逐步提交commit，多个commit可以作为一个整体 统一提交给reviewer：
• 单次commit 理论上是可以作为一个独立功能来发布的，善用patch，减少时间线的错乱
• 按照经验，单次修改 文件数不超过7个 可能会比较合适
• 如果自己的commit 不能得到review，可能需要思考下自己对于commit的切割和拆分是否有问题
• committer要对自己的每次commit负责，也要对reviewer的时间负责，绝大部分的commit都不配review，要努力让自己的代码值得review

4. 自己能不能+2 ?
• 能

5. 自己能 +2，会不会让code review 成为一种形式？
• Learning不足、风险不大的commit，可以快速 +2
• Committer和Reviewer在这个过程中 相互协作、建立技术沟通渠道、有所收获
• commit message标准、易读，可以快速获得关键的上下文信息
• Review 过程中需要有记录，包括 review 的结果、讨论和建议等，可以在群里 也可以在change页面

Commit message 规范

1. commit前缀
• feat: feature，添加新功能
• mod: 对已有功能的修改
• fix: bug fix
• docs: 添加/修改 comment、empty commit等
• refactor: 代码重构
• pref：性能优化，xx优化等
• test：添加测试用例
• revert / merge / build，一般不会自己写，要么是git自动生成的，要么是可以用其他前缀代替的

2. commit message
• 在commit message里 写明变更了什么，不用写为什么变更。为什么变更 可以写在review message里，而不用单独写
• 英文优先。如果英文不能明确表达，建议直接写中文，更不要写中文式英文。命名和注释也是这个原则

3. commit body
• 非必需，如果需要，可以写

可能的奖励机制

最后附上一张全文图