コードレビューでの英語
コードレビューにはなぜ特別な英語が必要なのか
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（良い指摘）”誰かがバグ、パフォーマンスの問題、または隠れた要件を見つけたとき、彼らが正しいことを確認します。
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 “コードレビューの礼儀のフォーミュラ”問題を指摘するとき
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?"異なる意見があるとき
Section titled “異なる意見があるとき”設計の決定に同意できない場合：
❌ "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 モードのコードレビューでの活用”あなたの母語の考え → 3 レベルの英語オプション → 最適なものを選択
シーン 1: バグを指摘
Section titled “シーン 1: バグを指摘”言いたいこと：「ここに競合状態がある。複数のリクエストが衝突する」
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 “日本語話者によくある干渉”| 誤った表現 | 原因 | より良いバージョン |
|---|---|---|
| ”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" |
| "Thank you for your kind review” | 敬語が過剰 | ”Thanks for the review!" |
| "It was decided to merge” | 主語の省略 | ”We decided to merge” |
クイックリファレンス表
Section titled “クイックリファレンス表”| 状況 | 表現 |
|---|---|
| 同意 + 小さな問題 | 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. |