「良いコード」の基準はどこで作られるか
コードレビューで「ここ、なんか気持ち悪いんですよね」と言えるエンジニアと、「動いてるからいいんじゃないですか」で止まるエンジニアの違いは何でしょうか。
それは「良いコードを大量に読んだ経験の差」です。
コードの美醜を判断するセンスは、会社の業務コードだけを読んでいても培われません。業務コードは良い設計もあれば、歴史的な負債も混在していて、「基準」にはなりにくいからです。
OSSコードリーディングが優れた理由
OSSには、世界中のエンジニアによるレビューを何百回も通過したコードが蓄積されています。命名規則、関数の分割粒度、エラーハンドリングのパターン、テストの書き方……それらは「なぜそうなっているか」の理由とともに、PRのコメントやIssueに記録されています。
【OSSコードリーディングで得られるもの】
- 命名の哲学（なぜこの変数名なのか）
- 抽象化の粒度感（どこで境界を引くのか）
- エラー処理の設計（例外をどのレイヤーで扱うか）
- テストの粒度（何をユニットテストし、何をE2Eに任せるか）
- PRコメントから「何が良くて何が悪いか」の判断基準
どのOSSを読めばいいか（技術別おすすめ）
初心者がいきなりLinuxカーネルを読む必要はありません。自分が普段使っている技術スタックに近いOSSから始めましょう。
【技術別 最初に読むOSS】
Web（JavaScript/TypeScript）:
- Express.js: Webフレームワークの基本設計
- Zod: バリデーションライブラリの型設計
Python:
- Requests: HTTPクライアントの美しいAPI設計
- Click: CLIライブラリのインターフェース設計
Go:
- Chi: 軽量Webフレームワーク（Goらしい書き方の教科書）
インフラ・DevOps:
- Terraform Provider（小さなプロバイダ）: Goとインフラの両学習に
「読むだけ」で終わらせない3ステップ
ただコードを眺めるだけでは定着しません。
Step 1: 「なぜこう書いたのか」を考えながら読む
→ 疑問に感じた箇所は、GitのBlameでコミット履歴を追い
当時のPRやIssueを確認する
Step 2: 読んだコードの「良い点・改善できそうな点」を
Notionやobsidianにメモする
Step 3: 週1回、チーム内で「今週読んで良かったOSSのコード」を
5分シェアする（ナレッジの共有）
Step 3まで実践できると、チーム全体のコードレビューのレベルが上がり始めます。
まとめ
コードレビューは「バグを見つける作業」ではなく「設計の思想を読む作業」です。
その思想を読むセンスは、優れた設計を大量に読み込むことでしか養われません。週に1時間、業務のコードではなくOSSのコードを読む時間を確保してみてください。3ヶ月後、あなたのレビューコメントの質は確実に変わっています。
推奨タグ: OSS, コードレビュー, 設計, 学習, チーム開発