Code Review Practice
目录
什么是Code Review
Google Code Review的描述
The biggest thing that makes Google’s code so good is simple: code review. At Google, no code, for any product, for any project, gets checked in until it gets a positive review.
让谷歌的代码如此优秀的原因很简单：代码审查。在谷歌，任何产品、任何项目的代码都不会在没有审查的情况下进入代码库。
是一种文化，不是制度
为什么需要
工作中的痛点
- 每个人代码风格不统一
- 接口、类各种命名不统一
- 深层逻辑问题，测试不容易发现
- 吐槽「这TMD谁设计的，各种坑（可能是几个月前的自己）」
可以带给我们什么
- 提升代码质量
- 团队知识共享
- 团队统一规范
- 形成好的代码文化共识
Review什么
Google Review的原则
What to look for in a code review
- Design: Is the code well-designed and appropriate for your system?
- Functionality: Does the code behave as the author likely intended? Is the way the code behaves good for its users?
- Complexity: Could the code be made simpler? Would another developer be able to easily understand and use this code when they come across it in the future?
- Tests: Does the code have correct and well-designed automated tests?
- Naming: Did the developer choose clear names for variables, classes, methods, etc.?
- Comments: Are the comments clear and useful?
- Style: Does the code follow our style guides?
- Documentation: Did the developer also update relevant documentation?
我们的Review原则
架构和设计
- S.O.L.I.D
- 单一职责原则（SRP）
- 开放封闭原则（OCP)
- 里氏替换原则（LSP）
- 接口隔离原则（ISP）
- 依赖倒置原则（DIP）
- 行为是否统一
- 缓存是否统一，错误处理是否统一，错误提示是否统一等等
- 同一逻辑 / 同一行为有没有走同一Code Path。低质量程序的另一个特征是，同一行为 / 同一逻辑，因为出现在不同的地方或者被不同的方式触发，没有走同一Code Path 或者各处有一份copy的实现， 导致非常难以维护
- DRY原则（Don’t repeat your self）
- 面向接口编程，而不是面向实现编程
- 健壮性
- 对Corner case有没有考虑完整，逻辑是否健壮？有没有潜在的bug？
- 有没有内存泄漏？有没有循环依赖?（针对特定语言，比如Objective-C) ？有没有野指针？
- 有没有考虑线程安全性， 数据访问的一致性
- 错误处理
- 有没有很好的Error Handling？比如网络出错，IO出错
- 效率 / 性能
- 对频繁消息和较大数据等耗时操作是否处理得当
- 关键算法的时间复杂度多少？有没有可能有潜在的性能瓶颈
Style
- 工程规范（工程结构，分层方式及命名等等）
- Apollo配置规范
- 命名规范（接口、类、方法名、变量名等）
- 代码风格（括号、空格、换行、缩进等）
- 注释规范（规定必要的注释）
- 日志规范（合理的记录必要的日志）
- DB SQL规范
- URL规范
如何进行Code Review
团队前置准备
- Git Branch Model
- Git Message（能说明提交内容的）
何时触发
使用工具
- Gitlab
- Sonarqube