小堀 真義 [著] 2009/07/17 14:00

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

1 2 →

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

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

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

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

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

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

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


1 2
→
INDEX
「レガシーコード改善ガイド」のススメ 第3回:既存のコードに極力手を加えずに機能を追加する
Page1
テストで保護することができない場合
スプラウトクラスとは
レガシーコードでは、「悪化させない」ことだけでも重要なこと
プロフィール
小堀 真義 コボリ マサヨシ

ウルシステムズ株式会社 シニアコンサルタント

Webアプリケーションやセキュリティ基盤の開発を経験し、2006年より現職。 技術的な支援を本業としつつ、ときにはプロジェクト管理まで踏み込みながら、 システム開発をサポートする毎日を過ごしている。本連載で紹介する「レガシーコード改善ガイド」の翻訳に参加した。


記事へのコメント・トラックバック機能は2011年6月に廃止させていただきました。記事に対する反響はTwitterやFacebook、ソーシャルブックマークサービスのコメントなどでぜひお寄せください。

スポンサーサイト