ここで特に強調しておくが、アジャイルではフィードバックをとても重視する。
例えば、設計や実装に対するフィードバックを重視するのぢゃ。設計や実装を極端なまでにレビューする(eXtreme Review)。そしてそれにより、極端なまでに設計や実装へのフィードバックを受けようとする。
1つの例が、「ペア・プログラミング」という手法ぢゃ。この手法では、2人で1台のコンピュータに向かって一緒にプログラムを書く。Aさんのプログラムは、Bさんにより常にレビューされておる状態ぢゃ。Bさんがプログラムの間違いに気付けば即座に、Aさんにツッコミ(=フィードバック)を入れる。
無論、ソース・コードに対するツッコミはペア・プログラミングによるものだけではないぞ。
ソース・コードを書いてコンパイルをすると、文法的な間違いがあった場合には、ツッコミが入る。すなわち、コンパイル・エラーは、ソース・コードの静的なエラーに関するフィードバックぢゃ。
それからVisual Studio 2005の「コード分析」という機能もそうぢゃ。こちらは、より詳細なツッコミを入れてくれる。
また、プログラムの動的なエラーにツッコミを入れてくれるツールとしては、NUnitやVisual Studio 2005の「単体テスト」に代表される単体テスト・ツールがある。
実際の例を挙げてみよう。次のソース・コード(C#)では、簡単なスタック・クラスをコーディングしようとしている。前半にあるのが、NUnit用のテスト・コードで、後半が実コードであるスタック・クラスぢゃ。
// テストのソース・コード
using サンプル;
using NUnit.Framework;
namespace サンプルテスト
{
[TestFixture]
public class スタックテスト
{
スタック target;
[SetUp]
public void SetUp()
{
target = new スタック();
}
[Test]
public void 作成してみる()
{
Assert.AreEqual(0, target.Count);
}
[Test]
public void Pushしてみる()
{
target.Push(10);
Assert.AreEqual(1, target.Count);
}
}
}
// 実ソース・コード
namespace サンプル
{
public class スタック
{
public int Count
{
get { return 0; }
}
public void Push(object newObject)
{
}
}
}
|
|
テスト・コードとテスト対象であるスタック・クラス(C#) |
|