代码评审中用好7招，成功建立起你的反对同盟

Posted 2022-07-21 常柱的blog

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

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

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

下面是如何搞砸一次代码评审，来为你树立敌人的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/