鎌ヶ迫ブログ

前職の頃から一部マニアの間ではXPエクストリーム・プログラミング[W]の信奉者として有名だった不肖鎌ヶ迫です(一部誇張あり)が、その一部については今でも実践しております。

昨日今日と、現在手掛けているプロジェクトのサーバサイドJavaアプリのカスタマイズを行っておりました。既存のコードを流用しようと思えば流用できたのですが、ドメインが微妙に分かれている上に今後もカスタマイズが発生する可能性があり、下手に継承して後々困るのも面倒なので、インタフェースを揃えてパッケージからして別に実装することにしました。

コピペは諸悪の根源、継承関係が成り立たないのであればきっちり実装です(staticなロジックのみのクラス? 何のこと?)。と、その前にテストクラスを実装します。はい、テスト・ファーストですね。テストに合わせてクラスを実装するという、ある意味では矛盾しているような、しかし実に理に適った実装方法です。

「クラスを実装できる ← インタフェースが決まっているハズ ← テストを書けるはず」「テストを書けない → インタフェースが決まっていない → まだ実装すべきでない」というシンプルな理屈です。クラスに修正が必要な場合は、当然、テストを修正するのが先です。これを徹底することで、単体レベルのバグ数をかなり抑え込むことができます。

問題は、テストクラスを実装しない場合に比べて見掛けの実装が増えることです。ただ、デバッグと仕様変更の対応、メンテの手間を考えると、テスト・ファーストをしっかり実践した方が工数が減ると経験的に言えます。この点を定量的に示すことができれば、導入の敷居は下がることと思います。