Tuesday, February 2, 2016

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

No comments:

Post a Comment