代码评审不必有压力


你觉得代码审查有压力吗?汤姆·库比特,极限编程死硬,says so也是。

别误会我。我喜欢极限编程,在过去做结对编程的时候,我有过很大的乐趣和满足感。开发人员不仅交流想法,还学习人际交往技巧。他们看到了什么能让开发伙伴兴奋,什么不能。在成对编程或坐下来一起检查代码的过程中,来自传统的提交等待代码评审的反馈循环或多或少被消除了。但是与代码配对是一个昂贵的提议。尤其是今天,当组织试图把你醒着的每一分钟都用来编码的时候。速度宝贝!

但是我们已经走过了一段路Fagan’s inspections。由于类似的方法非常昂贵,软件行业的大多数人已经开始着手于代码评审提交。在某方面是个了不起的人物Git’s PRs,Crucible或者Review-board。毫无疑问,这可能会带来压力。作为评论家和作家,我都经历过压力。我也在其他评论家和作者身上观察到了它。

那么是什么导致了这种压力呢?我注意到过去几年在不同领域工作的一些模式。它们在这里,我将谈到调整一些东西可能会有所帮助。我会尽量客观。:)

评论者的被动语言

让我们先面对丑陋的事实。这让大多数工程师都很恼火。你真的需要厚脸皮,因为评论者通常给人的印象是不礼貌的。这是野兽的本性。代码审查本质上是被动的、积极的。我在评论中看到过这一点,尤其是在一天结束的时候。被动模式比坐在一起、声音柔和但直接要粗鲁得多。

最好有像我这样的语言指南here。作为一个评论者,你不需要花很多钱来添加微妙的短语,如“最好的如果……”和“更喜欢如果”或者好的缩写“Pls”。即使这些普通的玩笑超出了你的能力范围,也要以包容的方式提出建议,比如“让我们试试吧。”“我们应该……”,因为你在这里不是作为一个“个体”出现的。

代码评审应该是关于代码的

审阅者通常通过敲打张贴在审阅上的屏幕,或者从用户工作流的角度翻译代码,将审阅变成一个piata。在你知道之前,代码审查现在是UX审查!实际上被检查的是翻译到屏幕上的代码。如果评论是关于UX的,那么就少了一些东西。UX,我特别指的是任务工作流程和互动,而不是颜色或间距等。人们对缺少一致的模式感到困惑,他们在代码评审中把它拿出来。截屏应该是关于匹配代码中的样式与高保真模型,或者呈现剧烈的外观和感觉变化。它们不是真正的用户界面工作流模式。这些应该在代码编写之前就已经决定了。

但这确实给了你一个机会去做UX回顾和可用性测试,结果应该会把你带回到图纸上来。在任何情况下,试图在代码评审中获得完美的UX共识都是一个糟糕的策略,这样你就永远不会离开代码评审。代码审查是关于可发货代码的。如果从代码的角度看,UX有明显的差距,那么不要给它一艘船——它!敏捷(如果你不敏捷,请保佑你的心)和短距离冲刺的美妙之处在于,UX总是可以被提升的,即使一个不完美的工作流程作为一个最有价值的人或者一个产品标志背后的特征出现。

审阅者太多

如果你把你的评论发给一个开放的小组,你是在自找麻烦,除非你是故意的。没有故事背景的评论者可能会有一个关于代码发布和“一切”吹毛求疵的日子。这会产生很多噪音。

虽然以上对于琐碎的修复是可以的,但是最好包括一个bug审查者和两个特性或增强的审查者。另一方面,没有被邀请参加评审的评审者,只有在出现明显的问题时才应该介入。否则,这只是一个公开的审查。

阿尔法

即使在看起来没有任何等级制度的团队中,也会有一两个工程师将评审或其分点转化为一个pi $ ing竞赛。因为他们可能不喜欢面对面地谈论它,所以评论成了他们的出口,你很快就会注意到这是无事生非。

嗯,对代码库和其中的尸体最了解的人,或者任期最长的人,通常在这里“胜出”。如果这些评审者不能友好地解决问题,那么最好的办法就是与整个团队进行交谈。指出这是不可接受的,如果审查点有争议,应该离线并放到白板上。客观地对待它,而不仅仅是基于观点。同样,有一个关于代码审查如何适应你的特定文化的参考指南。这将让团队识别出不合理的和严重偏离实践的成员。

开放式问题

这通常发生在提出不合理或开放式问题的评论者身上。这主要是因为在审阅之前,只看行的变化,而没有收集上下文,或者甚至在审阅时阅读作者的变更注释。正如我上面提到的,讨论UX问题可能会使作者困惑。我既有罪又是受害者。以疑问的方式回顾代码是一种我们很少有人掌握的技术。这些陈述通常作为开放式问题输入。这就开始了一个来回的循环。现在你看到结对程序员在嘲笑你!

通常,对评论者(他们不明白直接的意思)来说,最有效的方法是实际上去和他们交流。作为作者,试着理解那个人的观点和他们来自哪里。在团队中制定一个规则来避免开放式问题是可以的。作为一个评审者,使用代码评审作为一个工具来了解一个作者对某个特性了解多少是绝对错误的方法。说话!另一个人是人,不是鱼!

我不是刚刚复习了吗?

当你更新一篇评论时,它(通常总是)会给评论者发一封电子邮件,通知所有的开发者。当评论以快速问答的方式而不是健康的方式被提出和回复时,它会分散评论者的注意力,让他们认为,你是在评论赞扬的基础上行动的,而你只是回复了一些评论正在…你还在修改其他评论。这可能会让评论者觉得讨厌。

了解您的代码审查工具!只回复一组有益健康的更改,并发布一次回复。请务必将变更集注释为“根据约翰和玛丽的上一次审查所做的变更”。这清楚地表明评论已经改变了。是的,这是文书工作,但是习惯工具很重要,因为工具是公司文化的延伸。

架构变化=大型评论

假设一个开发人员开始开发一个超大尺寸的功能。在敏捷开发世界中,详细的架构文档是不被允许的,所以事先会遗漏一个。但是当代码被提交审查时,你会发现太多的功能缺陷,当审查者完成审查时,审查将看起来像一个reddit论坛。

为了避免以这样的评审结束,真的要努力把最有价值产品(最小可行产品)分解成我所说的可评审可行产品。第一个评审可能是关于构建基础设施,然后是后端工作,接着是用户界面。是的,这增加了一点时间,但至少这是一场战斗Parkinson’s Law of Triviality重要的问题不会漏掉。如果已经提交了这样的审查,那么另一个策略是找一个房间,分别与主题专家一起审查审查并捕获问题。这就避免了大量的电子邮件通知和讨论被当场整理出来。

尽情享受吧,伙计!

作者也是如此。我曾与比我聪明得多的人共事过,但我从未与有史以来最伟大的工程师共事过。没有这样的生物存在。基于我们的经验,我们都知道我们所知道的。因此,让自我妨碍在评论中接受建设性的批评是一种自我毁灭的行为。防御性是人之常情,说起来容易做起来难,但我们可以从现在开始就注意这一点!一篇对上面列出的所有问题的小剂量的评论,有时足以使你作为一个作者气馁。但是不要放弃!适应!

因此,除了遵循你自己团队中建立的实践,代码评审是一个向他人学习和分享你的经验的绝佳机会。厚脸皮,客观地接受评论,并确定你从每次评论中学到了什么。当面谈论什么不够清楚。代码审查只不过是一个沟通渠道。