dev-principles

開発原則リファレンス

コードの品質・可読性・拡張性を向上させるための原則。実装・レビュー・設計判断時にこれらを適用すること。

SOLID原則

S - Single Responsibility Principle（単一責任原則）

クラスやモジュールは単一の責任のみを持つべき。

• 1つのクラス/関数 = 1つの責任
• 変更理由が複数あるなら分割を検討する
• 変更時の影響範囲が限定され、バグの波及効果を最小化できる

O - Open-Closed Principle（開放/閉鎖原則）

拡張に対して開放、変更に対して閉鎖されるべき。

• 既存コードを変更せずに新機能を追加できる設計にする
• インターフェースや抽象クラスを活用する
• 既存クラスの利用箇所でのバグ発生を防止できる

L - Liskov Substitution Principle（リスコフの置換原則）

親クラスのインスタンスは子クラスで置換可能であるべき。

• 子クラスは親クラスの契約（振る舞い）を守る
• 子クラスが同等の結果を提供することで一貫性を維持する
• 置換しても既存の動作が壊れないことを保証する

I - Interface Segregation Principle（インターフェース分離の原則）

クライアントは自身が使用しないメソッドに依存すべきでない。

• 大きなインターフェースを小さく特化したものに分割する
• 不要なメソッドへの依存を排除し、予期しないバグを回避する
• クライアントが必要なメソッドのみを実装すればよい設計にする

D - Dependency Inversion Principle（依存性逆転の原則）

上位モジュールは下位モジュールに依存すべきでない。両方とも抽象に依存すべき。

• 具象クラスではなくインターフェース/抽象に依存する
• 上位レベルと下位レベル間の結合度を低減する
• テスタビリティと差し替え容易性が向上する

KISS原則（Keep It Simple, Stupid）

コードはできるだけシンプルにすべき。

• 「動作に必要な最もシンプルな実装は何か？」と常に問いかける
• 複雑なコードはバグを引き起こしやすく保守が困難
• 過度な抽象化・汎用化を避ける
• 読み手が理解しやすいコードを書く

YAGNI原則（You Aren't Gonna Need It）

今必要なコードのみ追加すべき。

• 将来必要になるかもしれない機能を事前に実装しない
• 事前の備えは余計な複雑性をもたらす
• 汎用性より単純性を優先し、現在必要な機能のみ実装する
• 必要になったときに実装すればよい

DRY原則（Don't Repeat Yourself）

同じコードの重複を避けるべき。

• 重複コードはコード量の増加、修正時間の増加、理解の困難さを招く
• 処理のまとまりを関数・メソッドとして抽出する
• ただし、過度なDRYは避ける（文脈が異なる類似コードは無理に共通化しない）
• 3回以上の重複が発生したら共通化を検討する（Rule of Three）