高效代码审查:来自前质疑者的9个建议

理论我知道。代码审查(Code Review)有助于:

  • 抓bug
  • 保证代码的可读性,可维护性
  • 在团队中散播代码的知识
  • 让新人适应团队的工作方式
  • 让大家接触不同的思路

或者按另一种看法,代码审查就是极大的浪费时间。至少我对代码审查的最初感受就是这样。

当时我是新人,刚毕业,在伦敦一家软件公司开发插件。

随着时间推移,我得提交大量样子都差不多或干脆一样的代码。另一个可怜的家伙(“他是最好的。”我的经理告诉我。好在哪儿啊……)会来Review我的代码。而每次审查之后都会返回不一样的结果。看起来都是全无必要的挑剔又主观的结果。

更糟的是,审查过程的时间,哪怕没有几周,也得有好几天。等代码返回给我的时候,我几乎都记不得那是我写的。这不是那个家伙的错。他肯定也想要个更有经验的开发者,不过他分到了我。他厌倦了处理每个没经验的开发者搞出的那些低级问题,代码审查过程变成了他祛除沮丧情绪的方式。

再加上这些浪费的时间:不同分支的代码同步,上下文切换……我不是代码审查的粉儿,团队其他人也一样。

几年之后,我发现我很同意Jeff Atwood所发表的推特:

“结对代码审查是你能改进代码质量的唯一要事。”

经过这几年的时间我开始赞同代码审查,是因为我发现了代码审查并不是坏事,代码审查执行不好才是坏事。伙计,我们就执行的很不好。

我付出了惨痛代价才意识到这一点。当然不是一夜之间的转变。反思之后,代码审查把我从尴尬的,足以破坏构建的代码修改中拯救出来不少回。而自从我在其他地方工作后,我积累了一些和以前不同的、更好的工作方式的经验。这给了我机会,让我能切身体会到我以前曾错过的代码审查的好处。所以现在我认为自己是一个皈依了的质疑者。

为了你能避免这些痛苦,看看我们的视频,读完这些建议,这样就能带给你更有效的代码审查过程。

一、写给所有人的:

1.只审查正确的东西,让工具干别的

你不需要在代码风格和格式问题上与人争论。有大量的工具可以持续地强调这些内容。确保代码正确、易于理解和可维护性强才是重要的。当然了,编码风格和格式也是这些的一部分,只是你更应该让工具去检查。

2.所有人都该做代码审查

一些人比另一些人更擅长审查。更有经验的人可以发现更多的bug,这很重要。不过更重要的是在总体上维持一个针对代码审查的积极态度,也就是说要避免任何“我们和他们”的对抗态度,或者是让代码审查成为某个人的负担。

3.审查所有的代码

没有代码是因为太短或者太简单而不值得审查。当你审查一切,就没有什么会漏掉。另外这样做会成为流程的一部分,成为一种习惯,而不总是事后诸葛。

4.态度积极

这一点对审查者和提交者都很重要。代码审查不是你要拿全A,发动代码神技的时候,也不是你需要摆出防御姿态的时候。带着对建设性批评的积极态度投入进去,你就可以在此过程中收获信任。

二、写给对审查者的:

5.代码审查应该短期高频

你的审查效率在一个小时后开始下降。所以推迟审查共走,然后在一个极限的周期内赶完对谁也没用。在你的一天中留出时间来定期处理,别打乱自己的工作节奏并养成习惯。你的同事会为此而感谢你。等待会让人沮丧。而且当代码还新鲜的保存在他们脑海里时,他们解决问题也会快一些。

6.It’s OK to say “It’s all good” |“都挺好”挺好

别太挑剔了,你不是一定要每次审查都发现问题。

7.使用一个清单

代码审查清单确保一致性——每个人都了解哪些是重要的,哪些是常见错误。

三、写给代码提交者的

8.保证代码简短

超过200行,审查效率就会显著下降。一旦你超过400行,那基本就没什么意义了。

9.提供上下文

要提供相关的单子,或者规格说明的链接。像Kiln这样的代码审查工具可以提供帮助。应提供简短而有用的提交信息,在代码中留下大量注释。这会帮助审查者,你得到的问题反馈也会少一些。

1 收藏 评论

关于作者:drowzju

@卓尔不浪得 个人主页 · 我的文章 · 10

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部