Code Review

代码审查是软件开发过程的一部分，可以在早期避免错误代码合并到进入项目中， 方便团队维护代码和产品质量。

为什么代码审查至关重要？

如果没有人把控输入的代码，只管一个劲地堆砌，久而久之，这坨代码也就失去秩序，成一团乱麻了，人见人嫌。所以在工程的一开始就引入代码审阅，可以非常有效地提高代码质量。

更重要的是，Code Review 是一个双向的过程，双方借助针对具体代码的交流，得以了解对方的想法，进行互相探讨，这是帮助团队中的成员成长，赋予团队自我管理、良性发展的能力。

代码审查有以下好处：

• 及时发现错误：人都会不可避免的出现一些纰漏，而这些纰漏在另一个人眼中也许显而易见。通过编码和健壮性检测，尽量减少出问题的机会。目前团队由于缺乏自动化测试环节，质量问题带到线上的风险会很高，更需要在开发环节做好自检工作。
• 每个人对项目的代码都会很熟悉：通过阅读别人的代码，更加熟悉项目结构。
• 技术功能
• 代码可读性：随着代码审查的覆盖，团队风格的统一，大大提高代码可读性，新人加入可以更快的投入到生产中。
• 互相学习，提高水平，营造工程师文化：代码审查最终的作用将归到促进工程师日常代码交流和人员的成长上面来。团队在 Code Review 前期重点会是找问题（代码规范、潜在缺陷、BUG，代码设计等等），而随着互相学习，后期问题会逐渐减少，Code Review 习惯逐步养成，工程师交流文化的营造将转化成重点。

代码审查者应该关注哪些方面？

代码审查时应该关注以下方面：

• 设计：代码是否经过精心设计并适合系统？

• 功能：代码的行为是否与作者的意图相同？代码是否可以正常响应用户的行为？

• 复杂度：代码能更简单吗？将来其他开发人员能轻松理解并使用此代码吗？

• 测试：代码是否具有正确且设计良好的自动化测试？

• 命名：开发人员是否为变量、类、方法等选择了明确的名称？一个好名字应该足够长，可以完全传达项目的内容或作用，但又不会太长，以至于难以阅读。

• 注释：注释是否清晰有用？

• 风格：代码是否遵守了风格指南？

• 文档：开发人员是否同时更新了相关文档

如何进行代码审查？

审查的实施分析：

1. 强制&非强制： 按照经验，CodeReview 启动前期建议采用强制要求，否则很难有效开展起来。坚持一段时间待习惯养成后再考虑自由度。
2. 小片段&大模块：如果想要让问题暴露更充分或降低 review 的难度，建议采用细粒度方式进行，即小片段提交小片段 review。如果更关注全局设计和逻辑思路的学习和找茬，那么可以用模块方式统一 review。但很多时候这两种方式是可以结合运作的。
3. 线上交流&线下会议：大团队采用线上方式效率很高，但是需要配套的 Code 平台，如果更喜欢全员一起找茬的那种快感，那么可以采用线下会议方式开展。
4. 事前&事后：这里指的是发布前还是发布后。版本发布后统一进行CodeReview的方式更多是一种代码交流活动， 起不到代码质量把关的作用。反之，如果在版本发布前就对代码进行 CodeReview，就可以对质量问题起到很好的把关作用。这里是时间和质量之间的权衡。
5. 高频率&低频率：代码交流频率越高越好。具体根据团队实际情况进行安排即可，目前采用发布前审查。

代码审查常用的方式有代码管理工具审查、结伴编程、线下审查等。目前团队采用线下审查方式。

审查的前置条件：

在进行代码审查时，开发人员应该确保：

• 代码设计精良。
• 该功能符合产品预期。
• UI 符合设计。
• 代码并不比它需要的复杂。
• 没有实现他们将来可能需要，但不知道他们现在是否需要的东西。
• 代码有适当的自测。
• 使用了清晰的名称。
• 注释清晰有用，且大多用来解释为什么而不是做什么。
• 代码符合我们的风格指南。

每一行

审查每行代码。有时如数据文件、生成的代码或大型数据结构等东西，可以快速扫过。但不要快速扫过开发人员编写的类、函数或代码块，并假设其中的内容是 OK 的。审查人员必须做出的判断某些代码需要比其他代码更仔细的审查，至少应该确定审查人员理解所有代码正在做什么。

如果审查人员觉得这些代码太难以阅读导致减慢您审查的速度，尝试继续审核前要让开发者为程序做出解释，也能帮助未来的开发人员理解这些代码。

上下文

例如，审查人员可能只看到添加了四行新代码，但是当审查人员查看整个文件时，会看到这四行是添加在一个 50 行的方法里，所以需要作者概要的阐述上下文，如果涉及 UI 的，给出 UI 原型和运行时 UI 表现。方便审查人员了解具体情况。

鼓励

如果您在代码审查中看到一些不错的东西，请告诉开发者，特别是当他们以一种很好的方式解决了审查者的一个评论时。代码审查通常只关注错误，但也应该为良好实践提供赞扬。在指导方面，比起告诉他们做错了什么，有时更有价值的是告诉开发人员他们做对了什么。

记住你是一个「人」

无论是在 review 代码还是写代码的过程中，必须要始终记得一件事情：你是一个「人」，并且你 review 的代码的作者也是一个「人」。

在审查代码时，有问题或者发现作者没注意到一个边界条件的时候，保持友善的态度。即使是写了多年“完美无缺”代码的老鸟，有些时候也应该把他们当作会犯错误的普通人来看待。即使那些与你共事很久的人并不在意你拿他们开玩笑，总会有新人不理解的。

被很多人改动过的，并且在不断更新的代码必然往往是奇怪的、复杂的，特别是那些已经存在了许多年的代码。还有很多时候开发工作是十分仓促的，开发人员需要在有限的时间完成尽可能优质的代码。我们并不能为了完美的代码耽搁项目进度，但是我们需要保证我们写的每一份代码尽可能的好，无论我们在写代码还是在 review 代码。