レガシーコードからの脱却まとめ – 13.6 – 13.8

13.6 オープン・クローズドにリファクタリングする

SOLID原則のOこと、オープン・クローズドの原則では、ソフトウェアは「拡張に対して開かれているが変更に対して閉じられている」べきだとしている。
こうすると、新しい機能の追加は、新しいコードの追加と最小限の既存コード変更で済むようにする。

変更を加える際は常に2段階のプロセスで進める。

まず新しい機能に対応できるように、拡張したいコードをリファクタリングする。この時点ではまだ新しい機能は追加しない。
リファクタリング中の間違いはテストが教えてくれる。
次に機能拡張ステップに入り、テストファーストでレッド・グリーン・リファクタリングを繰り返す。

この手順を混同して進めると混乱して間違えやすい。

コードの変更しやすさを担保することは、正しい抽象化を見つけ、コードが適切にカプセル化されていることを意味する。

つまり、正しい抽象化とはなにかを理解し、それを見つけていき、カプセル化を理解し、カプセル化をしていくことが重要だ。

最終的に重要なのは「自分がモデル化しているものを理解してモデルへ組み込む」ことで、これが正確性と一貫性をもたらす。

プラクティスやTDDは、自分がやろうとしていることを明確にするためのサポートはしてくれるが、自分がやろうとしてくれることそのものをすべて生み出してくれるわけではない。

コードの変更しやすさが偶然生まれることはない。

正しい抽象化は、複数のふるまい・具体的な例を挙げることで、何が同じで何が違うかが浮かび上がり、そこから汎化することで見つけられる。

この作業は、具体例が多いほど精度が高くなり少なければ精度が低くなる可能性があることを意味する。プロジェクトが進むにつれて、具体例は見えてくる傾向にある。
つまり、プロジェクト初期は精度の高い適切な設計が難しいことを意味している。

ソフトウェアの「柔らかい」特性を理解して、いつでもリファクタリングできるようにしておくことで、プロジェクトを進めながら設計の精度を上げることができる。