SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

翻訳書「レガシーコード改善ガイド」の注目トピック

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

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

  • X ポスト
  • このエントリーをはてなブックマークに追加

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

  • X ポスト
  • このエントリーをはてなブックマークに追加

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

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

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

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

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

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

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

会員登録無料すると、続きをお読みいただけます

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

次のページ
スプラウトクラスとは

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
翻訳書「レガシーコード改善ガイド」の注目トピック連載記事一覧

もっと読む

この記事の著者

小堀 真義(コボリ マサヨシ)

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

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/4151 2009/07/17 14:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング