Code Review
At Google, essentially every change is reviewed before being committed, and every engineer is responsible for initiating reviews and reviewing changes.
在谷歌，基本上，每一项变更在提交之前都要经过审查，每一位工程师都要负责发起和审查变更。
Google 中 80％ 的代码审查确实要求开发人员采取行动。这清楚表明代码审查对代码库有积极影响。但是那剩余的 20％ 呢？
Code Review 的好处
Checks code correctness （确认代码的正确性，高效的发现BUG）
Ensures the code change is comprehensible to other engineers （确保其他工程师能够理解代码更改）
Enforces consistency across the codebase （加强整个代码库的一致性，降低长期维护成本）
Psychologically promotes team ownership（从心理上促进团队所有权）
Enables knowledge sharing （实现知识共享）
Provides a historical record of the code review itself （提供代码评审本身的历史记录）
Code Review Flow （Google代码评审流程）
1、撰写变更快照 （ patch + description）
2、自审查（Critique）；静态分析（Tricorder）；发送变更给一个或多个评审者；
3、评审者对变更提供反馈
4、作者根据评审的结果进行修改或回复（然后再进入步骤3）
5、评审者同意变更（LGTM）
6、作者提交变更到代码仓库
Code Is a Liability（代码是一种责任）
Much like the fuel that an airplane carries, it has weight, though it is, of course, necessary for that airplane to fly.
是要记住（并接受）代码本身就是一种责任
代码审查不是重新讨论或辩论的机会
Google 如何开展 Code Review
Code Review 的实践
- Be Polite and Professional （礼貌并且专业）
- Write Small Changes （
小的变更 ） - Write Good Change Descriptions （撰写
好的变更描述） - Keep Reviewers to a Minimum （小团队Review）
- Automate Where Possible （尽可能自动化）
Code Review 的类型
- Greenfield reviews and new feature development
- Behavioral changes, improvements, and optimizations
- Bug fixes and rollbacks
- Refactorings and large-scale changes
总结
代码审查是谷歌最重要、最关键的流程之一。从测试到静态分析再到CI，几乎所有其他流程都依赖于此。
经验 & 分享
Code Review 的维度
-
清晰程度
- 代码风格（通过自动化工具）
- 可读性高、易于理解和维护
-
准确性
- 逻辑正确
- 新增功能、解决问题的同时不会引入其他问题
-
性能
- 没有潜在的性能问题
-
重复性
- 在当前的文件中，是否会出现多行代码在不同的地方出现。或者，当前代码在其他文件中出现。如果是，则意味着这需要重构
- 当前的功能是否在之前的代码中已经实现过了
-
兼容性
- 尽可能向前兼容（不任意删减变更现有的接口、结构体等）
-
外部依赖
- 确认是否必要。引入新的外部依赖，需要考虑潜在的功能安全
- 必须引入，使用尽可能轻量级的外部包
-
异常/边界处理
- 是否考虑到了所有异常和边界的情况
- 异常或边界的处理是否合理
其他 ...
关于提交履历：
[type]: [subject]
例如:
[fix]: fix build issues
•feat：新功能（feature）
•fix：修补bug
•docs：文档（documentation）
•style： 格式（不影响代码运行的变动）
•refactor：重构（即不是新增功能，也不是修改bug的代码变动）
•test：增加测试
•chore：构建过程或辅助工具的变动
