Code Review的正确姿态

正确的做Code Review可以帮我们解决两个问题：

1. 减少Bug
2. 使修改别人的代码变得容易

那么怎么样才是正确Code Review的姿态呢？

我们先从bug说起

bug的形态可以分为以下几类：

• 逻辑不全 - 如缺少输入检查、缺少逻辑判断、少存一个字段等
• 逻辑错误 - 如字段错位、与或搞错了等
• 业务理解偏差 - 这个容易理解，就不解释了
• 集成错误 - 如组件与组件之间接口不匹配等

要让别人鉴别出这些问题，首要任务就是让别人通过理解业务需求来理解你在做什么，对应的需求有没有相应测试覆盖，有没有被遗忘的角落或理解上的偏差。其次再将需求对应到功能代码上，讨论你实现的合理性，是否有更好的实现，是否有已存在的技术，可以简化现在的设计等。

因此这里我们得到了三个关注点：

• 业务需求的理解
• 相应的测试覆盖
• 可读性高的代码

然后我们说说代码共享

容易被修改的代码通常具有以下几个特征：

• 意图明显 - 让阅读者很容易理解作者为什么要写它
• 容易阅读 - 有良好的层次，业务逻辑清晰
• 反应当前业务 - 可以通过阅读代码了解系统现状，从而很容易找到修改点

所以这里要关注的依然是：可读性高的代码，也就是说同样的功能，能越快读懂的代码越好。关于更可读的代码，请参考《Clean Code》。

Code Review在这里能起到避免误读的问题，所以我们还是应该像上面提到的一样，先理解需求，随后看一下代码和需求是否一致。

另外，我们经常看到一些团队，在做Code Review的时候会有一些低价值的讨论，比如：

• 用if还是switch
• 注释应该怎么写
• 大括号前要不要换行
• 代码在什么情况下会被执行
• 把Tech Lead的话当圣旨

虽然以上讨论能形成一些代码规范，但这些规范只能非常有限的帮助减少bug和代码共享。

因此，我们从要解决的问题中，找到了Code Review的正确姿态，总结如下：

1. 业务需求理解 > 代码执行细节
2. 代码业务逻辑 > 代码风格规范
3. 是否测试覆盖 > 人为逻辑判断
4. 知识传递 > 听从权威

同时，关注别人代码中的亮点，指出来。

那么下一个问题，Code Review的频率应该是怎么样的？

通常，大家都希望反馈的周期越短越好，只有得到足够快速的反馈，我们才能尽早的避免引入问题，保持始终往正确的方向前进。

所以基于期望得到最快速的反馈，最好的实践是结对编程。

但是结对编程对于刚刚开始敏捷转型的团队来说，实践难度太大，团队很难接受这种思想，也很难放弃现有习惯去工作。所以比较折中的方式就是进行每日Code Review，也就是团队每天找一个时间，大约半小时左右，在一起互相Review代码。这个时间可以在下班前，也可以在每日站会后，由团队根据自身情况而定。

总结

总之，通过每天在Code Review中关注业务、自动化测试和代码可读性，每个成员分享和传递知识，从而增进团队成员之间的相互了解，共同实现更高质量的产品，进而帮助团队在走向敏捷的过程中迈出重要的一步。