编者按：本文来源创业邦专栏InfoQ，作者David Lloyd。
作为开源项目的积极贡献者，我发现处理代码评审问题是一件很浪费时间的事情，特别是当代码评审带有负面、主观或争论性的东西时。当项目维护者不喜欢贡献者提交的代码，经常会出现这种情况。在最好的情况下，这种代码评审策略会导致无意义的争论。在最坏的情况下，它会阻碍项目贡献，形成一个充满敌意和精英主义的文化。
代码评审应该是客观和简洁的，并尽可能面向确定性。代码评审不是关于政治或情感上的争论，而是一个技术问题。代码评审的目标应该是不断进取，提升项目及其参与者的水平。提交的代码应该根据代码的优点而不是对提交者的意见来评判。
代码评审策略以下是一些代码评审策略，作为项目维护者，如果你看到不喜欢的代码，可以尝试应用这些评审策略。
1. 把拒绝变成问问题糟糕的评审：“如果你这样改，就不可能……”。（这显然有点夸张，真的不可能吗？）好的评审：“如果你这样改，那该怎么……？”
2. 避免夸大其词简单一点，把你的顾虑和问题说出来，这样有助于你获得期望的结果。
糟糕的评审：“这个变更对性能影响很大。”好的评审：“这样改的话性能会比之前低一些，你有做过测试吗？”更好的评审：“我会准备一些数据来验证一下这样改之后速度不会比之前慢。”或者这样：“这个变更把之前的 O(n) 变成了 O(n2)，不会影响性能吗？”
3. 把带有讽刺意味的评语留给你自己有些想法最好把它烂在肚子里，如果你不想让人觉得你粗鲁，最好不要把这些想法说出来。
“我觉得这个变更太糟糕了，它会毁了所有东西的。”“你真的觉得软件工程这个行业适合你呆下去吗？”
4. 积极参与对于同一个问题，或许你会有不同的想法。如果你能够积极参与，可能会得到比之前更好的解决方案。
糟糕的评审：“这个想法太糟糕了，我有更好的解决方案。”好的评审：“对于这个问题我也有一些类似的想法，或许我们可以比较或者组合一下我们的想法。”或者：“我也有一些类似的想法，我这样做是因为……而你那么做是因为什么？”
5. 不是每个人的经历都跟你一样有些东西对你来说是常识，但有些人可能并不知道，即使他们的能力并不差。你可以说这些东西是常识，但不要显露出嘲笑或高人一等的姿态。
糟糕的评审：“你不知道这个明显是错的吗？”好的评审：“这样是不对的，因为当……的时候它会抛出空指针异常。”
6. 不要把复杂的东西简单化有些事情对你来说是显而易见的，但对其他人并不一定也是这样。为别人提供可选方案或有用的例子可以让他们也变得跟你一样好。
糟糕的评审：“为什么不直接这样？”好的评审：“这样做会更简单，比如……”
7. 尊重别人有时候，提交的代码可能质量很差，但表示一下对别人的尊重其实很容易。
糟糕的评审：“这些愚蠢的代码人跟写代码的人一样愚蠢。”好的评审：“感谢你提交的代码，但我们不能接受它们，因为有一些问题（已经列出来了）。”或者：“代码有一些问题，已经列出来了。或许我们可以回退一步，一起讨论一下用例？这样可以帮我们往前进一步。”
8. 管理你的期望和时间如果一次提交的代码太多，你没有时间评审，可以让提交者知道。
糟糕的评审：“代码太多了，我不会合并它们的。”同样糟糕的是直接忽略它们。好的评审：“可以把这些分成几次提交吗？我没有这么多时间，而且一次也评审不了这么多代码。”
9. 使用礼貌用语使用礼貌用语（比如“请”）表示对代码提交者的尊重，特别是当你要他们在细节上做出一些调整（比如格式化）时。
“请你把与空格相关的变更放在单独的 PR 里，可以吗？”“请你把变量对齐，这样更容易阅读，可以吗？”
10. 开启对话你可能照着上面所说的去做了，但对提交的代码仍然不满意。这个时候你可以这么说：“我不喜欢这段代码，但我也不知道为什么，我们可以聊聊吗？”尽管需要多花一点时间，但这样是值得的，因为这样你和对方都能学到东西（一个讲一个听），而不是变成对立方。
即使是很有经验的程序员也可以这么说：“我也不知道为什么不喜欢这段代码”。这不是在创造攻击代码评审人员的机会，而是打开一条共同求知的道路。
总 结避免使用双关语或夸大其词，避免争论，避免精英主义或贬低他人，避免诸如“显而易见”和“你为什么不……”这样的评语。使用清晰、真实的陈述和支持性的语言，提出问题，推动事情向前发展。记住，同事和代码贡献者都是人，他们的付出和你的付出一样值得尊重。
本文为专栏作者授权创业邦发表，版权归原作者所有。文章系作者个人观点，不代表创业邦立场，转载请联系原作者。如有任何疑问，请联系editor@cyzone.cn。
