在代码评审中用好这7招,很容易就能建立起你的反对同盟

在软件开发中,代码评审是一个关键的流程。

一个团队,代码评审开展的好,可以大不度的提升团队整体的交付质量,同时团队内的成员也可以很好的提升能力。

另一个方面,如果评审走歪了,代码评审可能就变成了大型踩踏的事故现场,彼此互相攻击,破坏信任等。

下面是如何搞砸一次代码评审,来为你树立敌人的7个招数:

1、代码风格的反馈

在代码评审中,对毫无戒心同事发起攻击,最好招式就是:不断指出其不符合编码规范的问题。

大多数公司内都有编码规范的文档,好好学习和利用吧。然后开始要求没有明确的提及的修改。如果代码规范中没有提到什么,那么这就是一个完美的机会,可以要求进行无意义的修改,这样就会给你要攻击的目标带来很多无意义的工作,譬如:

  • 对单元测试类中的方法进行正确的类型提示了吗?
  • 方法上没有添加void的标识了吗?
  • 变量的命名是否过于冗长呢?
  • 等等。

使用编码规范,来不断的折磨你的同伴吧。

2、要求做无意义的变更

第一步很烦人,但不会让你的敌人心生怨恨。你的继续努力,接下来就是毫无意义的变更要求。

如果有两种方法来做一件事,要求他们必须按照你的方式来修改代码,不接受那些对你不利而对他有利的理由。

你需要长篇大论的写反馈建议,来捍卫你所谓的正确。

如果你不想写太多解释性的东西,那你也可以用这样的说辞,让他们觉得自己不合理:

我不知道你为什么对我的这个要求如此难以接受呢,这样做是正确的,是对你好的,请按照我说的来,谢谢。

让你的同事,每天花大量时间来重写那些工作的很好的代码,是不是很爽呢。

3、长时间的拖延

给出评审反馈的时候不要着急。收到评审请求,在24小时,甚至48小时候,再来做评审的事情吧。当收到催促挑战时,就声称自己忙于其他事情啦。

这样做的目标是让他的PR变味。未能及时关闭的拉去分支会被认为是技术债务,需要付出额外的工作来做维护。这是一项非常烦人乏味的工作。所以尽可能的拖延每个分支的持续时间,来增加你攻击目标同事的版本合并过程中,解决冲突的风险和时间吧。

如果你的攻击目标,没有在每一版本分支拉去前,处理过2-3次的合并冲突,那你的速度就太快了,有很多的进步空间。

4、要求增加bug

要求增加变更,是增加工作量的一种很好的方式。而要求做出变更并带来bug的负面影响,这也是增加工作量的一种方式。

你攻击的对手们,一面需要努力的做出变更,然后再变更后发现了新的bug,一面还要费力的去花时间修复新增的bug,是不是很有成就感呢。

5、评审请求中只有代码规范的变更

你让你的敌人审查的每一次变更中,都至少应该包含有50%以上的非关键功能性的、不必要的代码样式上的调整。

尽可能不在请求说明关键的变更有哪些,让你的敌人们自己去猜吧,让他们盲目的去浪费时间来处理你的评审吧。

6、创建超大范围的评审

当在几十行代码上做评审,是非常容易的。但你想要的不是容易和简单,而是希望你的敌人们在收到你的评审请求是感到恐惧:让你的评审中,至少包含10几个文件,1000行以上的代码吧。

对这类的分支请求,也需要快速的处理,他们是技术债务,你可自己去合并解决代码冲突。所以要不断骚扰和催促每一个人,以快速的完成你分支的合并。

同时,也不接受任何人关于你负责分支版本反应慢的反馈,让他们知道你版本的重要性。

7、忽视他人的反馈

在代码评审期间,一直要强调这点:忽视他人的反馈,因为他们是在报复你。

在代码评审中,避免任何负面反馈造成影响最好的一个办法:忽视一切的反馈。

有人给出来了需要做出更改的反馈吗? 忽视他吧,找关系搞定版本的合并,而不是去费力的修复它。

不喜欢任何人用有效的反馈来增加你的工作量,让他们像鸭子背上的水珠,从你的分支版本上滑下来。

写在最后

让上面这些行动,不断的重复,重复,再重复。

持续几个月,你的敌人们就会后悔对你的轻视的。

如果你想让你的敌人们喜欢上代码,你不应该做的事情:

  • 将你的代码风格自动化,使其能够自动处理;
  • 只有比现有版本更好的方案时,才会安排变更请求;
  • 快速相应拉去请求,并每天安排时间进行代码评审;
  • 当请求变更时,确保所有的变更都进行了测试;
  • 但你使用了新的编码风格后,安排单独的请求;
  • 为代码评审创建小而频繁的拉去请求;
  • 回应所有的反馈,要么同意,要么陈述你不同意的原因。

原文:
http://repohealth.io/blog/code-review-how-to-make-enemies/

张贴在2