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

全文共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，加入读者圈，一起讨论最新鲜的人工智能科技哦～）