如何做一个令人尊敬的代码评审人员

  • 时间:
  • 浏览:0
  • 来源:大发快三_快三苹果app下载_大发快三苹果app下载

声明:本文来自于微信公众号 infoq(ID:infoqchina),作者:David Lloyd,授权站长之家转载发布。

作为开源项目的积极贡献者,我发现防止代码评审什么的什么的问题是一件很浪费时间的事情,不为什是当代码评审暗含负面、主观或争论性的东西时。当项目维护者不喜欢贡献者提交的代码,突然会再次总出 这人 具体情况。在最好的具体情况下,这人 代码评审策略会愿因无意义的争论。在最坏的具体情况下,它会阻碍项目贡献,形成一两个充满敌意和精英主义的文化。

代码评审应该是客观和简洁的,并尽不可能 面向选泽性。代码评审后会关于政治或夫妻情感上的争论,后来 我一两个技术什么的什么的问题。代码评审的目标应该是不断进取,提升项目及其参与者的水平。提交的代码应该根据代码的优点而后会对提交者的意见来评判。

代码评审策略

以下是后来 代码评审策略,作为项目维护者,不可能 你都看不喜欢的代码,还这麼尝试应用什么评审策略。

 1. 把拒绝变成问什么的什么的问题

糟糕的评审:“不可能 你从前改,就不不可能 ……”。(这显然不为什夸张,真的不不可能 吗?)好的评审:“不可能 你从前改,那该为什……?”

 2. 防止夸大其词

简单后来 ,把你的顾虑和什么的什么的问题说出来,从前有有利于你获得期望的结果。

糟糕的评审:“这人 变更对性能影响很大。”好的评审:“从前改语录性能会比后来 低后来 ,你有做过测试吗?”更好的评审:“我会准备后来 数据来验证一下从前改后来 下行带宽 不不比后来 慢。”不可能 从前:“这人 变更把后来 的 O(n) 变成了 O(n2),不不影响性能吗?”

 3. 把暗含讽刺愿因的评语留让我另一方

后来 想法最好把它烂在肚子里,不可能 你想要 让我随便说说你粗鲁,最好不不把什么想法说出来。

“我随便说说这人 变更太糟糕了,它会毁了所有东西的。”“你真的随便说说软件工程这人 行业适合你呆下去吗?”

 4. 积极参与

对于同一两个什么的什么的问题,或许让我有不同的想法。不可能 你才能积极参与,不可能 会得到比后来 更好的防止方案。

糟糕的评审:“这人 想法太糟糕了,我有更好的防止方案。”好的评审:“对于这人 什么的什么的问题我后会后来 累似 的想法,或许亲戚亲戚朋友还这麼比较不可能 组合一下亲戚亲戚朋友的想法。”不可能 :“我后会后来 累似 的想法,我从前做是不可能 ……而你这麼做是不可能 什么?”

 5. 后会每另一方的经历都跟你一样

后来 东西对你来说是常识,但后来 人不可能 并谁能谁能告诉我,即使亲戚亲戚朋友的能力不不差。让我说什么东西是常识,但不不显露出嘲笑或高人一等的姿态。

糟糕的评审:“你谁能谁能告诉我这人 明显是错的吗?”好的评审:“从前是不对的,不可能 当……的后来 它会抛出空指针异常。”

 6. 不不把简化的东西简单化

后来 事情对你来说是显而易见的,但对另一方不不一定也是从前。为别人提供可选方案或有用的例子还这麼帮亲戚亲戚朋友也变得跟你一样好。

糟糕的评审:“为什不直接从前?”好的评审:“从前做会更简单,比如……”

 7. 尊重别人

有后来 ,提交的代码不可能 质量很差,但表示一下对别人的尊重随便说说很容易。

糟糕的评审:“什么愚蠢的代码人跟写代码的人一样愚蠢。”好的评审:“感谢你提交的代码,但亲戚亲戚朋友这麼接受它们,不可能 有后来 什么的什么的问题(不可能 列出来了)。”不可能 :“代码有后来 什么的什么的问题,不可能 列出来了。或许亲戚亲戚朋友还这麼回退一步,一同讨论一下用例?那帮我帮亲戚亲戚朋友往前进一步。”

 8. 管理你的期望和时间

不可能 一次提交的代码太满,你这麼时间评审,还这麼让提交者知道。

糟糕的评审:“代码太满了,我不不合并它们的。”同样糟糕的是直接忽略它们。好的评审:“还这麼把什么分成哪2个提交吗?我这麼这麼多时间,后来 一次也评审不了这麼多代码。”

 9. 使用礼貌用语

使用礼貌用语(比如“请”)表示对代码提交者的尊重,不为什是当帮我亲戚亲戚朋友在细节上做出后来 调整(比如格式化)时。

“请你把与空格相关的变更装入 单独的 PR 里,还这麼吗?”“请你把变量对齐,从前更容易阅读,还这麼吗?”

 10. 开启对话

你不可能 照着上面所说的去做了,但对提交的代码仍然不满意。这人 后来 让我这麼说:“我不喜欢这段代码,但谁能谁能告诉我为什,亲戚亲戚朋友还这麼聊聊吗?”尽管这麼多花后来 时间,但从前是值得的,不可能 从前你和对方都能学到东西(一两个讲一两个听),而后会变成对立方。

即使是很有经验的守护进程员也还这麼这麼说:“谁能谁能告诉我为什不喜欢这段代码”。这后会在创造攻击代码评审人员的不可能 ,后来 我打开四根一同求知的道路。

总   结

防止使用双关语或夸大其词,防止争论,防止精英主义或贬低他人,防止诸如“显而易见”和“你为什不……”从前的评语。使用清晰、真实的陈述和支持性的语言,提出什么的什么的问题,推动事情向前发展。记住,同事和代码贡献者后会人,亲戚亲戚朋友的付出和你的付出一样值得尊重。

原文链接:

https://developers.redhat.com/blog/2019/07/08/10-tips-for-reviewing-code-you-dont-like/