如何成为更高效、更具同理心的代码审查员?

170 阅读4分钟

全文共1348字,预计学习时长3分钟

图片来源:©Asana
https://blog.asana.com/2016/12/7-ways-to-uplevel-your-code-review-skills/

对开发人员来说,审查代码是家常便饭。这可能是一个虚心学习的经历,但也可能演变成一个以自我为中心的过程。那么,如何成为一个更高效、更有同理心的审查员呢?本文想分享一些这方面的信息,希望能对你有所帮助。

合理构建PR(Pull Request)让审查员更轻松
图片来源:@iamdeveloper https://twitter.com/iamdevloper/status/397664295875805184

避免大规模的更新日志

· 保持简洁——如果可能的话,不要超过300行。

· 如果一项工作需要600多行代码,试着把它分散成更小的逻辑块,这样可以单独审查。

· 没有人想收到1000行畸形PR。好的审查员通常会拒绝这种规模的合并请求。根据原有经验,他们可能无法有效地对代码进行审查。

理解结构

· 将类似的更改分组进行提交。是否在不修改文件的情况下更改它们的位置?将其分组到自动提交这一步中,这样审查员就知道这不是他们需要关注的逻辑更改。

· 频繁提交更改以减少其范围。相对于较大的工作块,当提交较小的工作块时,审查员更容易关注到重要的内容。

短路可能导致混淆的局面

· 如果修改前一组提交中已存在的逻辑或结构,请确保通知审查员,以免他们偏离主题,转而评论目前不存在的代码。这种情况适用于当审查员进行一次又一次提交时。

提供足够的上下文

· 确保PR被清晰地描述,无论是通过链接的票据还是书面描述,最好两者都涉及。提供工作如何影响项目的实例,无论是视觉上的还是其他方面的。从审查员的角度看待问题,让读者尽可能地理解合并请求的目的。

高效并且有效地接近队友的PR

及时审阅

· 一旦被添加为PR的审查员,试着尽快审查。

· 完成请求和第一次评阅的最长时间不应超过一个工作日。

如果缺少上下文,收集上下文

· 如果PR缺乏来龙去脉,或者缺乏对其变化的描述,请联系作者,并在审查之前得到澄清。这可以大大减少由代码或目的的误解所造成的反复的状况。

从高水平开始

· 按照水平由高到低的顺序进行审查。如果存在较大的问题,在这些问题得到解决之前,不要对诸如样式之类的小变化进行评论。这样,作者可以首先关注最重要的修正结果。有时候,较小的问题会随着较大的变化而消失。

· 这也减少了自行车棚效应(bike-shedding,总在一些没有意义的问题上争论,而有意忽视那些真正需要解决的难点/痛点问题)的可能性。自行车棚效应会影响工作中更重要和更有影响力的方面。

处理分歧

· 如果对于代码版块不认同,请提供一个代码示例,来说明如何执行代码块。对于其他开发人员来说,这比只留下一条 “这应该是不同的”的注释来说有用得多。

请求改变

· 除非工作中存在根本问题,否则不要阻止PR。在同事面前设置一个关于命名的障碍对团队中的任何人都没有帮助。给同事去处理较小的变化的机会,然后继续他们的任务,而不是等待下一轮的反馈。

· 小问题应该通过项目风格指南来解决——但这是完全不同的话题。

同理心

图片来源:©xkcd https://imgs.xkcd.com/comics/code_quality.png

· 最重要的是,记住在你审查结束后还有其他人进行审查。以有益和具有建设性的方式提供反馈。如果合并请求正在被审查,那么要经常考虑如何得到相应的反馈。


算法的公平性也可以量化?试试这三个指标吧

留言 点赞 关注

我们一起分享AI学习与发展的干货
欢迎关注全平台AI垂类自媒体 “读芯术”

(添加小编微信:dxsxbb,加入读者圈,一起讨论最新鲜的人工智能科技哦~)