コンテンツにスキップ

03.レビュー規定

このドキュメントは、本プロジェクトのソースコードに対する品質を維持・向上させるためのレビュープロセスに関する規則を定めます。

Abstract

"レビューの目的" コードレビューは、単なる間違い探しではありません。- 品質の向上: コードが規約に準拠し、堅牢で保守性の高いものであることを保証します。- 知識の共有: 変更内容とその背景をチームで共有し、属人化を防ぎます。- 学習と成長: より良い設計や実装について議論し、チーム全体のスキル向上に繋げます。

1. レビューの観点

コードをレビューする際は、以下の観点を総合的に確認してください。

  • 規約への準拠:
  • 設計とアーキテクチャ:
    • 設計はシンプルで、過度に複雑になっていないか？（KISS, YAGNI原則）
    • 責務は適切に分離されているか？（単一責任の原則）
  • 可読性と保守性:
    • 変数名や関数名は、その意図が明確に伝わるか？
    • コードの重複はないか？（DRY原則）
  • 堅牢性と正確性:
    • ロジックは要求仕様を満たしているか？
    • エッジケースや異常系の処理は考慮されているか？
    • エラーハンドリングは適切か？
  • パフォーマンス:
    • 明らかなパフォーマンス上のボトルネックはないか？
    • リソース（メモリ、DB接続など）は適切に管理・解放されているか？
  • テスト:
    • 変更に対するテストは追加・更新されているか？
    • テストは、正常系だけでなく異常系もカバーしているか？
  • セキュリティ:
    • 既知の脆弱性（SQLインジェクション、XSSなど）を生み出す可能性はないか？

2. レビュープロセス

コードのレビューは、GitHubのプルリクエスト(Pull Request)機能を利用して行います。プロセスは、03.ドキュメント規定/03_レビュー規定 に準じます。

  1. ブランチの作成
  2. プルリクエストの作成
  3. レビュアーの指定
  4. レビューの実施とフィードバック
  5. 修正と再レビュー
  6. 承認 (Approve)
  7. マージ

3. セルフレビュー

PRを作成する前に、作成者自身で以下の点についてセルフレビューを行うことを強く推奨します。

  • [ ] 動作確認: ローカル環境でコードが意図通りに動作することを確認したか？
  • [ ] テストの実行: 全ての自動テストが成功することを確認したか？
  • [ ] フォーマッター/リンターの実行: PrettierやRuff, dotnet formatなどを実行し、スタイル違反がないことを確認したか？
  • [ ] 不要なコードの削除: デバッグ用のconsole.logや、コメントアウトされたコードは削除したか？
  • [ ] PRの説明: 変更の目的（What）、背景（Why）、そして行ったこと（How）を、PRのDescriptionに分かりやすく記述したか？

4. 重要確認項目

4.1. トレーサビリティの確保

  • コード内のコメントやテストのアトリビュートに、対応する機能ID（例: FUNC-AUTH-1-0）は正しく記載されていますか？

4.2. 言語固有のチェックリスト

上記の共通観点に加え、対象となる言語のコーディング規約に基づき、以下の重点項目をチェックしてください。

  • C#:

    • 規約: 01.CSharp規約
    • 重点チェック項目:
      • async/awaitの不適切な使用（async void, .Resultなど）はないか？
      • recordやinitアクセサを活用し、不変性が保たれているか？
      • #nullable enableの規約に沿っているか？
      • LINQは効率的に使われているか？（例: Count() > 0ではなくAny()を使う）

  • Python:

    • 規約: 02.Python規約
    • 重点チェック項目:
      • 全ての関数で、モダンな型ヒントは正しく付与されているか？
      • リソース管理にwith文は使われているか？
      • イミュータブルなデータ構造（tuple, @dataclass(frozen=True)）は適切に活用されているか？

  • C/C++:

    • 規約: 03.C規約 / 04.Cpp規約
    • 重点チェック項目:
      • [C++]: RAIIは徹底され、スマートポインタ（std::unique_ptrなど）は正しく使われているか？手動のnew/deleteはないか？
      • [C/C++]: constは積極的に活用されているか？
      • [C]: strcpyのような危険な関数は使われていないか？エラー処理（errnoのリセットなど）は適切か？

  • Web (TypeScript/JavaScript/Node.js):

    • 規約: Web開発規約
    • 重点チェック項目:
      • [TS]: any型は使われていないか？unknown型と型ガードが適切に使われているか？
      • [JS/TS]: varは使われていないか？constが基本になっているか？
      • [Node.js]: 同期的なI/O APIを不適切に使って、イベントループをブロックしていないか？エラーハンドリングは操作エラーとプログラマーエラーを区別しているか？

5. フィードバックの心構え

  • 具体的かつ建設的に: 単に "規約違反です" ではなく、「なぜそれが問題なのか」「どのように修正すべきか」を、コード例を交えて具体的に提案してください。
  • 敬意をもって: レビュアーはチームの一員です。相手を尊重し、ポジティブで協力的なトーンでフィードバックを行ってください。
  • 意図を尋ねる: 理解できないコードがあれば、一方的に修正を求めるのではなく、「この部分の実装意図を教えていただけますか？」のように質問から始めましょう。