MoSCoW：你未使用的最佳代码审查技术

我们都经历过这种情况。你的代码收到了审阅者的评论，感觉还不如从头重写。这让人沮丧，感觉是在浪费时间，尤其是你知道它能正常工作，并且满足任务要求的时候。

forEach类似这种情况可能会导致您挑选审阅者，在 a与 a之间进行无休止的来回争论for，并且总体上对整个过程感到有些厌倦。

好吧，让我向你介绍一个系统，它可以让评论者以一种方式表达他们的想法，准确地表明每条评论有多重要，以及你需要对它给予多少关注。

MoSCoW 源自项目管理领域，是对如下需求列表的名称：

• 必做
• 应该
• 库尔斯
• 沃尔斯

我不会详细讨论它们在它们起源的世界中​​究竟意味着什么，因为这不相关，而且这个系统是如此不言自明，你可能已经知道我要去哪里了。

中/中/中/西

每个注释应以M:、S:或开头C，W:然后是注释。

• 必须：必须修改才能获得批准。这些错误要么违反了团队的编码规范，要么明显不正确，会导致 bug。这些错误不容忽视。
• 应该：这些是显而易见且值得改进的地方。你必须给出忽略这些改进的理由，并且代码审查人员必须同意。如有需要，可以引入第三方。
• Could：这些是审阅者认为可以改进代码库的细节，但可能超出了任务要求。如果他们对函数名称有更好的想法，或者想留下评论，但不太介意你采纳建议，那么可以使用这个前缀。这些可以忽略，无需说明理由。
• 会：这类评论通常用于“我不会这样做”这类需要大量修改但完全出于个人喜好的评论。这类评论很少被使用，因为会实际上只是给评审者一个表达自己想法的空间。理想的用法是指导团队中的初级成员，并在评审结束后围绕此问题进行后续讨论。

在上面的 for 循环示例中，我会说：

S: Use forEach here to avoid off by one errors and aid understanding of loop conditions

或类似。

概括

在下一次团队会议上介绍这一点，清楚地了解你的必须做的事情，并对一些应该做的事情有一个大致的了解，你就会发现这对参与代码审查过程的每个人来说是多么的自由。

想要更多类似的内容吗？欢迎订阅我的邮件列表“职业转型编程”，免费获取我书中的一章。