連載
NAgileで始める実践アジャイル開発

第5回 常時結合のススメ

常時結合とは、アジャイル開発として有名なXP（eXtreme Programming）のプラクティスの1つで、1日何回もコードを結合し、そしてビルドと自動テストを実行することを推奨したものだ。常時結合は継続的インテグレーション（Continuous Integration）とも呼ばれている。

常時結合の結合って、結合テストってことですか？

ここでいう結合とは、複数の開発者が作り出したソース・コードを“結合”し、ソフトウェアをコンパイルするという意味での“結合”だな。ただ、単にコンパイルするだけでなく自動テストを同時に実行することでソフトウェアが仕様に従って正しく動作することを確認していることもポイントだ。

よく分からないのですが、なぜそんなに頻繁に結合を行う必要があるのでしょうか？

そういうときは逆に考えてみればよい。頻繁に結合せずにソフトウェアのリリース直前に1回で結合するとどうなるか？ 滝は、いままでにそういう経験はないか？

えー、そういわれてみると、コーディングのフェイズが終了して結合テストのフェイズに入ったときに、ソース・コード管理内の最新コードがコンパイルを通らずに修正するのに長時間かかったという嫌な思い出が……。

それも無理からぬ話だ。結合する間隔が長くなればなるほど、結合するために必要になる時間が長くなるからな。なぜかというと、ソフトウェア開発は基本的に複数の開発者が並行作業を行っているわけだから、作業中にどうしてもズレが発生してしまう。結合の間隔が長いほど、その間のコーディング量や修正個所が増大し、そのズレを解消する作業は難しくなる。1カ月前の作業の修正と1日前の作業の修正のどちらが容易か考えると分かりやすいだろう。

確かに、それは1日前の方が簡単に修正できますよね。

そうだ。つまり結合の間隔が長くなればなるほど、コードの変更個所が増え、それに比例して結合に失敗する確率も上がり、結合の失敗を修正することも難しくなる。だからこそ、頻繁に結合することが大切なのだ。まぁ最初から完ぺきな設計ができ、チームの開発者全員が完全に統一された考えの下で完ぺきに実装でき、開発途中に要求変更などによってソフトウェア開発の状況が変わることもないというのであれば話は別かもしれんがな。

う゛、また皮肉が出た……そんなこと思ってませんよ……。

いまのはただの嫌みだ。深い意味はない。

うーん、だんだん師匠が嫌な性格になっている気が……。（気を取り直して）では、結合した後に自動テストも実行するのですね。このテストは結合テストとして新しくテスト・コードを記述するのですか？

いや、通常はテスト・ファースト・プログラミングによって作成したテスト・コードをそのまま自動テストとして実行する。もちろん、ここで新たに結合テストとしての自動テストを作成してもよいが、そこはプロジェクトの体制や求められる品質などにもよるから一概にはいえないな。

え？ 同じテスト・コードを実行したのじゃ、単体テストと同じじゃないですか？ それって意味なくないですか？

そう思うのも無理はない。この点は言葉だけで理解するのはなかなか難しいからな。では、図を使って説明することにしよう。

まず常時結合の教えは、1つのアプリケーションを複数の開発者が並行作業で開発していることが前提となる。もし1人で開発しているなら特に必要はない。まぁ1人で開発というのはあまりないと思うが。

そりゃ、そうですね。

で、図の説明になるが、AとBという2人の開発者がいて、それぞれのPC上で開発を行っている。これは一般的な開発の環境だと思う。で、まずAがソース・コード管理システム（Visual SourceSafeなど）上のコード・リポジトリ（＝データベース）からあるコードをチェックアウトし、コーディングと単体テストを行った後に、そのコードをチェックインする。そして同時にBが関連するコードをチェックアウトし、コーディングと単体テストを行った後にまたそのコードをチェックインする。

ふむふむ。

ここでBが修正したコードをチェックインする時点と、コードをチェックアウトした時点では、コード・リポジトリ内のいくつかのコードは異なっている。つまり、すでにコンパイルにも通らない、もしくはコードが正しく動作しない可能性があるのだ。もっと具体的にいうと、開発者Aが開発者Bの呼び出しているあるクラスのメソッドのシグネチャを変更したら、そのクラスを呼び出せなくなる。これぐらいなら、まだコンパイルで発見できる問題だが、より難しくて複雑なケースがある。それが仕様の不整合が生じた場合だ。

仕様の不整合？

例えば開発者Aが、あるメソッドのパラメータにNull値を渡すことができないようにコードを修正したとする。そこへ開発者Bが、そのメソッドのパラメータにNull値を渡して呼び出していた場合は、コンパイルは通るがソフトウェアは正しく動作しない。つまりプログラム仕様の不整合が発生している。そのような問題も自動テストを実行することで発見できるようになるのだ。だから、テスト駆動開発で作成したテスト・コードをそのまま実行しても意味がないことではないのだ。説明が長くなってしまったが、「自分の開発環境で正常に動作したからといって、チームのコードとして正常に動作するとは限らない」と思えばそれでよい。

なるほど、そういうことなんですね。常時結合の重要性については理解できました。ではNAgileではどのように常時結合を実践すればよいのですか？

常時結合を実践するためのソフトウェアにはCI（Continuous Integration）サーバと呼ばれるものがある。今回はそのCIサーバの1つである「CruiseControl.NET」について説明しよう。

はい！ お願いします！！