[記事紹介] CodeZine ～ レガシーコードの定義、テストの重要性とは

この連載記事では、 書籍 「レガシーコード改善ガイド」 ( 2009/7/14 発刊予定) に書かれている内容から、 重要なトピックを取り上げて紹介してくださるとのことです。 第1回目は、 ユニットテストの重要性について。

CodeZine: 翻訳書 「レガシーコード改善ガイド」 の注目トピック
「レガシーコード改善ガイド」のススメ
第1回： レガシーコードの定義、 テストの重要性とは
邦訳版 『Working Effectively With Legacy Code』 の重要トピックを紹介
小堀 真義 [著] 2009/07/03 14:01

この記事 (そして、 「レガシーコード改善ガイド」 ) では、 自動実行できるユニットテストが無いコードをレガシー ( 遺産・遺物、 ここでは 「負の遺産」 という悪い意味 ) であると断定しています。

さて、 この書籍では 「レガシーコード」 を次のように定義しています。

レガシーコードとは、単にテストのないコードである

著者は上記のように定義した理由を、 次のように説明しています。

テストのないコードは悪いコードである。 どれだけうまく書かれているかは関係ない。 どれだけ美しいか、 オブジェクト指向か、 きちんとカプセル化されているかは関係ない。 テストがあれば、 検証しながらコードの動きを素早く変更できる。 テストがなければ、 コードが良くなっているのか悪くなっているのかが本当には分からない。

これを見て 「きれいな設計やコードなら、 変更は簡単なのでは？ 」 と感じる方がいるかもしれません。 設計やコードをきれいにすることは重要ですし、 そのための技術書もたくさん書かれています。 ですが、 それだけでは不十分なのです。

いくらきれいに作られたコードでも、 ユニットテストが付いていなければ、 メンテナンスを通して悪化していき、 確実に 「負の遺産」 になっていってしまう。 だから、 悪いコードなのだ、 ということでしょうね。

(2010/1/12 追記)
第2回以降へのリンクを載せておきます。
・第2回: コードを理解するため、 仕様化テストで文書化する
・第3回: 既存のコードに極力手を加えずに機能を追加する
・第4回: 既存のコードに極力手を加えずにテストで保護する
・第5回: レガシーコードを攻略するための原則とプラクティス