• 打造历史文化名城 “安宁记忆”项目启幕 2019-12-28
  • 重庆地税个税完税证明验证系统 2019-12-28
  • 毛泽建:勇敢的女游击队长(为了民族复兴·英雄烈士谱) 2019-12-24
  • 互联网打通精准扶贫“最后一公里” 2019-12-24
  • 一场千里联姻将“中国造血干细胞之父”的技术带到桐庐 2019-12-15
  • [大笑]建议小撸去学点生物进化史…… 2019-12-15
  • 盘点E3展前发布会:六大游戏巨头的意外与遗憾 2019-12-12
  • 全国高考开展网上评卷 多重保障确保打分公平 2019-12-12
  • 比过来,比过去,只是一场浪费游戏,把年轻人生活逼得压力特大 2019-12-10
  • 同一个世界,同一个银行,这样的银行能参与国际竞争吗?女子去银行取钱:柜员递出一张纸 写着公安局地址 2019-12-10
  • 一次金特会能让朝鲜半岛休兵? 2019-11-24
  • 水费欠账竟“穿越”16年?用户质疑:为何没见催缴过? 2019-11-22
  • 武警重庆总队举行干部退役仪式 2019-11-22
  • 您访问的页面找不回来了 2019-11-19
  • 由进口至出口再至走向世界,这一路着实不易,其中少不了无数位科研人员的奉献与牺牲。 2019-11-19
  • 如何做一个令人尊敬的代码评审人员

    2019-07-15 17:02 稿源:InfoQ公众号  0条评论

    锦州麻将官方下载 www.dpgid.tw 病毒、代码 (4)

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

    作为开源项目的积极贡献者,我发现处理代码评审问题是一件很浪费时间的事情,特别是当代码评审带有负面、主观或争论性的东西时。当项目维护者不喜欢贡献者提交的代码,经?;岢鱿终庵智榭?。在最好的情况下,这种代码评审策略会导致无意义的争论。在最坏的情况下,它会阻碍项目贡献,形成一个充满敌意和精英主义的文化。

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

    代码评审策略

    以下是一些代码评审策略,作为项目维护者,如果你看到不喜欢的代码,可以尝试应用这些评审策略。

     1. 把拒绝变成问问题

    糟糕的评审:“如果你这样改,就不可能……”。(这显然有点夸张,真的不可能吗?)好的评审:“如果你这样改,那该怎么……?”

     2. 避免夸大其词

    简单一点,把你的顾虑和问题说出来,这样有助于你获得期望的结果。

    糟糕的评审:“这个变更对性能影响很大?!焙玫钠郎螅骸罢庋牡幕靶阅芑岜戎暗鸵恍?,你有做过测试吗?”更好的评审:“我会准备一些数据来验证一下这样改之后速度不会比之前慢?!被蛘哒庋骸罢飧霰涓阎暗?O(n) 变成了 O(n2),不会影响性能吗?”

     3. 把带有讽刺意味的评语留给你自己

    有些想法最好把它烂在肚子里,如果你不想让人觉得你粗鲁,最好不要把这些想法说出来。

    “我觉得这个变更太糟糕了,它会毁了所有东西的?!薄澳阏娴木醯萌砑こ陶飧鲂幸凳屎夏愦粝氯ヂ?”

     4. 积极参与

    对于同一个问题,或许你会有不同的想法。如果你能够积极参与,可能会得到比之前更好的解决方案。

    糟糕的评审:“这个想法太糟糕了,我有更好的解决方案?!焙玫钠郎螅骸岸杂谡飧鑫侍馕乙灿幸恍├嗨频南敕?,或许我们可以比较或者组合一下我们的想法?!被蛘撸骸拔乙灿幸恍├嗨频南敕?,我这样做是因为……而你那么做是因为什么?”

     5. 不是每个人的经历都跟你一样

    有些东西对你来说是常识,但有些人可能并不知道,即使他们的能力并不差。你可以说这些东西是常识,但不要显露出嘲笑或高人一等的姿态。

    糟糕的评审:“你不知道这个明显是错的吗?”好的评审:“这样是不对的,因为当……的时候它会抛出空指针异常?!?/p>

     6. 不要把复杂的东西简单化

    有些事情对你来说是显而易见的,但对其他人并不一定也是这样。为别人提供可选方案或有用的例子可以让他们也变得跟你一样好。

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

     7. 尊重别人

    有时候,提交的代码可能质量很差,但表示一下对别人的尊重其实很容易。

    糟糕的评审:“这些愚蠢的代码人跟写代码的人一样愚蠢?!焙玫钠郎螅骸案行荒闾峤坏拇?,但我们不能接受它们,因为有一些问题(已经列出来了)?!被蛘撸骸按胗幸恍┪侍?,已经列出来了?;蛐砦颐强梢曰赝艘徊?,一起讨论一下用例?这样可以帮我们往前进一步?!?/p>

     8. 管理你的期望和时间

    如果一次提交的代码太多,你没有时间评审,可以让提交者知道。

    糟糕的评审:“代码太多了,我不会合并它们的?!蓖愀獾氖侵苯雍雎运?。好的评审:“可以把这些分成几次提交吗?我没有这么多时间,而且一次也评审不了这么多代码?!?/p>

     9. 使用礼貌用语

    使用礼貌用语(比如“请”)表示对代码提交者的尊重,特别是当你要他们在细节上做出一些调整(比如格式化)时。

    “请你把与空格相关的变更放在单独的 PR 里,可以吗?”“请你把变量对齐,这样更容易阅读,可以吗?”

     10. 开启对话

    你可能照着上面所说的去做了,但对提交的代码仍然不满意。这个时候你可以这么说:“我不喜欢这段代码,但我也不知道为什么,我们可以聊聊吗?”尽管需要多花一点时间,但这样是值得的,因为这样你和对方都能学到东西(一个讲一个听),而不是变成对立方。

    即使是很有经验的程序员也可以这么说:“我也不知道为什么不喜欢这段代码”。这不是在创造攻击代码评审人员的机会,而是打开一条共同求知的道路。

    总   结

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

    原文链接:

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


    声明:本文转载自第三方媒体,如需转载,请联系版权方授权转载。协助申请

    相关文章

    相关热点

    查看更多
    ?
    关闭
  • 打造历史文化名城 “安宁记忆”项目启幕 2019-12-28
  • 重庆地税个税完税证明验证系统 2019-12-28
  • 毛泽建:勇敢的女游击队长(为了民族复兴·英雄烈士谱) 2019-12-24
  • 互联网打通精准扶贫“最后一公里” 2019-12-24
  • 一场千里联姻将“中国造血干细胞之父”的技术带到桐庐 2019-12-15
  • [大笑]建议小撸去学点生物进化史…… 2019-12-15
  • 盘点E3展前发布会:六大游戏巨头的意外与遗憾 2019-12-12
  • 全国高考开展网上评卷 多重保障确保打分公平 2019-12-12
  • 比过来,比过去,只是一场浪费游戏,把年轻人生活逼得压力特大 2019-12-10
  • 同一个世界,同一个银行,这样的银行能参与国际竞争吗?女子去银行取钱:柜员递出一张纸 写着公安局地址 2019-12-10
  • 一次金特会能让朝鲜半岛休兵? 2019-11-24
  • 水费欠账竟“穿越”16年?用户质疑:为何没见催缴过? 2019-11-22
  • 武警重庆总队举行干部退役仪式 2019-11-22
  • 您访问的页面找不回来了 2019-11-19
  • 由进口至出口再至走向世界,这一路着实不易,其中少不了无数位科研人员的奉献与牺牲。 2019-11-19