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

最后更新：2022-07-22 08:48:14 手机定位技术交流文章

在软件开发中,代码检讨是一个关键的过程。

一个进行良好的代码审查的团队可以大大提高团队的整体交付质量,而团队内部的成员也可以提高他们的能力。

另一方面,如果代码检讨失败,代码检讨可能会变成大规模的逐步事故现场,互相攻击,破坏信任等。

下面是如何破裂代码审查设置敌人的7个技巧:

1、代码风格的反馈
在代码审查中,攻击一个不屈不挠的同事的最佳方法是不断指出它不符合代码标准。

大多数公司都编码了标准文件,好好学习和利用吧。然后开始请求更改,没有明确的引用。如果代码规范中没有提到什么,所以这是一个完美的机会,你可以要求无意义的修改,这会给你很多无意义的任务与你想要攻击的目标做。譬如：

单元测试类中的方法是正确的类型吗?
你没有在方法上添加空标识符吗?
变量的名称太长了吗?
等等。
使用代码标准来继续折磨你的同伴。

呼吁无意义的改变
第一步令人讨厌,但不会让你的敌人生气。如果你继续尝试,下一个步骤就是毫无意义的更改请求。

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

你需要用反馈来写长长的论点来捍卫你所说的是对的。

如果你不想写太多的解释文,你可以用这个句子使他们觉得不合理的:

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

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

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

这样做的目的是使他的 PR 味道更好。如未能及时关闭提取支店, 将视为技术债务,维护需要额外的工作。这是一个非常令人讨厌和无聊的工作.因此尽可能延迟每个分支的期限,为了增加攻击目标同事的版本集成过程,处理风险和冲突的时间.

如果你的攻击目标没有在每个版本分裂之前处理 2-3 个合并冲突,那么你的速度太快,还有足够的改善空间。

4、要求增加bug
需要更多的更改是增加工作量的好方法,也是通过需要更改和产生错误的负面影响来增加工作量的方法。

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

仅在检讨请求中更改代码规范
你让你的敌人审查的每一次变更中，都至少应该包含有50%以上的非关键功能性的、不必要的代码样式上的调整。

尽可能,不要让敌人告诉你关键的变化是什么,让他们自己猜测,让他们盲目地浪费时间在你的评论上。

6. 创建一个大范围的审查
对数以十计的代码行进行评估是非常容易的,但是你不想让它简单而简单,你希望你的敌人在收到你的评审请求时会感到害怕:确保你的评审至少包含10个文件和超过100个代码行。

这样的分支请求也需要快速处理,它们是技术债务,你可以将其合并以自己解决代码冲突。因此,继续骚扰和迫使每个人迅速完成分支合并。

同时,不要接受任何人对分支版本响应的缓慢反馈,让他们知道你的版本的重要性。

7、忽视他人的反馈
在代码检讨期间,一定要强调这一点:不要忽视别人的反馈,因为他们正在报复。

在代码检讨中,避免产生影响的任何负面反馈的最佳方法是忽略所有反馈。

有人提出需要修改的反馈吗? 忽略他,找到一个关系,使版本合并,而不是努力解决它。

不要喜欢那些利用有效的反馈来增加你的工作量,让它们像背上一只鸭子的珍珠一样从你的分支版本滑下来。

写在最后
让上面的动作重复一遍又一遍。

几个月来, 你的敌人会后悔他们对你的疏忽.

如果你想让你的敌人喜欢你的代码,你不应该这样做:

自动化代码样式,使它能够自动处理;
只有当程序比现有版本更好时才能安排更改请求;
快速拖动请求并按时安排每天检讨代码的时间;
在请求更改时确保所有更改都经过测试;
但您使用新的编码风格后, 安排一个单独的要求;
为代码检讨创建小而频繁的拖动请求;
回答所有反馈,要么同意,要么说明你为什么不同意。