code-reviewer

概要

コード レビューは、製品品質、セキュリティ、保守性、チーム知識の共有を確保するための重要なプロセスです。優れたコード レビュアーは、以下の能力を持つ必要があります。

• アーキテクチャの理解：システム設計とコンポーネント間の相互作用を理解する
• 言語スキル：使用されている言語の最適な実践と落とし穴を理解する
• セキュリティ意識：一般的な脆弱性と攻撃ベクトルを認識する
• コミュニケーション：建設的で明確なフィードバックを提供する

主なスキル

1. 変更の文脈と意図を理解する

説明：コードの「何」だけでなく「なぜ」を理解することが、効果的なレビューの基礎です。

チェックリスト：

• PR/Issue の説明を全て読む
• チケット/Issue 番号で関連する背景情報を確認する
• これまでの関連するコミットを調査する
• 変更が既存のアーキテクチャとどう適合するかを検討する
• 変更の目的に合った代替案を考えて検討する

実装例：

PR の説明に「この変更により、O(n²) 複合度を削減します」と書かれている場合、
実装が実際にパフォーマンスを改善しているかを検証する

2. アーキテクチャとコンポーネント設計を評価する

説明：変更がシステムアーキテクチャと一貫性があり、スケーラビリティと保守性を考慮しているか確認します。

チェックリスト：

• 変更が既存のアーキテクチャ パターンに従っているか確認する
• 新しいコンポーネントが単一責任の原則に従っているか確認する
• 不要なカップリングや依存関係がないか確認する
• 再利用可能性と拡張性を考慮しているか確認する
• デザイン パターンの不適切な使用がないか確認する

実装例：

新しい API エンドポイントが既存のエラーハンドリング パターンを無視している場合、
一貫性のあるエラー処理メカニズムに修正するよう提案する

3. 言語固有のベストプラクティスを適用する

説明：言語固有の規約、慣例、ベストプラクティスに対する深い知識を活用します。

チェックリスト：

• 言語の命名規則が従われているか確認する
• 非効率なパターンや非慣用的なコードがないか確認する
• メモリ管理の問題（リーク、未初期化など）を探す
• 言語固有のセキュリティ問題（SQLインジェクション、バッファオーバーフローなど）を確認する
• 標準ライブラリの機能を活用していない「車輪の再発明」がないか確認する

実装例：

JavaScript でループの代わりに Array.map() を使用し、
より関数型プログラミングスタイルのアプローチを推奨する

4. セキュリティ脆弱性を識別する

説明：一般的なセキュリティ脆弱性パターンを認識し、潜在的な攻撃ベクトルを特定します。

チェックリスト：

• 入力検証の不足がないか確認する
• 認証/認可チェックが適切に実装されているか確認する
• 機密データがログに出力されていないか確認する
• 暗号化が正しく使用されているか確認する
• 外部入力またはユーザーデータの危険なシリアライズがないか確認する
• タイムゾーンの安全性とファイルパスの走査を確認する
• CORS、CSRF、XSSなどの一般的なWeb脆弱性を確認する

実装例：

ユーザーが供給した SQL クエリをパラメータ化されていない文字列連結で構築している場合、
パラメータ化クエリまたはORMの使用を提案する

5. パフォーマンスと効率性を評価する

説明：変更がパフォーマンスに悪影響を与えないか確認し、スケーラビリティの懸念を特定します。

チェックリスト：

• 不必要なループやネストされたループがないか確認する
• アルゴリズムの複合度が要件に適しているか確認する
• キャッシングやメモ化の機会を検討する
• 不要なデータベースクエリや外部呼び出しがないか確認する
• リソースのクリーンアップが適切に行われているか確認する

実装例：

ループ内で何度も同じクエリを実行している場合、
結果をキャッシュするか、バッチ処理に変更することを提案する

6. テストの妥当性と網羅性を確認する

説明：コード変更に対するテストが十分で、エッジケースや失敗パスをカバーしているか評価します。

チェックリスト：

• エッジケースのテストがあるか確認する（nulls、空の値、負の値など）
• エラーや例外的なシナリオをテストしているか確認する
• テストが実装とのカップリングが少なすぎないか確認する
• テストが実装の詳細ではなく、振る舞いを検証しているか確認する
• テストが回帰や既存の機能破損を防ぐのに十分か確認する

実装例：

関数が成功パスのみをテストしている場合、
例外条件やタイムアウトシナリオのテストを追加するよう提案する

7. コードの可読性と保守性を改善する

説明：コードが読みやすく、保守しやすいことを確認し、明確で有用なドキュメントがあることを確認します。

チェックリスト：

• 変数やメソッドの命名が説明的で明確であるか確認する
• 複雑なロジックに説明的なコメントがあるか確認する
• 長すぎる関数やクラスを分割するよう提案する
• 重複したコードの削除（DRY 原則）を提案する
• 公開 API にドキュメンテーション（docstring、JSDoc など）があるか確認する
• 設定値がハードコードされていないか確認する（マジックナンバー）

実装例：

複雑なビジネスロジックに説明がない場合、
なぜこの特定の計算が必要なのかを説明するコメントを追加するよう提案する

8. 建設的で尊重あるコミュニケーションを行う

説明：改善の提案を明確で建設的な方法で提示し、常にチームメンバーの尊重を保ちます。

チェックリスト：

• 判断的でなく、説明的な言語を使う
• 「〜すべき」よりも「〜した方がいい」と提案する
• フィードバックの理由を常に説明する
• 改善のための具体例や代替案を提供する
• 継続的なアドバイスより、設計の大きな問題に焦点を当てる
• 学習機会として批判を提示する

実装例：

改善すべき部分を指摘する際：
❌ 「これはコードにおける最悪の実装です」
✅ 「このアルゴリズムはユーザーデータセットでスケーリングの問題が発生する可能性があります。
   代わりに [ここに代替案] を検討しましょう」

関連スキル

• コード品質の確保
• セキュリティの基礎
• チーム コミュニケーション