代码审查的主要目的是确保代码库的整体代码健康状况随着时间的推移而改善。代码审查的所有工具和过程都是为此目的而设计的。
# （why）为什么要代码审查
Peer review—an activity in which people other than the author of a software deliverable examine it for defects and improvement opportunities—is one of the most powerful software quality tools available. Peer review methods include inspections, walkthroughs, peer desk checks, and other similar activities.
- Karl E. Wiegers
上面这句话大概意思是: 同行评审软件交付物作者以外的其他人在其中检查缺陷和改进机会的活动,是可用的最强大的软件质量工具之一。同行评审方法包括检查、排查、同行桌面检查和其他类似活动。
1.尽早发现 Bug 和设计中存在的问题,统一编码风格.
2.知识共享，获得最佳实践（如果在您的代码被审查时某个人建议一种更好的方法去做一些事）
3.提高代码质量（当人们知道有人在阅读信息时，他们往往会写的更好）
4.了解项目状态，至少有另一个人熟悉你的代码
# （who）谁做代码审查
项目经理/架构师/相关开发人员/比你更资深的程序员，希望得到他们的专业反馈
# （how）如何进行代码审查
# 1 规范标准
- 原子性提交。一个提交包含一个不可分割的特性、修复或者优化，同时这个提交要尽可能小。(提交尽可能小可以聚焦，让错误/问题 一目了然)
- 使用统一的代码风格 （阿里巴巴JAVA开发规范）
- 当遇到代码冲突出现共识冲突的情况，通过视频/面对面询问的方式，而非通过代码审查评论来解决冲突。
# 2 审查的时机
最好的审查时机是，功能分支自测完成后，需要合并到 develop 分支申请提测前。越往后修改成本越高。
提交 ：原则上至少一天提交一次。
审查：代码审查理论上可以在任何碎片化时间进行，推荐在每天早上或者下班前抽出一段固定的时间审查前天/当天提交的代码。
时间：单次代码审查的时间保持在5-20分钟
# 3 代码评审应该关注的重点
- 代码设计是否合理，是否有违背基本的设计模式理念（SOLID）
- 代码的行为是否符合作者的预期，是否明显的逻辑错误
- 是否符合系统的代码规范
- 代码的可读性和可维护性是否良好，是否可以更简单。
- 类，变量，方法等命名是否清晰
参考资料
Google 工程实践文档:github.com/google/eng-…