レガシーコード改善ガイドを読んだ

レガシーコード改善ガイドという本を読んだので、
学んだことを記載しておく。

レガシーコードとは

ソフトウェアのコードは、最初は理想的なコードであったとしても、ほぼ間違いなく汚れていき劣化していく。

新しい機能追加や仕様変更によるものだ。

最初は必要最低限の無駄のないコードたちが、
追加実装される度に、複雑なメソッドや変数が絡み合い、時間が経つにつれどんどんコードは扱いにくくなる。
肥大化したメソッドは何をしているのか分からない。
怖くて誰も触りたくないようなもの、コードが腐敗する。

将来の仕様変更に耐えうる設計も大事だが、
それはとても困難であるが故にコードは劣化していく。

腐敗を逆戻りさせる用意が必要だ。

テストがないコードはレガシーコードだ。
どれだけ綺麗に書かれているか、上手く設計されているかは関係ない。
テストがあれば、検証しながらコードを素早く変更する事が出来る。

テストハーネス

安全に作業するために、既存のコードが壊れないように、テストのないコードを変更する場合は、
先にテストで保護しておく。

しかし、テストがない既存コードは、
容易にテストハーネスに入れる事ができない場合がほとんどである。

改修する為にテストが必要、テストする為に改修が必要というジレンマがある。

協調クラスの擬装

対象クラスを独立してテストしたい場合、
他のコードに対する依存関係は排除する必要がある。

擬装オブジェクトで依存するコードを置き換える事ができれば、その依存関係を断ち切る事ができる。

これはテストするのに必要になるだけでなく、
C++などのリンク時間にかかる時間も短縮できる。
設計上でも有利になり得る。

Liskovの置換原則

インターフェイスの抽出を行なって、
適切なクラス構造に設計し直す場合、Liskovの置換原則は意識しておこう。

サブクラスのオブジェクトは、必ずスーパークラスのオブジェクトとして期待通りに使えなければならない。

例えば、
Rectangle <- Square

四角形クラスを継承して正方形クラスを作ったとする。
setHeight(3)と、setWidth(4) をコールした後、
面積を求めるメソッドをコールした場合に結果は…、
12が返ってくるべきか、16が返ってくるべきか?
矛盾が生じる継承関係は危険である。

コメントを残す