Code Review的四个实践误区：从嵌入式软件到团队协作的反思

写代码的同学应该都知道Code Review，也就是代码审查、检查或评审。

在软件工程中，Code Review是一项非常重要的评审工作。但在日常的嵌入式软件开发工作中进行Code Review时，我发现团队成员有时可能会固守一些“实践经验”。然而，这些经验对于整个软件项目而言，却可能是错误的。

今天就来分享一下我认为的几大误区，也欢迎大家一起来讨论。

误区一：什么时候都一定要做Code Review

Code Review真的在任何时候都必不可少吗？我的答案是否定的。

我认为这需要看时间和看项目。

在公司创业初期，可能就一两个人吭哧吭哧地把整个产品从0到1搭建出来。这时候，Code Review既没有条件（没有其他开发者可以参与评审），也没有必要。让产品快速实现并活下来，才是那个阶段的首要任务。

当线上出了严重Bug，分分钟可能造成巨大损失时，显然救急是第一位的。如果非要等一个完整的Code Review流程，可能“黄花菜都凉了”。当然，这里也要分情况：如果是一个非常显而易见的bug，比如你很确定只是一个条件写反了，那直接修复上线可能是更高效的选择。但如果这个修改涉及复杂的逻辑或不那么轻巧，那么多一双眼睛（进行一次快速的同行评审）往往能大大降低再次引入问题的概率。

误区二：Code Review主要是用来让别人检查Bug的

将Code Review视为让别人替自己“捉虫”的手段，可能代表了不少程序员的想法。

在Code Review中查找潜在的错误，确实是一个重要目的，但它绝不应该成为唯一的目的。

除了检查Bug，Code Review还能带来更多价值：

1. 维持代码质量与统一代码风格的手段。 团队成员的技术背景和能力各不相同，完全放任自由发挥，可能会产生质量参差、风格迥异的代码。通过Code Review，可以促使大家将代码质量维持在一个团队可接受的水平线上，并尽力让项目代码风格保持统一。

2. 一个互相学习的过程。 对于经验尚浅的同事，我们可以指出其代码在风格、设计等方面的不足，进行直接的指导。反过来，在评审他人代码时，我们也能学习到作者的编程思路、API调用方式或巧妙的设计模式应用。这个过程不仅是新手向老手学习的机会，老手同样可能从新手那里获得新的启发。

3. 一个了解同事工作内容的机会。 开发者通常专注于自己的任务，而通过Code Review，可以最直观地了解同事正在做什么、如何做。例如，你发现同事可能要修改你负责的同一个文件，提前了解他的修改思路，可以有效避免后续代码合并时的冲突。

误区三：初级工程师的代码需要检查Bug，高级工程师的代码不需要

很多时候，对于初级工程师提交的代码，大家会踊跃地参与Review，甚至以找出其中的Bug为荣。但对于高级工程师写的代码，情况可能就不同了：要么他们根本不发起Review，要么即使把你加入评审列表，你也可能碍于对方的“江湖地位”而不敢提意见。或者，团队可能对资深同事给予过度信任，对他们的评审请求只是草草一看，就给出“LGTM”（Looks Good To Me）。

然而，这种做法是有问题的。初级工程师可能写出小bug，而高级工程师则可能写出“要命”的bug。

初级工程师通常处理相对基础和明确的任务，而高级工程师往往负责更核心、更复杂的模块。如果你回顾公司里那些重大的线上事故，引发者往往是高级工程师的概率远大于初级工程师。这有点像“出车祸的多是老司机”、“淹死的多是会游泳的”的道理。高级工程师可能更专注于高屋建瓴的架构设计，反而容易忽视代码中的细节陷阱。同时，他们对自身技术能力的高度自信，有时会让他们忽略一些基础的软件测试环节。

因此，无论代码出自谁手，Code Review都是必要的，只是评审的侧重点可能不同。在检查Bug这件事上，我们或许应该秉持这样的原则：战略上信任同事，战术上保持怀疑。

误区四：Code Review提的问题越多越好

我在工作中遇到过一些“Code Review喷子”。同事提交了一段不到100行的代码，却被洋洋洒洒地提出了十几二十处“问题”。原作者在某些问题上回复了自己的看法，双方就一些“萝卜白菜各有所爱”的细节问题盖了十几层楼。结果两三天过去了，论战仍在继续。

我也曾经历过这种“猛烈”的评审轰炸。为了让所有评审者都满意，我前后修改了数十次，每次改动都会引来不同同事提出的各种意见。最后，因为一个设计上的分歧，我对代码进行了大规模重构，才终于被接纳。

然而，代码合并后却出现了一个低级Bug。回头一查，正是最后一次大重构引入的。为什么会出现这样的结果？一个Code Review的持续时间越长，原作者耐心逐渐耗尽，评审者也可能越来越只关注他们“希望”你做出的改变，反而容易忽略更本质的问题，捡了芝麻丢了西瓜。

如果一个Code Review中的提交次数太多，对评审过程是不利的。每位评审者的记忆有限，可能只记得前几次的修改。当评审最新的提交时，如果失去了之前的完整上下文，就容易出现我上面遇到的问题。

我们进行Code Review的目的，并不是追求所谓“完美的代码”。世界上不存在完美的代码，任何一段足够长的代码，理论上都有可以改进的空间。每个人心中对“完美”的定义也不尽相同。在不违反团队约定的代码质量与风格标准的基础上，应该尊重“谁写代码谁做主”的原则，避免陷入无休止的细节争论。

声明：本文转自网络，版权归原作者所有。如涉及作品版权问题，请与我联系，我将根据实际情况进行处理或删除。更多技术干货与实践心得，欢迎访问云栈社区与广大开发者交流探讨。