全文共1348字,预计学习时长3分钟
对开发人员来说,审查代码是家常便饭。这可能是一个虚心学习的经历,但也可能演变成一个以自我为中心的过程。那么,如何成为一个更高效、更有同理心的审查员呢?本文想分享一些这方面的信息,希望能对你有所帮助。
避免大规模的更新日志
· 保持简洁——如果可能的话,不要超过300行。
· 如果一项工作需要600多行代码,试着把它分散成更小的逻辑块,这样可以单独审查。
· 没有人想收到1000行畸形PR。好的审查员通常会拒绝这种规模的合并请求。根据原有经验,他们可能无法有效地对代码进行审查。
理解结构
· 将类似的更改分组进行提交。是否在不修改文件的情况下更改它们的位置?将其分组到自动提交这一步中,这样审查员就知道这不是他们需要关注的逻辑更改。
· 频繁提交更改以减少其范围。相对于较大的工作块,当提交较小的工作块时,审查员更容易关注到重要的内容。
短路可能导致混淆的局面
· 如果修改前一组提交中已存在的逻辑或结构,请确保通知审查员,以免他们偏离主题,转而评论目前不存在的代码。这种情况适用于当审查员进行一次又一次提交时。
提供足够的上下文
· 确保PR被清晰地描述,无论是通过链接的票据还是书面描述,最好两者都涉及。提供工作如何影响项目的实例,无论是视觉上的还是其他方面的。从审查员的角度看待问题,让读者尽可能地理解合并请求的目的。
高效并且有效地接近队友的PR
及时审阅
· 一旦被添加为PR的审查员,试着尽快审查。
· 完成请求和第一次评阅的最长时间不应超过一个工作日。
如果缺少上下文,收集上下文
· 如果PR缺乏来龙去脉,或者缺乏对其变化的描述,请联系作者,并在审查之前得到澄清。这可以大大减少由代码或目的的误解所造成的反复的状况。
从高水平开始
· 按照水平由高到低的顺序进行审查。如果存在较大的问题,在这些问题得到解决之前,不要对诸如样式之类的小变化进行评论。这样,作者可以首先关注最重要的修正结果。有时候,较小的问题会随着较大的变化而消失。
· 这也减少了自行车棚效应(bike-shedding,总在一些没有意义的问题上争论,而有意忽视那些真正需要解决的难点/痛点问题)的可能性。自行车棚效应会影响工作中更重要和更有影响力的方面。
处理分歧
· 如果对于代码版块不认同,请提供一个代码示例,来说明如何执行代码块。对于其他开发人员来说,这比只留下一条 “这应该是不同的”的注释来说有用得多。
请求改变
· 除非工作中存在根本问题,否则不要阻止PR。在同事面前设置一个关于命名的障碍对团队中的任何人都没有帮助。给同事去处理较小的变化的机会,然后继续他们的任务,而不是等待下一轮的反馈。
· 小问题应该通过项目风格指南来解决——但这是完全不同的话题。
同理心
· 最重要的是,记住在你审查结束后还有其他人进行审查。以有益和具有建设性的方式提供反馈。如果合并请求正在被审查,那么要经常考虑如何得到相应的反馈。
留言 点赞 关注
我们一起分享AI学习与发展的干货
欢迎关注全平台AI垂类自媒体 “读芯术”
(添加小编微信:dxsxbb,加入读者圈,一起讨论最新鲜的人工智能科技哦~)