「レガシーコード改善ガイド」のススメ
第3回：既存のコードに極力手を加えずに機能を追加する

邦訳版『Working Effectively With Legacy Code』の重要トピックを紹介

　このシリーズでは7月に刊行される翻訳書「レガシーコード改善ガイド（Working Effectively With Legacy Code）」に書かれている内容から、重要なトピックを取り上げて紹介していきます。今回は、この本で紹介されている数多くの手法のなかから、スプラウトクラスという手法を紹介します。

テストで保護することができない場合

　レガシーコードに手を加える場合、テストで保護することが何よりも大切であることは、これまでの連載で説明してきました。ですが、レガシーコードにテストを用意することはなかなか大変なことも事実です。

　テストを用意するためには、テスト対象となるクラスのインスタンスを作らなければなりませんが、依存関係が複雑だったり、コンストラクタの引数にたくさんの別のインスタンスが必要だったりすると、とたんに困難な作業になります。

　そのようなクラスに機能を追加しなければならなくなったとしたらどうすればよいでしょうか？ 十分に時間があれば、対象とするコードに対してリファクタリングを行い、テストを準備してから取り掛かりたいところです。しかし、機能追加の規模が小さいと、大規模なリファクタリングをする時間などありません。だからといって、テストで保護せずに作業してしまうことはレガシーコード状態を続けることになります。

　このような状況はよくあるのではないでしょうか。

「テストを用意した方が良いことはよくわかっているけど、
　実際にはそんな時間はないんだよね……」

　『レガシーコード改善ガイド』では、このような現実に対して、いくつかの対処手法が紹介されています。理想論だけが語られる書籍が多いなかで、とても珍しいことです。今回は、この本で紹介されている数多くの手法のなかから、スプラウトクラスという手法を紹介します。