【読書記録】アジャイルソフトウェア開発の奥義(4) ソフトウェアを腐敗させないためのSOLID原則 S
引き続きボブおじさんの名著を読み直している。
第7章 アジャイル設計とは？
ソフトウェアの仕様は常に代わり続けるもので、仕様変更に耐えられず設計が劣化していくなら、それは自分たちの設計やプラクティスに問題があるのだとボブおじさんは言う。
ソフトウェアが腐敗し始めた兆候として以下の7つが挙げられている。
- 硬さ
- もろさ
- 移植性のなさ
- 扱いにくさ
- 不必要な複雑さ
- 不必要な繰り返し
- 不透明さ
ソフトウェアの腐敗を防ぐために、アジャイル開発者はクリーンな設計を保つ努力をしなければならない。「アジャイルな設計とは何か？」について以下のように締めくくられている。
アジャイルな設計とは「プロセス（流れ）」や「イベント（事象）」ではない。ソフトウェアの構造や可読性を向上させるために、原則、パターン、そして、プラクティスを継続的に適用する行為である。またそれは、システムの設計を可能な限り、シンプル、クリーン、かつ、わかりやすく保つための献身的な行為である。
（第7章、p.118）
ではその設計の原則とは？
ということで、8章以降SOLID原則の説明がなされる。
第8章 単一責任の原則（SRP: Single Responsibility Principle）
クラスを変更する理由は1つ以上存在してはならない。
この原則は、クラスに複数の役割を持たせるなと言っている。「役割（責任）＝変更理由」として定義されている。何かの仕様変更が発生してクラスを修正する際にそのクラスが複数の役割を持っているとすると、それらの役割（責任）を果たすための実装が入り混じっているため思いもよらない形でコードを壊してしまうリスクがある。このようなソフトウェアは「もろい」設計である。
しかし、役割を分離するという作業は案外難しい。役割分担を一発で行えない、あるいは行ってみたが誤っていたという場合も多い。テスト駆動開発のアプローチによって、リファクタリングをしながら適切な形へ持っていく必要がある。
単一責任の原則（SRP）は最もシンプルな原則のひとつであるが、正しく適用することが最も難しい原則の1つでもある。我々はともすれば複数の役割を結合してしまいがちなのだ。結合している役割を見つけそれらを分離する作業は、ソフトウェア設計の本質である。
（第8章、p.125）
つづく。