对于代码审查的认识和理解

  代码审查应该成为任何重要的软件开发工作中一个基本制度。并不单指产品程序――而是所有东西。而且代码审查也不需要花费很多的时间和人力,但它却能发挥巨大的效果。

  从代码审查里能得到什么?

  对于代码审查的认识,在代码提交前,用其他人的眼睛检查一遍,防止bug混入。这是最常见的理解,也是对代码审查的好处的最广泛的认识。

  但是,在我看来,这并是它最不重要的。人们确实可以在代码审查中找到一些bug。可是,这些在代码审查中能发现的绝大部分bug,很显然,都是微不足道的bug,程序的作者花几分钟的时间就能发现它们。真正需要花时间去发现的bug不是在代码审查里能找到的。

  代码审查的最大的好处在于,如果你是程序员,而且知道将会有其他同事来检查你的代码,你编程态度就完全不一样了。你写出的代码将更加整洁,有更好的注释,更好的程序结构。因为你很在意别人对你的程序的看法。没有代码审查,你可能会认为,你写的程序基本不会有人看到,除非有人用到了,它不会给你带来同等的紧迫感。除此之外,还有一个非常重要的好处。代码审查能传播知识,培养分享的氛围。在很多的开发团队里,经常每一个人负责一个核心模块,每个人都只关注他自己的那个模块。除非是同事的模块影响了自己的程序,他们从不相互交流。这种情况的后果是,每个模块只有一个人熟悉里面的代码。如果这个人休假或辞职了,其他人则束手无策。通过代码审查,至少会有两个人熟悉这些程序。审查者虽然并不能像程序的作者一样对程序和业务十分了解,但他会熟悉程序的设计和架构还有业务的架构,这个极其重要的。

 

  刚开始,大家在代码审查时经常会犯一些错误,导致很多麻烦,特别是一些缺乏经验的审查者,他们在代码审查的时候会给了程序开发者的很不好的感觉,最终导致程序员抵触代码审查制度。

  针对所有人的审查
    * 首先必须承认:审查者都是根据自己的编程习惯来评判别人的代码。所以很多编程上的主张都是一种个人观点。所以应该讨论它们的利与弊,提出你倾向的观点,迅速的在团队达成一致。

    * 对与审查者和被审查者,大家觉得有压力,感觉非要说点什么,非得找出点什么问题出来才好,别人都提出了点什么,自己多少也得说点吧。(完全不需要。只说一句“这段程序写的真不错。”就可以了)

    * 尽量使用提问或是建议,而不是命令。(“把这个变量命名成:user_id,你觉得怎样?”)

    * 请求说明。(“我不明白。你能解释一下吗?”)

    * 避免代码的归属之争。(“我的”,“不是我的”,“你的”)

    * 不要讽刺,嘲笑别人的代码,避免使用一些会被认为或可能会被认为是有关人身特征的词语。(“笨蛋”,“愚蠢”,“傻逼”,“二”)要把所有人都看作是有魅力的、聪明的、善意的。

    * 要明确。要记着并不是每个人都能理解你的意图。

    * 要谦虚。(“我不能确定——我们来分析一下。”)

    * 不要用“总是”,“从不”,“永远”,“毫无…”这样的修辞语。

    * 如果对于某个代码,有太多的我不理解或大家都有不同的看法,可以组织一个讨论会,或是技术分享,然后把你们的交流形成共识,总结成文档

    * 代码审查,不能时间太短,这样没有太多的效果,但是时间也不能太长。毕竟大家还有其他的工作要做。

 

  让别人审查你的代码

    * 首先要达成共识,理解审查是对事不对人。审查的是你的代码,而不是你。

    * 对审查者的建议表示肯定和感激。(“对,你说的没错。”,“谢谢提醒。我会把它改正。”)

    * 解释为什么代码写成这样,可以说明这段代码的业务逻辑。

    * 整理所作的改动,不必当场改掉,复杂的程序,也可以在以后的迭代中重构它们。

    * 努力站在审查者的立场上理解,同样也要努力理解作者的立场。。

    * 针对你感觉非常好的地方以及不是很好的地方与开发者交流。

    * 找出既能解决问题又能简化代码的方法,让代码变得简单。

    * 提出你的实现方案,但要表现出作者也在考虑这种方案。(“你觉得这里用一个自定义校验如何?”)

    * 程序风格样式和注释,同样也是代码审查的范围,而不仅仅是程序。

 

发表评论

电子邮件地址不会被公开。