用户您好!请先登录!

Code Review Principles

Code Review Principles

CodeReview 就像是一个魔咒一样,越是优秀的程序员越易于接受,越是初级的程序员越鄙夷;越是大的公司越奉为经典,越是小的公司越觉得是浪费资源。笔者在不同规模公司的不同阶段和文化氛围中充分感受着来自不同认知的压力,推广CodeReview之行一波三折,深受其苦。

对于好的CodeReview的基本原则与流程,就像“幸福的家庭家家相似”一样,这是借鉴谷歌的做法,聊一聊,叫做如何进行CodeReview以及在各阶段都应该注意哪些。

CodeReview Principles:

Review设计及框架

进行CodeReview的时候,最重要的,就是看变更的总体设计。我们需要有一个代码变更列表,看看每一处变更是否有道理,每一处变更是否起作用。变更是在哪里进行变更的,逻辑层、服务层还是存储层。代码在这里变更合不合适,能否放到更合适的地方。

Reviw功能实现

当我们进行代码审查的时候,需要思考,这些变更是否让功能真正实现了,并且这些变更也是比较友好的,容易维护的。同时,我们应该确保新增的功能是正常运行的,我们需要思考业务有没有边界场景,需要思考有没有并发问题,确保代码没有bug。

当我们的代码变更设计到UI变更的时候,我们可能很难一下子从代码里面看到新页面的样子,这个时候我们需要发起代码变更的人提供一个Demo,或者提供UI出现的路径,以便我们看到。

代码的并发问题是非常难从代码里面看到的,我们很难从代码里面看到是否会出现死锁或者并发冲突,同时,这些并发问题也不是简单的把程序跑起来就能找到,我们需要代码审查人进行更深层次的思考,同时,开发同学也尽量避免使用一些有并发问题的模块。

对于并发问题就留于测试阶段,通过对测试结果的分析与代码实现的预期做比较。

Review非功能实现

非功能实现包括很多部分:复杂度,可维护性,可扩展性,冗余性,是否可重构等。在代码实现中有一条圣经,“精简是美”。

我们需要看到每一次代码变更是否过于复杂,可能是方法过于复杂,也可能是类过于复杂,复杂以为这别人很难阅读懂这段代码,很难进行维护。这意味着别人改动这个代码非常容易出问题。我们经常在代码里面进行过度设计,开发人员经常在代码里面添加一些不必要的方法,代码审查人员需要警惕过度设计,让当次的开发人员用更简单的方法进行实现。

 Review测试用例

测试用例的Review人们往往不把它划归到代码评审中,但别忘记了,测试代码也是代码。国内同仁们对于测试用例的评审往往非常粗糙,仅仅邀请测试相关人员,最多加上产品与架构相关的人一起评审,而这个远远不够。

在一些国外公司,测试用例也是需要进行代码评审的,我们要注意到,每一个测试用例是否有用的,是否正确,能否覆盖到代码的所有场景。测试代码也是经常需要维护的,要把不同的场景搞成不同的方法,不要让测试代码过于复杂,后期更难维护。

Review命名规范

中国研发团队很少对命名规范有非常严格的约定与执行,更多是给大家一本不知从哪里借鉴的命免规范,一句“请大家按照这个命名规范命名”就完事了。在大型软件的开发中,尤其是有长生命周期的代码,代码的一致可读性非常关键。

要求代码评审的程序员需要时刻注意到代码的命名,无论是方法,变量,还是类,如果命名难以理解或者容易混淆,应该进行改正。

Review注释

代码开发人员应该在代码无法清晰解释意图的时候,写下注释。注释会解释为什么这个代码要这么写。代码审查人员应该注意代码的注释是否跟代码所表达的意思一致。同时应该确保所有的TODO注释都被删除。

关于注释,是把双刃剑,不写注释是不对的,因为有可能别人看不懂,甚至过了许久之后,作者本身都会很困惑;写了注释太多也不见得是好事,说明代码实现晦涩难懂,各种类,方法,属性及调用过程不表意,说明了代码有重构的必要。因此,掌握好“度”成了一门学问。

Review风格

不同的公司有不同的基因,时间久了,都有自己的代码风格和传统,我们大家应该按个遵循这种风格。如果你有一些代码不遵循这样的风格,最好在前面注释下原因,如果你要格式化文件,应该把格式化文件跟代码变更分离开来,提两个不同的CodeReview单。

仔细阅读每一行代码

仔细阅读每一行代码,特别是文件读写,大数据,与类初始化,这些开销较大的代码要值得警惕。不要只是粗矿地阅读下函数名,感觉调用链路正确而不去阅读每一行代码。审查的程序员要理解每一行代码做的是什么。

可能你会觉得代码审查非常地浪费时间,同时也是非常地困难。但是,谷歌公司招收的每一个软件开发者,都是非常优秀的,如果你无法做到这一点,说明你的能力可能不符合公司的的要求。这一点不得不佩服谷歌。

也希望中们国内的公司能够养成经的约束和执行能力。

鼓励他人

如果在阅读代码的时候,看到不错的代码,应该赞赏,代码评审不是为了发现别人的错误,也是提升自我的一个地方。

对于CodeReivew,举个不恰当的例子,有点像我们常说的“批评与自我批评相结合”,如何确保代码评审过程有个好的氛围,更加高效、聚集,就需要我们更多的是鼓励与建议,而非人格与能力的指责,这点上,对于初级的程序员,更好做好保护。

总结

做好一个代码评审你需要注意的是:

  • Review设计框架是否合理
  • 代码对其他维护的人都比较友好
  • 对于UI,最好有交互Demo演示
  • 仔细对待并发问题并在后续测试过程中重新审视
  • 没有过度设计,精简是美
  • 单元测试完成再CodeReview
  • 对于单元测试覆盖率争取85%以上
  • 代码命名清晰规范
  • 代码注释非常有用并且容易理解
  • 遵从公司整体的代码风格与文化
行走的code

要发表评论,您必须先登录