2.6　提供并回应评审反馈

代码评审的目标是保证代码的总体质量符合公司规范。因此反馈应当是建设性的，不能成为贬低同事或令别人难堪的借口。同样，评审人的反馈应当聚焦于合理的行为与解释，不得针对具体个人。

图2-12展示了创建Pull Request（PR），执行代码评审以及接受或拒绝PR的流程。

2.6.1　评审人提供反馈意见

职场霸凌可能造成不良后果，这对于编程环境来说也是如此。没有人喜欢自以为是的开发者。因此评审人需要有良好的软性技术和沟通技巧。有些人很容易感到自己被冒犯而采取错误的方式进行应对。因此要考虑被评审人特点，预判其反应，这有助于我们谨慎地选择沟通方式和措辞。

代码评审人应当理解需求并确保代码符合业务要求。因此请注意以下问题：

• 是否能够阅读并理解代码的含义。
• 是否能够找到一些潜在的缺陷。
• 代码是否经过了一些权衡取舍。
• 如果前一个问题答案为“是”，那么为什么要进行这种取舍。
• 这种权衡是否会带来技术债，是否需要进一步纳入项目。

当评审结束时，有三类反馈供评审人选择：正面反馈、可选的反馈和关键反馈。评审人可以在正面反馈中对开发者的出色之处进行表扬。这是鼓舞士气的良好途径（在开发团队中士气往往会变得很低）。可选反馈可用于帮助开发者根据公司的规范磨炼编程技能，也可以对软件开发带来整体性的改善。

最后介绍关键反馈。关键反馈适用于那些已经发现的、在代码最终通过并提交到QA部门之前必须解决的问题。在进行此类反馈的时候，请务必谨慎发言以免冒犯他人。重要的是，关键反馈要针对具体的问题，并提出充分的理由来支撑反馈的内容。

2.6.2　被评审人回应反馈

被评审人应当有效地向评审人介绍代码的背景信息。小步提交是有效传递信息的方式。少量的代码比大量的代码更容易评审。需要审查的代码越多，越容易出现漏网之鱼。在等待代码审查时，请不要再对代码进行任何更改。

和想象中一样，评审反馈有可能时正面的，可选的或者关键性的。积极的反馈有助于提升你对项目的信心和士气。你可以在此基础上坚持良好的实践。对于可选的反馈可以选择是否采取行动，但在此之前最好能够和评审人进行沟通。

对于关键反馈，你必须认真对待并付诸行动，因为这种反馈对于项目的成功是必不可少的。请一定注意以礼貌而专业的方式处理此类反馈，不要让评审人的意见影响自己，因为这些评论并非针对个人。这一点对新人程序员和缺乏自信的开发者来说尤其重要。

收到了评论者的反馈后，请立即采取行动，并确保在必要时和评审人进行沟通。