反馈梯子：我们如何在Netlify编码代码评论
代码审查对于作为专业开发人员来说是至关重要的部分：在大多数工程组织中，没有至少经过另一位工程师的检查，就无法检入任何代码。这对于执行代码标准有很多好处。但是，如果我们没有为代码审查本身建立标准，就会遇到沟通问题。
为了解决这个问题，Netlify的UX团队开发了用于代码审查的共享术语，我们将其称为“反馈梯”！对于Netlify来说，它的工作效果非常好，我们希望与您分享它对您的团队的帮助。
代码审查涵盖了系统无法捕获的所有内容。我们可以运行所有我们喜欢的漂亮和棉绒规则以及自动化的单元/集成/端到端测试。但是人们仍然必须检查测试是否正确，代码是否符合公认的标准，注释和命名以及代码组织和体系结构选择可以由其他人维护。
但是，可以合并的好代码与必须更改的坏代码之间没有二分法。理想的解决方案和运输速度之间需要权衡：完美是善的敌人。代码审查反馈并非都是平等的-有时您可能只是指出了一点优化，有时您可能会在需要立即关注的阻止程序上敲响警钟！
最后但并非最不重要的一点是，代码审查仍然是异步通信的一种形式，因此丢失了许多上下文（例如肢体语言和来回往返的机会）。对于大多数远程公司而言，这对我们尤为重要，因此我们希望找到一种在反馈中增加一些细微差别的方法。
许多开发人员通过指出反馈的优先级来说明它们是否是“优先级”。 “ nit”就像“ nitpick”一样-您自愿表示所讨论问题的严重性较低。但是，仍有很多解释的余地-一些“ nits”仍然是代码标准问题，并非每个没有“ nits”的反馈都是一个高优先级的阻止程序。
Leslie最终落入的系统是“反馈阶梯”的想法。提供反馈时，它有助于团队使用共享术语来更好地理解反馈在更大范围内的适用范围。在我们的工作环境中，这尤其必要，我们的目标是尽快发货，经常迭代并尽快压扁壁球。
为了使反馈阶梯的水平更容易记住和使用，克里斯汀提出了隐喻性的名称来描述每个步骤。想法是您住在一栋仍在建造的房屋中。我们列出的每个“不便之处”（山，巨石，鹅卵石，沙子，灰尘）对您每天的房屋生活都有不同程度的影响。例如，您可能会注意到地板上有灰尘，但这并不妨碍您生活的能力；另一方面，一块巨石会挡住门。
我们在梯子上每个步骤的反馈方式都应根据其严重性进行适当调整。
这座山把你房子的屋顶撕了。里面没有空间供您使用，您在执行其他任何操作之前必须立即照顾好它！
此反馈会阻止所有相关工作，并需要立即采取措施。切勿在直接消息或私人对话中提供此类反馈。
示例：开发人员正在处理一个问题，并发现了以前未知的问题域的更多信息，意识到该问题本身由于不可行，需要分解或需要重新提交给制图板解决方案实际上并没有解决预期的用户故事。
巨石挡住了门，人们无法进入，您也无法离开。你得把它从那里拿走。但是您可以先照顾一些其他事项，例如完成在厨房中安装灯的工作。
此反馈应阻止工作前进或获得批准，但不一定需要团队立即采取行动。
示例：已实现一项功能，并对其进行了标记以供审核。在测试Deploy Preview时，审阅者会注意到使用了错误的API端点，并且前端中显示的数据不正确。
当您在地板上遇到小卵石时，它会非常令人沮丧，但是它不会经常妨碍您，因此您可以在有时间的时候对其进行处理。
此反馈不应阻碍工作的进行或获得批准，但确实需要团队的未来行动。通常，这意味着MVP或这项工作的初稿不是必需的反馈，但应在某些时候加以解决。
示例：在设计评审期间，设计师说他们想更改状态标志的背景颜色以帮助使状态更清晰。
在你的房子里放沙子有点烦人；您应该稍后考虑是否值得清理。但也许您最终还是要向人们指出您的房子在海滩上，所以无论如何它总是会有点沙，而且您愿意与之同住，因为您将要在海滩上！
该反馈不应阻碍工作的进行或获得批准。如果至少有其他团队成员同意，则项目负责人或所有者应考虑并实施反馈。
示例：在代码审查期间，团队成员留下了有关重构以提高可读性的反馈。在前端团队中[sand]反馈的一个非常常见的示例是代码样式或方法（不面向用户）。
有些人可能会注意到灰尘，认为值得清理，而其他人则根本不介意。
该反馈不应阻碍工作的进行或获得批准。如果项目负责人或所有者认为有用，则应考虑并予以实施。
示例：在代码审查期间，团队成员为新变量建议一个不同的名称。
我们发现我们的“反馈阶梯”系统在简洁地编码反馈的严重性方面非常有用，并且认为它对其他工程团队也有帮助。您可能希望在团队中实施时添加或删除行，并且如果您对此想法有任何有趣的变化，我们也希望听到他们！
异步代码审阅的最后一个技巧是：往返（从队友到审稿人再到队友）非常昂贵，每次冲刺最多要花两个工作日。最小化往返次数的一种好方法是抢先查看您自己的代码，添加仅在查看时阅读的注释。 （当然，如果注释对将来的读者有意义，请考虑在实际提交的代码本身中添加注释！）
这使您可以利用对队友的了解，并表示您对他们通常会提出的问题很体贴。这提高了团队的信任度和运输速度。在您进入“反馈阶梯”之前，作为一项先发制人的措施，您可以将其视为代码审查的“底层”！
