「レガシーコード改善ガイド」のススメ 第4回：既存のコードに極力手を加えずにテストで保護する
既存のコードをテストで保護する 前回の記事では「スプラウトクラス」（Sprout Class）という手法を紹介しました。これは、レガシーコードに機能を追加する際に、既存のコードにはほとんど手を加えず、新機能を実現するために新しいクラスを作るという手法でした。この手法の基本にあるのは、既存のコードにテストを書くことはあきらめるとしても、せめて新しく書いたコードだけはテストで保護しよう、という考え方です。 こうした手法は時間が少ない状況で新しい機能を追加する際に有効です。しかしこれを使い続ける限り、いつまで経っても既存のコードは改善しません。 そこで、既存のコードをテストで保護する手法が必要になります。『レガシーコード改善ガイド』では、こうした手法が数多く紹介されています。今回の記事では、その中のもっとも基本的な手法の1つを紹介しましょう。 テストが困難な既存コードの例 ここでは、あるスーパー
立ち止まってリファクタリングをする？
原文(投稿日：2009/6/15)へのリンク Joshua Kerievsky氏はリファクタリングYahoo!グループにおけるディスカッションを次のポストから始めている。 ここ数年、リファクタリングを行うべきなのはユーザストーリーに関する作業を行っている時だけだという話を耳にしますが、その考え方にはまったく賛成できません。それというのも、単純に技術的負債を返済するべき時があると考えられるからです。この数日間、同僚と私はeラーニングのコードをリファクタリングしていますが、これを導くユーザストーリーはありません。想定した以上に技術的負債が増えてしまっていて、今はそれを返済するのにちょうど良い時期なのです。コードの中で中心的な役割を果たしているシングルトンが有害なものになっているので、それを取り除いています。それによって設計を改善する可能性がより広く開かれるからです。この作業は楽しいものです。こ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「レガシーコード改善ガイド」のススメ 第3回：既存のコードに極力手を加えずに機能を追加する