如何写出不显得粗鲁的代码审查评论
I’m happy to help translate the article, but I only see the source line you provided. Could you please paste the full text you’d like translated (excluding any code blocks or URLs you want to keep unchanged)? Once I have the content, I’ll translate it into Simplified Chinese while preserving the original formatting.
一个词的差别
❌ “这不对。”
✅ “我认为这可能会导致问题，因为 …”
两者传达相同的信息，但第二种更像是对话式，而不是评判性的。
5 种听起来严厉的表达方式（以及该怎么说）
1. “You should …”
听起来像命令。
- ❌ “You should use a constant here.”
- ✅ “What do you think about using a constant here?”
- ✅ “Have you considered using a constant here?”
为什么这样有效： 提问可以邀请讨论；而命令则会扼杀讨论。
2. “Why did you …?”
听起来像审问。
- ❌ “Why did you use a for loop here?”
- ✅ “I’m curious about the for loop—was there a specific reason you chose it over
map?” - ✅ “Just wondering—is there an advantage to the for‑loop approach here?”
为什么这样有效： “我很好奇” 表示真诚的兴趣，而不是评判。
3. “This doesn’t make sense.”
暗示作者困惑或愚蠢。
- ❌ “This logic doesn’t make sense.”
- ✅ “I’m having trouble following this logic—could you walk me through it?”
- ✅ “I might be missing something, but I’m not sure how this handles the edge case.”
为什么这样有效： 你为自己不理解负责，显得谦逊。
4. “Just do X.”
“Just” 让请求显得轻率或不屑。
- ❌ “Just add error handling.”
- ✅ “It would be great to add some error handling here.”
- ✅ “Could we add error handling for the null case?”
为什么这样有效： 去掉了轻视的语气，同时承认了对方的付出。
5. “This is inefficient / bad / wrong.”
标签化会让人感到个人被指责，即使指的是代码。
- ❌ “This approach is inefficient.”
- ✅ “I wonder if we could improve performance here by …”
- ✅ “This works, but I’m thinking we might hit performance issues at scale. What if we tried …?”
为什么这样有效： 先肯定代码可以工作，再提出改进建议。
魔法短语
请随时使用这些替代说法：
| 替代… | 尝试… |
|---|---|
| “You need to …” | “Could we …” |
| “This is wrong” | “I think there might be an issue with …” |
| “Why didn’t you …” | “I’m curious why …” |
| “Obviously …” | (delete the word) |
| “Just …” | (delete the word) |
| “You forgot to …” | “It looks like we might need …” |
何时直接
并非所有评论都需要软化。应在以下情况下直接说明：
- 存在明显的 bug – “This will throw a null‑pointer exception on line 42.”
- 存在安全问题 – “This exposes the API key. Let’s move it to environment variables.”
- 这是一条简单的事实 – “This function is missing a return statement.”
事实不需要缓冲；观点需要。
文化说明
在某些文化中，直率被视为尊重和诚实的标志。在英语专业环境中，间接性常被认为更有礼貌，因为它表明你尊重对方的判断。两种方式本身并没有对错之分，但在为国际团队用英语写作时，稍微柔和一点会事半功倍。
快速练习
请用更柔和的语气（或像在代码注释中一样）改写以下句子：
- “可以考虑给这个变量重新命名。”
- “这个函数有点长，或许可以拆分一下。”
- “能否解释一下为何使用回调而不是 async/await？”
本文词汇
| 单词 | 含义 | 示例 |
|---|---|---|
| harsh | 过于强烈、不友好 | “反馈让人觉得很苛刻。” |
| defensive | 为了防御批评而保护自己 | “我提到那个 bug 时，他变得很防御。” |
| dismissive | 把某事当作不重要或不值得理会 | “‘直接修复’听起来很轻率。” |
| humble | 不自以为高人一等 | “以‘我可能错了’开头是一种谦逊。” |
| cushioning | 使语言更柔和或不那么直接 | “事实本身不需要任何修饰。” |
轮到你了
你收到过最糟糕的代码审查评论是什么？
或者最好的那条——教会你东西且不让你感觉糟糕的评论？
在评论区分享，让大家互相学习。