我不断致力于开源项目（Red Hat等）。 他注意到，否定性代码审查本质上是主观的，它花费的时间最多。 这种情况通常发生在提交中，维护者出于某种原因不喜欢您的更改。 最好的情况是，这样的代码审查策略会浪费时间，导致毫无意义的辩论。 在最坏的情况下，它会积极地阻止犯下罪行，造成敌对和精英主义的环境。

代码审查应该是客观，简洁的，并且如果可能的话，应仅包含某些事实。 这不是政治或情感辩论，而是技术性辩论。 他的目标是继续前进，发展该项目和所有参与者。 任何提交都应仅根据是非曲直进行评估，而不应根据主观意见进行评估。

代码审查策略

当考虑您（作为维护者）出于某种原因不喜欢的代码时，请牢记以下几种策略：

1.将异议改成一个问题

• 错误：“此更改将使XXX变得不可能”（这是一个夸张； 真的不可能吗？）
  
• 好：“您更改后我们将如何做XXX？”

2.避免夸张

只需表达您的疑虑并提出问题，以帮助您实现理想的结果。

• 不好：“这种改变会破坏生产力。”
  
• 好：“看来X可能比现有的Y慢； “您是否进行过测量/收集了数据以证明事实并非如此？”
  
• 更好（如果有时间的话）：“目前，我正在收集数据。 我将尝试验证X的速度是否不比Y慢。”
  
• 同样好：“此更改将单个O（n）周期更改为双嵌套O（n²）周期； 它会影响性能吗？”

3.留下恶意评论

最好保留一些想法。 如果您不能礼貌地说，最好保持沉默。

• 不好：“我认为这是一个糟糕的改变，它将摧毁一切。”
  
• Bad：“您确定软件开发是您正确的职业选择吗？”

4.积极行动

也许您对如何解决问题有不同的想法？ 如果您采取积极行动，最终将找到比任何原始选择都更好的解决方案。

• 不好：“这种变化很糟糕，我的版本更好。”
  
• Good：“我对这个地方也有一个改变：也许我们可以比较和/或组合想法。”
  
• “我的工作也有类似的变化，但是我决定做X，因为ZZZ。 你为什么选择Y？”

5.请记住，每个人都有不同的经历。

在所有其他方面，一个绝对胜任的工程师可能几年都不知道您认为是常识的某些事实。 说出明显的话并没有错，除非您光顾或恶意进行。

• 坏：“你看不出来这显然是错误的吗？”
  
• 好：“这不是正确的，因为当X为Y时，它将引发空指针异常。”

6.不要轻描淡写不那么复杂的事物

请记住，对您而言显而易见的事情可能并非对所有人都显而易见。 通过建议其他方法并指出有用的示例，您可以帮助所有人同步。

• 坏：“为什么不仅仅粉碎自己的判断力？”
  
• 好：“如果您迷失了诊断，那么这部分会变得更容易（示例请参见XXX）。”

7.尊重

有时一次提交根本不符合最低质量标准。 这样说是很正常的，但是表示尊重并不需要额外的努力。

• 错误：“这是由愚蠢的人编写的愚蠢代码。”
  
• 好：“谢谢您的投入。 但是，它不能按现状被采用。 有很多问题（如上所述）。”
  
• 也很好：“如上所述，此提交存在多个问题。 也许退后一步谈论使用场景？ 这将有助于找到方法。”

8.管理您的期望（和您的时间）

如果提交过大而无法快速考虑，那么立即说是正常的。 然后寻找解决方案。

• 不好：“我不接受，它太大了。”
  
• 同样不好：忽略提交，直到提交消失。
  
• 好：“您可以将其拆分为较小的提交吗？ 我没有太多时间来进行代码审查，但是对于一次审查来说，提交却过于庞大/复杂。”

9.说“请”（表示礼貌）

只需说“请”，就表明您尊重发件人的时间，尤其是当您想要更改格式或样式时，这似乎是一个微小的更改。 范例：

• “您能否在另一个池请求中记录差距的变化？”
  
• “您可以对齐这些变量定义以使其更易于阅读吗？”

10.开始对话

如果毕竟您仍然不喜欢某些东西，但是不确定为什么，您可能只需要忍受。 或说：“我不喜欢它，但我不确定为什么，我们可以谈谈吗？” 这是一个合理的问题，尽管可能会花费一些时间，但通常还是值得的，因为现在您有两个人，并且两个人都在学习（解释和倾听），而不是两个彼此相对的人。

即使是合格且经验丰富的工程师也应该能够说：“我不明白为什么我不喜欢它。” 这并不是要攻击审稿人的职位，而是诚实地寻求知识。

总结

避免过分夸张或夸张的表述，避免纠纷，精英主义者或贬低诸如“明显”和“为什么不只是……”之类的表述和结构。 使用清晰，真实的陈述和支持的语言，提出问题并继续前进。 请记住，同事和贡献者也是人。 他们的时间应该得到与您相同的尊重。