Nit：预先说明是小瑕疵的引言

今日英语表达 14/30 · 阶段：接收并回复评审。 所有例句均为本文特意创作，并非搬运自实际仓库中的评论，变量名仅为示例。

一览

nit 来源于 nitpick（挑剔、吹毛求疵）。在评审评论前加上 Nit:，意味着“这是一个小瑕疵”。比如拼写错误、变量名、空行、注释语句等对功能无影响但润色一下会更好的地方。

Google 的代码评审指南将 Nit 作为表明评论分量的引言示例，解释其含义为“这是一件小事。从技术上讲修复它是对的，但没有重大影响”。该指南还同时介绍了 Optional（或 Consider）和 FYI。加上这样的前缀，作者就不会误以为必须修复所有评论，并且可以决定先做什么。

收到 Nit 的作者通常会去修复，因为这很容易改。不过，Nit 并不是阻止合并（merge）的阻碍，如果有理由，也可以不修复并简要说明。相反，如果评审者留下太多 Nit，作者可能会感到疲惫，因此有时会将几个小问题合并为一条并称为 “nits”。

这也与第 19 篇的 Not a blocker 相连。“LGTM with a few nits”意为“除了几个小瑕疵外一切都好”，也就是说没有大问题。

情况 1：评审者的行评论

Nit: cfg → config would be more consistent with the rest of the package.

情况 2：作者的回复

Done, thanks!

对 Nit 的回复越简短越好。如果已经修改，用 Done 或 Fixed 一个词就足够了。

情况 3：决定不修改时

I kept cfg here because the same name is used in the generated client, and I'd rather not diverge from it. Happy to change it if you feel strongly.

if you feel strongly 意为“如果您坚决要求更改”，将决定权交给评审者并礼貌地收尾。

I'm so sorry for my mistake. I will be more careful. 因为一个 Nit 就过度道歉，反而会让评审者感到有负担。
- 修改后的句子：Good catch, fixed.
作者收到 Nit 后 不作任何回复直接忽视。 即使不打算修改，留下简短的理由也是一种礼貌。
- 修改后的句子：Leaving this as is to match the existing naming, if that's okay.
作为评审者 去掉 Nit 且语气断然。 You should rename this. 读起来就像是必须修复的严肃指出。
- 修改后的句子：Nit: maybe rename this to podName?

假设你是评审者，请将以下内容写成行评论。

是个小问题，这个注释里有拼写错误（将 recieve 改为 receive）。

Nit: typo, "recieve" → "receive".

惯例上，Nit 评论不宜写得太长。用箭头（→）直接指出要修改的内容就足够了。如果使用 GitHub 的 suggestion 功能，作者甚至可以通过一个按钮直接采纳。

TT 的话： Nit 体现了“这只是小事”的体谅。接收方也只需简短、轻松地回复即可。

Google Engineering Practices, How to write code review comments(Label comment severity): https://google.github.io/eng-practices/review/reviewer/comments.html
Merriam-Webster, 「nitpick」: https://www.merriam-webster.com/dictionary/nitpick