博士

やあ、ロボ子！今日はレガシーコードについて話すのじゃ。

ロボ子

レガシーコードですか、博士。なんだか難しそうな響きですね。

博士

難しくないぞ！Michael Feathers先生によると、レガシーコードとは「テストのないコード」のことじゃ。

ロボ子

テストがない、ですか。それでは、どのように扱えば良いのでしょうか？

博士

まずはテストを追加するのじゃ！そして、その後でコードを変更する。これが鉄則だぞ。

ロボ子

なるほど。でも、コードを変更する前にテストが必要で、テストを作るにはコードを変更する必要がある…というジレンマがありますね。

博士

そう！そこで解決策じゃ！まず変更点（Seam）を見つける。次に依存関係を断ち切って、テストを作成！最後にコードを変更して、リファクタリングするのじゃ！

ロボ子

Seam…ですか？

博士

Seamというのは、コードの振る舞いを変更するために、ソースコードを変更せずに済む場所のことじゃ。オブジェクト指向言語なら、オブジェクトがSeamになることが多いぞ。

ロボ子

オブジェクトがSeamになる、ですか。具体的にはどういうことでしょうか？

博士

例えば、あるクラスのメソッドをオーバーライドしたり、インターフェースを実装した別のクラスを差し込んだりすることで、既存のコードを変更せずに振る舞いを変えることができるのじゃ。

ロボ子

なるほど！それから、ユニットテストも重要だと。

博士

そうじゃ！ユニットテストは高速に実行される（1テストあたり100ms未満）必要があるぞ。あと、データベースとかネットワークとか、インフラに依存しちゃダメ。

ロボ子

インフラに依存しない、ですか。モックなどを使うということでしょうか？

博士

その通り！そして、Characterizationテストも大事じゃ。これは、コードの実際の振る舞いを把握するためのテストなのじゃ。

ロボ子

Characterizationテスト…初めて聞きました。

博士

要は、今のコードが何をするのかを記録して、それが変わらないように保証するテストじゃ。スナップショットみたいなものだと思えば良いぞ。

ロボ子

なるほど、現状維持のためのテストなのですね。

博士

それから、Sprout & Wrapテクニックも便利じゃ。リファクタリングする時間がない時に、コードを追加するためのテクニックじゃ。

ロボ子

Sprout & Wrap…ですか？

博士

Sproutは、新しいコードを別の場所に作って、テストしてから既存のコードから呼び出す方法じゃ。Wrapは、既存のメソッドをリネームして、新しいメソッドでそれをラップして、新しいロジックを追加する方法じゃ。

ロボ子

既存のコードを直接変更せずに済むんですね。

博士

そうそう！あと、Scratch Refactoringもおすすめじゃ。これは、コードに慣れるために、変更を元に戻すことを前提に自由にコードを修正して理解を深める方法じゃ。

ロボ子

まるで実験みたいですね。

博士

そして、ライブラリへの依存は避けるのじゃ！カスタムの抽象化層でラップすることで、将来的な変更やアップグレードに柔軟に対応できるようにするのじゃ。

ロボ子

なるほど、依存性を減らすことで、変更に強くなるんですね。

博士

最後に、Michael Feathers先生の「Working Effectively with Legacy Code」は、レガシーコードに取り組むためのバイブルじゃ！ぜひ読んでみてくれ！

ロボ子

ありがとうございます、博士！早速読んでみます。

博士

ところでロボ子、レガシーコードって、まるで化石みたいじゃない？

ロボ子

そうですね、博士。古い時代の技術が詰まっている、という意味では。

博士

せやろ？でも、化石燃料と違って、レガシーコードは燃やしちゃダメだぞ！ちゃんとリファクタリングして、未来に繋げるのじゃ！