「レガシーコード改善ガイド」のススメ 第2回：コードを理解するため、仕様化テストで文書化する
増え続けるレガシーコード この記事を読んでいる皆さんの多くは、これまでたくさんのシステム開発に関わってきたことでしょう。仕様変更と闘い、納期に追われ、やっとのことで稼働したシステムも数多いはずです。厳しい状況になればなるほど、実際にコードを動かすことが最優先になり、「コードを保護する」ための単体テストの整備は後回しになってしまいがちです。 ところが、システム開発はシステムが完成して無事に稼働した時点で終わりではありません。ユーザーが実際に使い始めると、保守開発としてさまざまな仕様変更や機能追加が発生するのが常です。それらに対応するためには、厳しいスケジュールの中で、やっつけ仕事で間に合わせたコードに対して改修や機能追加をする必要があります。では、このような仕事にどうやって取り組めば良いのでしょうか？ さて、前回の記事では、『レガシーコード改善ガイド』におけるレガシーコードの定義を紹介しまし
Martin Fowler's Bliki in Japanese - リファクタリングの誤用
http://martinfowler.com/bliki/RefactoringMalapropism.html かつて、わずかな人しか知らなかった用語「リファクタリング」は、 今ではコンピュータ業界の中でフラフラ迷走している。 これは私にも責任がある。 私はプログラマたちの生活の向上と、ビジネスに利益をもたらせたいと願っている （重要なことだが、私はリファクタリングの父でもないし、発明者でもない。ただの執筆者である） …… ……のだが、リファクタリングは、適切に使われてはいない。 リファクタリング中に2,3日システムが動かなくなっちゃってーなどと言ってる奴がいたら、 んなもんリファクタリングじゃあなーいと言ってやれ。 ドキュメントをリファクタリングしちゃるとか言ってる奴、 それもリファクタリングじゃねーぞコラ。 そういうのは、リストラクチャリング（再構築）というのだッ。 「リファクタリ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Refactorings - FrontPage : リファクタリング・カタログ
