Code Review 中的英语
代码审查为什么需要特殊英语
Section titled “代码审查为什么需要特殊英语”代码审查不是简单的技术反馈——它是团队沟通。措辞不当会:
- ❌ 显得傲慢或讽刺
- ❌ 伤害同事的积极性
- ❌ 造成误解(特别是跨文化团队)
- ❌ 让人以为你在”挑刺儿”而不是真诚帮助
好消息是:有一套标准的表达,大家都能理解。
10 个必学的代码审查表达
Section titled “10 个必学的代码审查表达”1. Nit (小问题)
Section titled “1. Nit (小问题)”“Nit” 来自 “nitpick”(吹毛求疵),但在代码审查中是个正面用词,表示”这很小,不影响大局,但值得改进”。
❌ "This variable name is bad"✅ "Nit: could we rename this to `userCount`?"✅ "Minor: I'd prefer `userCount` for clarity"何时用:
- 命名、格式、风格问题
- 重构建议(非必须但更好)
- 文档补充
2. LGTM (Looks Good To Me)
Section titled “2. LGTM (Looks Good To Me)”简称,表示你审查完了,同意合并。
LGTM! 👍或更正式:
LGTM. Great implementation.3. Blocker (阻塞性问题)
Section titled “3. Blocker (阻塞性问题)”严重问题,必须修复才能合并。
Blocker: This will cause a race condition in `handleUserLogin`.Here's why: ...何时用:
- 安全问题
- 性能回归
- 功能缺陷
- 数据丢失风险
4. Nice catch (好指出)
Section titled “4. Nice catch (好指出)”当别人找到了 bug、性能问题或隐藏的需求,你确认他们是对的。
Nice catch! I didn't think about the edge case where `null` ...或:
Good eye! This would definitely break on large datasets.5. Could you elaborate (你能详细说明吗)
Section titled “5. Could you elaborate (你能详细说明吗)”当你不明白为什么这样写,或想理解设计决策。
Could you elaborate on why we're using `Map` instead of `Object`?更友好的版本:
I'm curious about the choice to use `Map` here. Could you walk me through the reasoning?6. Nitpick (更强的”小问题”)
Section titled “6. Nitpick (更强的”小问题”)”比 “nit” 更直接,表示这真的是细节,但值得改进。
Nitpick: Could we add a blank line here for readability?7. Looks good (同意这部分)
Section titled “7. Looks good (同意这部分)”用在部分同意的情况。比如你同意逻辑,但想问问另一个部分。
This part looks good. One question about line 42: why are we...?8. We should probably (建议)
Section titled “8. We should probably (建议)”温和的建议,不是必须但推荐。
We should probably add error handling here for the case where the API call fails.9. Have you considered (开放式问题)
Section titled “9. Have you considered (开放式问题)”提出替代方案而不是直接说”应该这样做”。这给了作者思考的空间。
Have you considered using `useCallback` to prevent unnecessary re-renders?10. Ship it (就这样发布吧)
Section titled “10. Ship it (就这样发布吧)”最随意的赞同,表示我已经看过了,没有问题,可以上线。
Ship it! 🚀代码审查的礼貌公式
Section titled “代码审查的礼貌公式”公式: Context → Issue → Suggestion
❌ "This code is inefficient"
✅ "In `processUserData`, iterating `O(n²)` might be slow with large datasets. Could we use a `Set` to get `O(n)` instead?"不同意某个设计决策?
❌ "That's wrong"
✅ "I see your approach. One concern: `Math.random()` isn't cryptographically secure for auth tokens. Should we use `crypto.getRandomValues()`?"赞同时也问问题
Section titled “赞同时也问问题”不要只说”好”。提出有建设性的问题:
❌ LGTM
✅ LGTM! Curious: did you benchmark this against the regex approach we discussed? I'm wondering if it's noticeably faster for production scale.Express 模式在代码审查中的用法
Section titled “Express 模式在代码审查中的用法”你的中文思路 → 三层英文选项 → 选择最合适的
场景 1: 指出 bug
Section titled “场景 1: 指出 bug”你想说:“这里有个竞态条件,多个请求会冲突”
开启 DevGlish Express 模式:
Input: "这里有个竞态条件,多个请求会冲突"
Basic (Direct): "There is a race condition here, multiple requests will conflict"
Intermediate (Natural): "Multiple concurrent requests could cause a race condition"
Native (Idiomatic): "Concurrent requests might race here. Consider using a lock or queue." 💡 Tip: 直接给出解决方向,而不是只指出问题选择「Native」,或融合几个层级:
✅ Blocker: Multiple concurrent requests could race here. Consider adding a lock or queue to serialize writes.场景 2: 礼貌地建议改名
Section titled “场景 2: 礼貌地建议改名”你想说:“这个变量名太长了,可以改短点”
Input: "这个变量名太长了,可以改短点"
Basic (Direct): "This variable name is too long"
Intermediate (Natural): "Could we use a shorter variable name?"
Native (Idiomatic): "Nit: `getCurrentUserAuthenticationStatusFlag` is a bit verbose. How about `isAuthenticated`?" 💡 Tip: 提供具体建议,比只说"改短"更有用代码审查的审查者视角
Section titled “代码审查的审查者视角”当你看到好代码
Section titled “当你看到好代码”Nice implementation! Love how you're using `reduce()` here to avoidintermediate arrays. Makes the intent really clear.当你看到创意解法
Section titled “当你看到创意解法”Clever! I like this approach better than the nested loops we had before.I haven't seen this pattern before. Could you explain the benefitsof using `Proxy` here? Curious to learn.I'm not sure about this. Could we discuss it sync? Happy to do a quick call.常见的代码审查错误
Section titled “常见的代码审查错误”中文使用者常见的干扰
Section titled “中文使用者常见的干扰”| 错误表达 | 原因 | 更好的版本 |
|---|---|---|
| ”This code is not good” | 太直接,显得傲慢 | ”Could we refactor this for clarity?" |
| "You must change this” | 听起来像命令 | ”We should probably change this" |
| "This is wrong” | 伤人 | ”This might cause X in scenario Y" |
| "Please to fix this” | 中式英文 | ”Could you fix this?" |
| "The code of the function is bad” | 过度使用 “of" | "The function could be clearer” |
代码审查的话题清单
Section titled “代码审查的话题清单”准备大的代码审查?保存这些表达到生词本的 code-review 标签:
Essential Phrases (15 entries) ├─ "Nit: " ├─ "LGTM" ├─ "Nice catch" ├─ "Blocker: " ├─ "Could you elaborate on..." ├─ "Have you considered..." ├─ "We should probably..." └─ [more...]
Questions & Suggestions (10 entries) ├─ "I'm not sure about X. Could we discuss?" ├─ "Did you benchmark this?" ├─ "Any edge cases we should handle?" └─ [more...]
Praise (5 entries) ├─ "Great implementation" ├─ "Love this pattern" └─ [more...]在写审查前,快速浏览一遍这个列表,确保你的语气既专业又友好。
| 情况 | 表达 |
|---|---|
| 同意 + 小问题 | LGTM, just one nit: … |
| 不同意某个决策 | I see your approach, but have we considered…? |
| 严重问题 | Blocker: This will cause… |
| 小建议 | Nit: Could we…? |
| 赞同+想学 | Nice! Could you explain why you chose…? |
| 不确定 | I’m not sure about this. Could we discuss? |
| 完全同意 | LGTM! Ship it. |