XPプログラミングの考察その1 - テスト自動化

XP プログラミングという有名なソフトウェア開発手法があります。有名すぎて今更感もありますが、この XP について考えていきたいと思います。
ただし、 XUnit と呼ばれるテスティングフレームワークについてはいろいろ調べたことはあるのですが、 XP 自体については Wikipedia などのネットの拾い読み程度の知識しかないので、それを私なりに解釈したものです。

XP にとって大事なことは何かというと如何に変更に強く開発していけるかということです。
そのための重要なポイントは次の 2 つだと思います。

テスト自動化
ソースコード重視

テスト自動化

XP のテストといえばテストファーストといった感じですが、個人的にはテストが前か後かというのはたいした問題ではないと思います。 XP の最大のポイントはテスティングと呼ばれるテストの自動化にあります。

ただ、テストファーストも悪いとは思っていません。私も Redmine というバグトラッキングシステムを使っているとき、いっぱい上がっているバグのチケットをひとつづつ修正していくのが結構楽しいときもあるので、テストエラーを一つづつ潰して行くクリア的な楽しさは確かにあると思います。

しかし、やはり大事なのはテストの自動化で XP の多くのプラクティスはテストの自動化に支えられています。

リファクタリング

これはちゃんと動作しているコードでもだめなコードならどんどん修正していこうということです。これは一見あたりまえのようですが、テストの自動化ができていないと出来ません。
プログラマはこのコードひどいなと思っても、一応動いているのであれば普通、なるべく手を出しません。コード修正用の工数などまずもらえませんし、下手にいじって動かなくなっては困ります。そこで汚いものにはフタをすることにします。これは汚ければ汚いほどその傾向になります。
そこに勇気を与えてくれるのがテストの自動化です。
ただまぁ、次回説明するつもりですが、単体テストを入れている時点でそこまでおぞましいコードはできていないとは思います。

ソースコードの共同所有

誰が作ったソースコードでも、開発チーム全員が修正できるということです。これもテストの自動化がなければ、人のコードなど怖くて触れません。

継続的インテグレーション(CI)

ビルドとテストをサーバーなどで定期的に行うことです。これはテスト自動化に支えれられているというよりもテスティングにおける"頻繁にテストを行う"というところをシステム的に実現させるものです。

YAGNI(今必要なことだけ行う)

必要な機能だけを実装するということです。これは余計なものを作らないことで早く作っていこうという考え方ですが、テスト自動化をしていない場合、逆に時間がかかってしまうことがあります。
というのも、機能を一つ追加した場合、その機能のテストだけでなく、その機能追加の修正によって他の機能に影響がないかをチェックする回帰テストが必要になってくるためです。テストに時間がかかる場合は機能を一度に追加して通しでテストを行った方がトータルの工数が減るわけです。
テスト自動化をしていればテストもすぐ終わるので、今求められているものだけを作ることができるようになります。これにより 短期リリースも実現可能です。

XP は変更に強くすることが重要であり、また、変更に強くなっているということを基にした開発手法でもあります。そのため、変更に強くなっていなければ、 XP は破綻します。これがよく分かるのが、この YAGNI でしょう。

ただし、今必要なことに最適化してコーディングするということではないことに注意してください。
必要のない機能は実装しませんが、将来起こるであろう修正に対して柔軟に対応できるようにしておくということは重要です。これは次のポイントである良質のコードを書くということでもあります。

XP の部分的導入というのはよく耳にします。 XP の完全導入はハードルが高すぎて私もできるなんて思ったことは一度もないので、それが当たり前だと思います。ただし、そこで真っ先に導入すべきはテストの自動化です。テスト自動化の導入は大変なので、抜きでやろうということがあるかもしれません。しかし、 XP のほとんどのプラクティスはテストの自動化なしには実行出来ませんし、無理にやったとしても破綻します。
確かにテストの自動化、ユニットテストのコードの記述は面倒です。市販のテスト自動化ツールなどもありますが、それでも軽減されるだけで手間は手間です。しかし、それを超えてこそ XP の恩恵がでてくるのではないかと思います。