代码审查那些事

代码审查(code review)是指对源代码进行系统化地审查，是软件开发中的最佳实践之一，代码合并之前必须审查通过才行，可及时发现隐藏问题，提高代码质量。

1 为什么要代码审查

代码审查环节，或者流于形式，或者根本没有，软件质量只依赖事后的测试；认真执行是有诸多价值的。

统一编码规范
审查代码风格，统一编码规范，有助于代码的可读性，也方便接盘者快速上手。

提前发现缺陷
代码审查最直接的优点是发现软件逻辑问题，性能等等潜在风险，提前发现缺陷可以有效节省人力和时间。

提高代码质量
代码审查与优化修复，确保代码在健壮性、设计合理性、代码结构等方面持续提升整体质量。

知识分享
每一次的代码审查都是一次知识的分享，磨合一定时间后，软件设计融合集体的智慧，团队内相互审查，也是互相学习的一种途径。

团队共识
经过讨论与交流逐步达成的团队共识，特别是对架构理解和设计原则的认知，在共识的基础上团队也会更有凝聚力，软件设计方式会趋于一致，特别是在较多新人加入时尤为重要。微信公众号【嵌入式系统】提醒，一些建议性的共识《代码的保养》。

2 代码审查原则

如果变更可提升整体代码质量，就可以让它通过，即使还不完美，这是代码评审准则的最高原则。没有完美的代码，只有更好的代码。评审者不应强求代码提交者在每个细节都写得很完美，应该考量修复时间与修改重要性之间的平衡。

以客观的技术数据为准，而非个人偏好。在代码排版样式上，遵从编码规范，所有代码保持风格一致，但如果新奇代码在编码规范未提及，那就接受作者的样式。同时有多种可行方案时，如果作者能证明这些方案基本差不多，那就接受作者的选择；否则，应以软件设计原则为准（参考《嵌入式软件设计原则随想》），而不应由评审者的个人喜好来决定。微信公众号【嵌入式系统】提醒，编码规范可以参考《嵌入式C编码规范》。

如果没有参考规则，那么评审者应该保证新代码与当前软件库风格一致，至少不会恶化软件的质量，一旦恶化就会带来破窗效应，导致软件质量逐渐下降。

代码审核者应该看什么

命名：变量、函数等命名是否清晰易懂？
注释：核心代码的注释是否都一目了然？
代码排版：所有的代码是否都遵循编码规范？
设计：代码是否设计良好？是否适合当前系统？有没兼容旧版或预留扩展接口？
功能：代码实现的行为与需求是否相符？
复杂性：代码可以更简单吗？如果由其他开发者接手，能否很快理解吗？
文档：开发者是否同时更新了相关文档？

推行代码审查机制，开发流程上专门有这个环节，代码必须审核通过才可以提交。审核结果或记录公开透明，团队内互相审查其他人的代码，甚至明确考评和代码审查表现相关，这样就能落实代码审查制度。

3 怎么做代码审查

3.1 作为代码提交者

发起时机：软件变更发布前提交代码审查申请。
代码行数：提交代码行数最好在500-1000行以下（非有效代码除外），一个高质高效的代码审查最好控制在一个小时以内。

3.2 作为代码评审者

主要从代码逻辑和质量两方面来评审。

代码逻辑

功能完整：代码实现是否满足需求，有没理解偏差。
逻辑设计：是否符合软件框架，功能细节处理是否考虑边界条件和并发控制。
数据安全：是否存在数据安全隐患，参数篡改或丢失。
性能隐患：是否存在损害性能的隐患，如死循环等。
测试用例：单元测试用例的验证逻辑是否有效，测试用例的代码行覆盖率和分支覆盖率。

代码质量

编码规范：命名、注释、架构分层、软件排版等是否符合编码规范。
可读性：是否逻辑清晰、易理解，避免使用奇淫巧技。
简洁性：是否有重复可简化的复杂逻辑，代码复杂度是否过高。
可维护性：是否分层清晰、模块化合理、高内聚低耦合、遵从基本设计原则。
可扩展性：是否仅满足本次需求，是否有必要的扩展设计。
可测试性：代码是否方便写单元测试及分支覆盖，是否便于自动化测试

3.3 评审注意事项

沟通是至关重要的，团队要始终保持沟通，并在整个过程中保持透明度，代码审查提供清晰的反馈修复建议。同时，要记住反馈应该集中在批评代码本身，而不是代码的作者。尽快完成评审，避免过度追求完美，抓住重点，水至清则无鱼。

4 代码审查避免流于形式

代码审查失去意义，主要是审核与否不影响流程，或者时间紧迫必须保证项目进度，或者审核结果修改建议无法执行。一旦认为审查是可有可无，后续就越发流于形式。

时间与进度的矛盾

项目压力大时间紧，以致草草分析不做设计，直接编码不做重构，前期快了最后总要有谁来背锅。

每次代码审查的建议都是一次技术交流，但是审查后，发现问题太多，或者改动太大，影响项目计划，理论上要求编码前设计评审方案，实际工作可能是发布前审查，为了项目进度只能认可既定事实。

或者代码审查的力度不够，只能提出一些浅表的问题，建议无非是一些格式、注释、命名之类不痛不痒的问题，草草了事，这个现象其实更为普遍。

评审者不了解业务和代码

代码提交人需编写清晰的修改描述，必要的情况下评审者应熟悉需求，否则，脱离功能实现无法发现真正的逻辑问题。

反馈建议未修改

这一点极为重要，需要对修改后的代码再次审查，确保理解一致，问题建议有被接受执行。

代码审查耗费人力

代码审查可能很耗时，特别是处理大型代码库或复杂变更时，评审人员需要花费时间和精力仔细审查代码，这可能会影响整体的开发速度和项目进度。代码审查需要多个团队成员的参与，包括作者和评审人员。这可能对团队资源产生负担，特别是在人员有限的组织中。

5 小节

程序员的智慧结晶都尽在代码之中，而代码审查是打磨它更加的纯洁无瑕、精致完美，这也值得大家一起持续精进，即使实际存在诸多阻碍。关于编码技术路，路漫漫其修远兮，吾将上下而求索。