17611538698
webmaster@21cto.com

代码审查员要常说四个“不”

资讯 0 1836 2019-01-12 12:03:07

21CTO导读:代码审查是每个高品质软件开发团队的强制性实践,我们希望在本文中没有关于审查的反对声音。
 
有的团队会预先合并代码审查,以保护他们的master/dev分支免受意外错误的影响。也有一些人会大合并后定期审查,以免在合并后发现Bug或不一致。
有些团队则两种方式都做。
 
代码审查与白盒测试技术非常类似,其中测试人员通过完全查看源代码来寻找缺陷。在任何一种情况下,代码审查都会有效提高软件质量,是提高团队积极性的重要工具。
 
但是,要做到这一点并非易事。要做代码审查这件事也难也能很舒服,我见过很多代码测试者和他们犯过的错误。
 
下面是我们总结的一个优秀测试工程师(代码审核员)的四项基本原则,希望对大家有帮助。


Untitled-2.jpg

金统帅都在做代码审查,你害想咋滴? 

不要怕


 
严格的代码审核者应该抛弃一些不必要的担忧,比如一个首要原因就是怕得罪代码的作者。“我最好闭上眼睛,假装今天没有他的bug,明天他会忽视我提的问题”,这就是恐惧产生的态度。这样的情况,虽然和代码作者友好相处了,但起的作用会适得其反,那就是严重降低代码质量和团队士气。
 
我们的建议是:直接,诚实,直截了当。
 
如果你对同事一直有这种感觉和方法,那么可以管理方式出了问题。你害怕被团队拒绝“不是团队一成员”,这是团队中最弱的成员的说辞,而不是项目领导所应该有的标签。甲方付费给团队开发高质量的软件,他们并不关心你想提高软件质量的想法会得罪他人,谁也不会在意。他们希望他的钱能够交付出可售卖或可运营的产品,他们也不会付钱给你在办公室里交朋友。
 
下一个类似的恐惧,听起来是这样式的:“如果我不让这个代码审核过去,会推迟项目的上线”。这样的思虑不言而喻,对整个项目都有很多的不利影响。你接受这些代码睁一只眼闭一只眼假装看到合格的code。团队里再没人会再说你是产品上线的瓶颈,不会因推迟发布而损失金钱。如果你想成为一个优秀的代码审查者和团队合作者,这样做对吗?答案肯定是错误的。
 
我们之前提到过,一个专业的团队非常了解他或她在项目中的个人角色,但不包括为任何人擦屁股。如果因拒绝不良代码而延迟发布,那就是作者的错误。代码审查者的责任就是让此故障可见。
 
这是你帮助团队学习和提高的方法。
 
我认为提高非常明显,要让团队学习与改进,首先先摆脱糟糕的程序员,推出优秀的程序员。诚实无畏的代码审核员可以帮助团队向更好方向发展。
 
第三个恐惧:“我可能错了,他们会笑话我”。更难堪的是,他们可能会发现我缺乏专业知识,会发现我不知道自己在做什么。安静地并假装代码中没错反正更安全,至少我不会用愚蠢的点评来掩饰尴尬。如果你闭嘴,看起来更聪明对吗?错误!
 
这个项目并没有你看起来好就很好,你拿到的薪水并不是因为团队喜欢你,而是因为你每天都会产生可交付的成果。您的职业责任是项目做有利的事情,忽视每个人的意见,包括老板的意见。我想说的是,尊重团队是一个错误的目标,不要试图获得尊重,创建干净的代码并尊重技术。
 
我再重复一下:不要害怕通过对某人的代码做出“错误或愚蠢”的评论而感到难堪。忠诚于项目,而不是周围人的期望。人们可能希望你能聪明,但是项目希望你能说出对代码的真实看法。所以不必担心人们的意见,去做正确的事,说出你的真实想法。

不妥协


 
现在,我们可以无畏的说出你对代码的看法,并拒绝审核通过。你正正审查的分支变得不顺利,你解释了原因,并要求代码作者重构或者重写。
 
下一步会出现什么情况?
 
他/她会尝试和你达成协议。这一切很自然,我的团队中看到几乎每一个分支都在发生这种情况。代码的作者也是专业开发人员,他似乎毫不畏惧,坚持他自己的实施方法是正确的,而你的想法是错误的。
 
在这种情况下,专业代码审查员应该怎么做?
 
在最坏的情况下,是双方妥协,这是破坏质量比烂代码快愉快的东西。妥协是一种冲突解决方案,双方一致同意不是为解决冲突而得到他们各自想要的东西。换句话说,就是“让和平只是为了停止战斗”,坦白说,这是一个有些糟糕的做法。
 
我们不做这种解决方案,有一个关于代码的“斗争”有三个专业的解决方案:
 
1)“你是对的,我接受此建议”
 
这种情况有可能会发生,而且应该经常发生,你应该准备好承认自己的错误。虽然你不喜欢那些代码,但是它的作者向你解释了它的好处,原因,一定不是你想停止与他战斗,而是你真正的理解了他的逻辑并接受它。愿意说“我错了”,这是一个成熟而认真的开发者的第一个表现。
 
2)“现在,我决不接受这段代码!”
 
有些代码值得你这样做,以这种直接的方式没有任何问题。对方可以接受这种情况并全部重写,去学习新的技术。
 
3)“我们来听架构师怎么说的!”
 
在每个项目中,都有一位软件架构师做出终极决定。你只需听取他的意见,得到他的最终决定。在事情发生后,邀请他参加讨论,请他站在冲突的某一边,如果他告诉你错了,全然接受这个决定并在此中吸取教训即可。
 
所以,要么坚持自己的立场并为之而奋斗,要么承认自己是错的,此种方式或另一种方式。但就是不要妥协!
 
别误会我的意思,不管多么糟糕,都不要固执已见。需要我们在现场保持灵活性。您的立场可能会在谈判期间发生变化,但不要接受自己不喜欢的立场。
 
你可以通过完全确信对方是正确的,或者当架构师出现时的判断时退出冲突。
 

不说废话


 
再一次,我们无畏地说出真实的话语。一种方法也可以有不同的方式设计,比如说对方,代码的作者,他回答他不是这么认为。我们再看,决定站在你位置,你仍然认为自己是对的,不会做出妥协。怎么处理?马上打电话给架构师还为时过早,所以你要尽量说服你的对手。
 
在大多数情况下,让人心服口服是的教学——你懂得他从不懂得的事情,这也是他以你不喜欢的方式编码的原因。团队的某个人需要额外的教育,这是你成为同事老师的最好机会。
 
要成为一名有效的老师,你需要出示证明,根据自己的逻辑来确保他能够理解并完全接受它。
 
方法是,准备好足够的页面链接,文章,书籍,报表,示例等材料。不要只是说:“我已经写了15年的Java了”这类话是不够的,这种论证也不会让自己有足够的说服力。
 
如果你没有足够令人信服的证据,那请你再好好想一想,也许是自己错了。
 
另外,请牢记,代码审查员的角色是审核错误的代码的,代码的作者不应该用什么来证明,他写的代码默认很棒。审查员的工作是解释说明为什么以及为何实际情况并非如此。换句话说,你是原告,他是辩护人。
 

没有冒犯之意


 
这是我们说的最后一个也是最难遵循的原则。无论代码多么烂,你的对手有多顽固,你必须保持专业性。在现实生活中,说实话,这种情况确实很难。在我现在的团队,每周都在远程团队中都有新人加入,尽管我们有较严格的选人标准,但是总会有一些人有些愚蠢而且比较难对付。
 
一年前,我遇到一个有意思的事,当时一位新人在现有的Java代码库创建了一个非常小功能,大概20-30行代码就能完成,但是他却输入了几百行,接着他发起pull请求。我是代码审核员,发现那段代码绝对是垃圾,很明显不是他自己写的。我立即看到复制下来去找他。我该怎么处理?我为什么拒绝它,而不是指责它,对于专业的软件开发者这是不可接受的。我接下来还花了大量时间来用客观事实,指出他的代码风格、设计等。我必须严肃指出一些错误的问题,并告诉他要彻底解决掉,他应该立即删除垃圾,代码从头开始写。在完成这个任务后,我再也没有见过这位仁兄。
 
我的观点是,当你与任何专业人士打交道时,也要保持自己的专业性。虽然在某些时刻,情况不总是这样理想,但是无论摆在你面前的代码有多糟糕,我们都要足够的耐心和说服力。你认为呢?

编译:洛逸
作者:Yegor Bugayenko


评论