👨💻 はじめに
Googleでシニアソフトウェアエンジニアを務める鈴木です。今回の「エンジニアのリアルな経験談シリーズ」では、**「GAFAのコードレビュー基準と実践例」**をテーマに、私が実際にGoogleで経験した「レビューで10回連続リジェクトされた衝撃の事例」から学んだ、超厳格なコード品質基準を公開します。
特に、**「なぜGAFAのレビューはあそこまで厳しいのか？」**という核心部分を、設計思想・パフォーマンス・セキュリティの3軸から解説。記事の最後には、今日から使える「レビューを一発通過させる」テンプレートも用意しました！
📌 この記事で学べること
- Googleの「コードレビューガイドライン」で禁止されている7つのコーディングパターン
- 「拡張性」と「保守性」を両立させるGAFA流設計手法
- レビュアーを唸らせる「説明的コメント」の書き方
🔥 1. GAFAコードレビューで即リジェクトされる「7つの致命的ミス」
❌ パターン1: 「とりあえず動けばOK」設計
悪い例:
def calculate_price(items):
# とりあえず動くロジック
total = 0
for item in items:
if item == "apple":
total += 100
elif item == "orange":
total += 50
return total
✓ Google流改善案:
class ItemPriceCalculator:
PRICE_TABLE = {"apple": 100, "orange": 50} # 価格テーブルを明示
def calculate(self, items):
return sum(self.PRICE_TABLE.get(item, 0) for item in items)
なぜダメ？: 価格変更時にコード修正が必要 → Open-Closed原則違反
❌ パターン2: テスト不可能な設計
悪い例:
public class PaymentService {
public void process() {
PaymentProcessor processor = new PayPalProcessor(); // 直接依存
processor.charge();
}
}
✓ Google流改善案:
public class PaymentService {
private final PaymentProcessor processor;
// 依存性注入(DI)
public PaymentService(PaymentProcessor processor) {
this.processor = processor;
}
}
🚀 2. 設計品質を劇的に上げる「Google流3原則」
原則1: 「変更コスト」で設計を評価せよ
Googleでは、**「将来の変更に要する時間」**で設計品質を測定します。
評価基準:
- クラス追加に要する時間: 1時間未満 → 合格
- 既存テストの修正量: 10%未満 → 合格
原則2: コメントは「Why」を書け
悪いコメント:
// ループを回す
for i := 0; i < 10; i++ {
良いコメント:
// キャッシュサイズ上限10は、メモリ使用量とレイテンシのトレードオフ測定結果（実験ID#X-1289参照）
for i := 0; i < 10; i++ {
原則3: パフォーマンス特性を明記
Googleのテンプレート:
## パフォーマンス特性
- Time Complexity: O(n log n)
- Space Complexity: O(1)
- 想定最大入力サイズ: 1M records
💎 3. 【超実践】レビューを一発通過させる「Google式PRテンプレート」
## 変更の目的
[プロジェクト全体のどの目標に貢献するか]
## 設計選択理由
[検討した代替案と比較したメリット]
## 影響範囲
- 変更が影響するモジュール:
- 必要なマイグレーション:
## テストカバレッジ
[追加/修正したテストケースの概要]
## パフォーマンス影響
[ベンチマーク結果または予測]
🎯 まとめ：今日から使える「プロ級」レビュースキル
- 「変更コスト」を意識した設計を常に心がける
- コメントは**「What」より「Why」**を書く
- PRテンプレートで情報を構造化する
💬 あなたの「コードレビューあるある」をコメントで教えてください！
次回は「シリコンバレー流リーダーシップとチームマネジメント」を解説予定です。
（画像キャプション: Googleの内部コードレビューツール「Critique」の画面）
「役に立った！」と思ったら♡やリポストをお願いします！ 🚀