关注，星标嵌入式客栈，精彩及时送达

[导读]在开发过程中，如何保证代码的质量，code review是一个很好的必要措施，本文谈谈我对code review的一些体会。

代码为什么要review？ 我以为代码很少bug，其实是这样的画风：

如果代码前期不提高质量，程序猴后期可能会有这样的酸体验：

所以你要为神马做项目代码审核(code review )？ 另一方面，直接原因是提高代码质量，能够在开发过程中、测试前排除bug； 另一方面，团队合作作战，制定的代码规格如何实施呢？ code review也将是一项逐步形成统一编码方式、提高团队协同发展整体作战水平、对形成协同互动的团队文化具有积极促进作用的好举措。 why？

激励认可，代码提交者提交的一组代码被审核者审核(review )，审核者多由同事担任或更资深的攻城狮子担任，肯定了审核中总有一些地方是可以孤注一掷的识别出存在缺陷的漏洞，在正面的方面必然激励代码作者，被指出疏漏，必然有堵塞疏漏的机会，降低事后调查错误的成本。 对很多同学来说，得到前辈的认可必然会受到激励，得到指点，必然有利于进益

团队建设

code review可识别需要改进的项目或不完整或已完成的任务，并允许团队成员根据已完成的工作进行渐进的迭代开发。

提交人有时使用技术或算法，审评委可以从中获益。 更重要的是，代码审查有助于逐步提高整个团队的代码质量标准。 在审查过程中，有一点是深入分析的，由于思想冲突，所谓不辩不明。 经过良好的长期代码审核机制，整个团队的认知将逐步提高！

积极的交流有助于建立良好的团队文化

风格一致性:code review有助于形成统一的代码样式，这是技术管理的重要维度。 代码样式一致性还有助于减少错误、提高协作开发能力，以及提高代码的可读性和可维护性。 为什么可以提高共同开发能力？ 想象一下，如果多人并行开发一个项目，并且每个项目的代码样式都不一样，组装和集成会有多痛苦。 要是知道有bug，解开bug该多痛苦啊。

可读性识别是所谓的官迷、旁观者清，代码片段的可读性对于作者本人来说很难判断，对于没有完整语境的读者来说更容易感知。 可读性强的代码容易重用，整体上错误较少。

错误识别即使是简短而非正式的代码审查也会严重影响代码质量和错误率。

合规性需求如在特定行业、医疗、工业、汽车领域，代码审核是开发过程中强制性要求的环节，如功能安全认证、医疗器械认证法规体系、汽车电子等进行代码审核，并出具审核报告

Review在做什么？ 具体要Review的内容是什么？ 这个问题似乎没有绝对的正确答案，但所有开发团队都必须对自己的方法达成一致。 达成一致的意思是，团队成员必须创建一起代码规则和Review的检查列表，而不应该有人创建规则。

片面的偏差是不可避免的，即使是前辈cbdzs，也不能保证所有的理解都是完全正确的

需要团队align同意。 不这样做的话，就很难实施。 特别是团队成员水平相当，气氛文化还没有形成好的情况下，谁都会对谁不服。

规则也可以协同渐进完善，但一定是可以实施的，而不是流于形式。

代码评审是需要无差别化，要一视同仁并不意味着即使是队里最资深的人也不需要评论他的代码。 即使在极少数情况下代码没有瑕疵，审查也提供了指导和合作的机会，从而加深团队对代码的理解。

具体实施可以从以下两个方面着手。

团队共同定义代码规范。 当然，如果已经有规格了，就需要对新人进行培训。 代码规范没有绝对的标准答案，只是为了建立成员认可的代码样式和习惯。

小组共同定义了评审项目列表，每个成员可能是作者，也可能是评委。 另一方面，编写代码时拿着尺子测量，审查时也拿着尺子检查。

对于审查项目，例如，可以定义以下规则：

检查是否正确使用了通过引用传递的参数。

检查是否为实现返回值的分支实现了显式返回值。

检查函数是否清晰易懂？

检查类型转换是否正确。

.

什么时候Review？ 代码审核应在自动检查(单元测试、代码样式、连续集成构建)成功完成后进行，但代码应集成到基于代码的主干(或mainli )中

ne或者叫trunk）分支之前进行。

单元测试，相信做过的朋友应该会有体会，有效的单元测试将提前识别出bug

代码风格，主要是指代码的样式，比如缩进，花括号的写法，很多编辑器能帮助自动完成。比如IAR，比如Clang-Format，visual code的ident插件等。

持续集成，比如有很多公司会使用Jenkins搭建一个自动构建平台，借助这个平台可以实施自动集成编译、自动运行单元测试、自动运行代码静态检查等。

为什么要在这些自动检查成功之后才Review？因为这几个过程都有可能发现问题，并触发修改代码，所以Rview一个相对稳定的版本将会减少重复Review的工作量，节约时间。那么为什么要在合并到主干之前审查呢？这显然比较好理解，因为这样可以尽量将高质量稳定的版本或者功能合并进主干，可以保证主干的相对稳定以及质量。

该怎么Review呢?

发起Review的代码提交者，需要提前做好准备工作，从而提高效率，以减少浪费其他参与人员的时间：

明确范围：待审查变更应具有明确范，成体系的范围。例如，这笔更改实现新功能或修复的错误。较短的更改优先于较长的更改。对于一个涵盖多项需求用例的更改，比较好的做法是拆分成多次review，或者组织review时尽量条理清晰，做些分门别类的前期准备，以方便审查，提高效率。

仅提交完整且经过自我审查（比如利用版本管理工具的diff进行）和经过单元测试的代码。为了节省审阅者的时间，比较好的做法是在发送审阅者之前测试提交的更改（比如前面谈到的完成静态代码检查、单元测试、代码风格），并确保它们通过本地和持续集成服务器上的所有内部版本以及所有测试和代码质量检查。

代码样式提前整理好，人工审查需要消耗其他人的时间，代价可谓昂贵，所以应聚焦到程序逻辑上，而非样式，语法或格式的争辩上。更好的办法是采用工具自动完成，比如Clang-Format等自动工具来解决这些问题。

具体Review时，有哪些值得推荐的做法呢？

要针对代码不要针对作者，忌攻击作者，否则影响士气，不建议管理者将代码审查缺陷当作绩效考核指标。

要开放不要保守，没有人写出绝对完美的代码，助人亦是助己，建立良好的代码审查文化，以积极看待发现的缺陷。

要识别缺陷不要修复缺陷

要高效不要拖沓，不宜超过2小时

要合理节奏不要太快或太慢

要聚焦逻辑而非形式，如前面所说，不要浪费时间在语法、格式等主题

要追溯跟踪、落地实操不要形式套路，否则不如不做。对于识别出的问题，应逐一反馈关闭。

建议采用辅助工具进行审查

审查代码前，作者应准备必要的注释或者代码解释，以提高审查效率。

一次查看代码尽量控制在200-400行，太多则不易识别出问题

团队协同制定审查清单，并一致认同

总结一下

良好的代码审查机制，将有助于提升代码质量、减少产品缺陷、降低开发成本，同时也有助于持续提升团队凝聚力、建立更好的团队协作文化、提升整体的作战能力。而形式化的代码审查，则将浪费成本、影响士气。至后台发送CR，领取checklist

本文辛苦原创，如喜欢请点赞/在看/分享支持，不胜感激！

—END—

往期精彩推荐，点击即可阅读

▲Linux内核中I2C总线及设备长啥样？ 

▲学Linux驱动：应先了解总线驱动模型

▲看思维导图：一文带你学Verilog HDL语言