レビュアースキルガイド

コードレビューで設計判断の質を高める：SOLID原則とモジュール構造の見極め

Tags: コードレビュー, 設計原則, SOLID, モジュール構造, 保守性, 拡張性, ソフトウェア設計

コードレビューで設計判断の質を高める：SOLID原則とモジュール構造の見極め

日々の開発業務において、コードレビューは欠かせないプロセスです。しかし、単にコードの誤りやバグの指摘に留まらず、よりコードベースの健全性を保つためには、設計観点からのレビューが重要になります。ある程度の開発経験をお持ちの皆様の中には、「このコードは意図通り動くが、設計として本当にこれで良いのだろうか」「将来的な変更に強い構造になっているか判断が難しい」といった課題を感じている方もいらっしゃるかもしれません。

本記事では、コードレビューにおいて設計判断の質を高めるために、設計原則の基本であるSOLID原則と、コードの構造を捉えるモジュール構造の見極めに焦点を当てて解説します。これらの観点を取り入れることで、コードの保守性、拡張性、理解容易性を向上させるためのレビューが可能になります。

なぜコードレビューで設計観点が重要なのか

コードレビューの主な目的は、バグの発見、コード品質の向上、知識共有など多岐にわたります。その中でも設計観点のレビューは、コードが「どのように動くか」だけでなく、「どのように構成されているか」に着目します。

これらの理由から、表面的な指摘だけでなく、設計の意図や構造にまで踏み込んだレビューは、中長期的なプロジェクトの成功に不可欠と言えます。

SOLID原則からコードを診断する

SOLID原則は、オブジェクト指向設計における5つの基本的な原則の頭文字をとったものです。これらの原則は、変更に強く、理解しやすく、再利用可能なソフトウェアを作るための指針となります。コードレビューにおいて、これらの原則が守られているかを確認することは、設計の健全性を判断する上で有効です。

1. 単一責任の原則 (Single Responsibility Principle: SRP)

クラスやモジュールは、ただ一つの責任を持つべきである、という原則です。ここでいう「責任」とは、変更の理由となり得る一つの機能や役割を指します。

レビューの観点:

コード例（概念）:

// SRP違反の可能性
class UserProfileManager {
    void loadUser(int userId) { ... } // ユーザーデータ取得
    void saveUser(User user) { ... }   // ユーザーデータ保存
    void displayUser(User user) { ... } // ユーザー情報表示（UI関連）
    void sendWelcomeEmail(User user) { ... } // メール送信
}

// SRPに沿った分割の例
class UserRepository { // ユーザーデータの永続化
    User findById(int userId) { ... }
    void save(User user) { ... }
}

class UserPresenter { // ユーザー情報の表示（UIロジック）
    void display(User user) { ... }
}

class EmailService { // メール送信
    void sendWelcomeEmail(User user) { ... }
}

UserProfileManagerはデータ永続化、UI表示、メール送信という複数の責任を持つ可能性があります。これをUserRepository、UserPresenter、EmailServiceのように分割することで、それぞれのクラスは特定の責任に集中し、変更が発生しても他のクラスへの影響を最小限に抑えられます。レビューでは、このような責務の混在がないかを確認します。

2. オープン・クローズドの原則 (Open/Closed Principle: OCP)

ソフトウェアの構成要素（クラス、モジュール、関数など）は、拡張に対して開いており、修正に対して閉じているべきである、という原則です。これは、新しい機能を追加する際に、既存のコードを変更せずに済むように設計すべきであることを意味します。

レビューの観点:

コード例（概念）:

// OCP違反の可能性
class DiscountCalculator {
    double calculate(double amount, String customerType) {
        if (customerType.equals("Regular")) {
            return amount * 0.9;
        } else if (customerType.equals("Premium")) {
            return amount * 0.8;
        }
        return amount;
    }
}

// OCPに沿った設計の例
interface DiscountPolicy {
    double calculate(double amount);
}

class RegularDiscountPolicy implements DiscountPolicy {
    double calculate(double amount) { return amount * 0.9; }
}

class PremiumDiscountPolicy implements DiscountPolicy {
    double calculate(double amount) { return amount * 0.8; }
}

class DiscountCalculator { // Policyを受け取る
    double calculate(double amount, DiscountPolicy policy) {
        return policy.calculate(amount);
    }
}

OCP違反の例では、新しい顧客タイプ（例: VIP）に対応するためにDiscountCalculatorクラスそのものを変更する必要があります。OCPに沿った例では、DiscountPolicyインターフェースを実装した新しいクラス（VipDiscountPolicyなど）を追加するだけで済み、既存のDiscountCalculatorクラスを変更する必要がありません。レビューでは、将来の拡張が既存コードの変更を伴わないような抽象化やポリモーフィズムが考慮されているかを確認します。

3. リスコフの置換原則 (Liskov Substitution Principle: LSP)

派生型は基底型と置換可能でなければならない、という原則です。これは、あるクラスのオブジェクトを使用している箇所で、そのクラスのサブクラスのオブジェクトを使用しても、プログラムの正当性が損なわれてはならないことを意味します。

レビューの観点:

この原則は、特に複雑な継承関係を持つコードで重要になります。レビューでは、継承が単なるコードの再利用のためだけでなく、is-a関係（「〇〇は△△の一種である」という関係性）を正しく表現しており、サブクラスが親クラスの契約（振る舞いに関する期待）を破っていないかを確認します。

4. インターフェース分離の原則 (Interface Segregation Principle: ISP)

クライアントは、自分が使用しないインターフェースに依存すべきではない、という原則です。これは、大きすぎるインターフェースを、より小さく特定のクライアントに特化したインターフェースに分割すべきであることを意味します。

レビューの観点:

コード例（概念）:

// ISP違反の可能性
interface Worker {
    void work();
    void eat();
    void sleep();
    void manage(); // マネージャーだけが必要
}

class Employee implements Worker {
    void work() { ... }
    void eat() { ... }
    void sleep() { ... }
    void manage() { /* 何もしないか例外 */ } // 不要なメソッド
}

class Manager implements Worker {
    void work() { ... } // 必要ないかもしれない
    void eat() { ... }
    void sleep() { ... }
    void manage() { ... }
}

// ISPに沿った分割の例
interface Workable {
    void work();
}

interface Feedable {
    void eat();
    void sleep();
}

interface Manageable {
    void manage();
}

class Employee implements Workable, Feedable {
    void work() { ... }
    void eat() { ... }
    void sleep() { ... }
}

class Manager implements Workable, Feedable, Manageable { // あるいはManageableのみ
    void work() { ... }
    void eat() { ... }
    void sleep() { ... }
    void manage() { ... }
}

ISP違反の例では、EmployeeやManagerはWorkerインターフェースの全てのメソッドを必要としない可能性があります。ISPに沿った例のように、インターフェースを細かく分割することで、クライアント（これらのインターフェースを使用するクラス）は自身が必要とする機能だけを持つインターフェースに依存することができます。レビューでは、肥大化したインターフェースがないか、クライアントが不要な依存を強いられていないかを確認します。

5. 依存関係逆転の原則 (Dependency Inversion Principle: DIP)

  1. 上位レベルのモジュールは下位レベルのモジュールに依存すべきではない。両方とも抽象に依存すべきである。
  2. 抽象は実装の詳細に依存すべきではない。実装の詳細が抽象に依存すべきである。

この原則は、特定の具象クラスへの直接的な依存を避け、抽象（インターフェースや抽象クラス）に依存することを推奨します。これにより、上位モジュールと下位モジュールの間の結合度を下げ、変更に強い設計を実現します。

レビューの観点:

コード例（概念）:

// DIP違反の可能性
class UserService { // 上位モジュール
    private MySqlDatabase db = new MySqlDatabase(); // 具象クラスへの直接依存

    void saveUser(User user) {
        db.save(user);
    }
}

class MySqlDatabase { // 下位モジュール
    void save(User user) { /* MySQLへの保存処理 */ }
}

// DIPに沿った設計の例
interface Database { // 抽象
    void save(User user);
}

class MySqlDatabase implements Database { // 下位モジュールの具象実装
    void save(User user) { /* MySQLへの保存処理 */ }
}

class OracleDatabase implements Database { // 別の下位モジュールの具象実装
    void save(User user) { /* Oracleへの保存処理 */ }
}


class UserService { // 上位モジュール
    private final Database db; // 抽象への依存

    // コンストラクタインジェクション
    UserService(Database db) {
        this.db = db;
    }

    void saveUser(User user) {
        db.save(user);
    }
}

DIP違反の例では、UserServiceが具体的なMySqlDatabaseクラスに直接依存しています。データベースをOracleに変更する場合、UserServiceのコードを修正する必要があります。DIPに沿った例では、UserServiceはDatabaseという抽象に依存しているため、具体的なデータベース実装を変更してもUserServiceのコードは変更する必要がありません。レビューでは、クラス間の依存関係が抽象化されているか、具体的な実装への直接依存がないかを確認します。

モジュール構造のレビュー

コードベース全体や特定の機能単位におけるモジュール（パッケージ、ディレクトリ、サブシステムなど）の構造も、レビューの重要な観点です。良いモジュール構造は、コードの整理、再利用性、変更時の影響範囲の限定に貢献します。

レビューの観点:

具体的なチェックポイントの例:

レビューの際は、ファイルやディレクトリの構成図、クラス図などを補助的に利用することも有効です。プルリクエストに含まれるファイル構成の変化から、モジュール構造への影響を読み取るようにします。

実践的な設計観点レビューのアプローチ

設計観点のレビューは、単に原則を知っているだけでは難しい場合があります。以下に実践的なアプローチをいくつかご紹介します。

自身のレビュアースキルを向上させるために

設計観点を含む質の高いコードレビューを行うためには、レビュアー自身のスキルアップが不可欠です。

まとめ

本記事では、コードレビューの質を高めるために、設計原則（SOLID）とモジュール構造の見極め方について解説しました。

コードレビューに設計観点を取り入れることは、最初は難しく感じるかもしれませんが、経験を積むことで徐々に見極める力が養われます。ぜひ、日々のレビューの中でこれらの観点を意識して取り組んでみてください。チーム全体のコード品質向上に繋がり、結果として開発効率の向上にも貢献できるはずです。