おおむらです
最近、changeのあたりから考え直しています。
ソフトウェアというものは、誰かの頭の中にある「思い」を、現実世界の「現象」にマッピングする
ナニカです。どっちの端にもモノはなく、うつろいやすいものです。
創造的であるということは、絶えず進化/変化していくということですから、生きている我々の
「思い」はどんどん変化していくし、変化していかなくてはならないと思います。
だから、ソフトウェア開発において「変化(change)」は本質的であると思います。
フォーターフローモデルなどの過去の開発手法では、変化は発生するけれど、変化が起らない
ようにしなくてはならないと考えていたと思います。
XPでは、反対に、変化が起ることを前提として、それにどう対処していくかを第一に考えて
いるのだと思います。(それがEmbrace Changeですよね)
では、変化の何がいけないのでしょうか。
いろいろ考えてみたのですが、ひとつしか思い付きませんでした。
つまり、あるシステム(ソフト開発の場合は、client-developer-softwareなどを含む全体)の
一部分だけが変化し、他の部分と整合性がとれなくなるということが、問題なのかと思います。
そういう不整合があると、システムは動かなくなるからです。
だとすると、変化に対応するための方法としては
c1. 変化を起らなくする
c2. 変化がおきたら最高速度でシステム全体に伝播する。
の二つが考えられます。
一方で、ソフト開発での変化の発生源には次のものがあります。(--XP的過ぎるかも)
s1. クライアントの頭の中
s2. 開発者の頭の中
です。s1が大元で、作ろうとしているプログラムがどういう問題を解決してほしいか、という
願望であり、s2は設計を変更したいという欲望などです。
で、XPでは、どの問題にどういう手法をとっているかという話。
c1に対しては、FrequentReleasesで、変化の発生を押さえているように思います。
c2に対しては、変化の発生源とそれの影響を受けるものの間での頻繁なやりとり
(コミュニケーション)しか手はないわけで、それによって次のようになります
クライアント-開発者間
on site clientによってコミュニケーションの相手を確保し
Metaphorで、話が通じる言語を作る
開発者-開発者間
pair programming によってコミュニケーションの相手を確保し
Coding StandardとかSimple Desing によって話が通じる言語を決める
あと、変化の終端というかシンクというか発生源の反対のものになるのが
プログラム自体なのですが、これに対してもやりとりをできるようにしています。
つまり、それがUnitTestです。(Functional Testについては略)
開発者-プログラム
Unit Test - Code のペアでコミュニケーションをシミュレートする
これは、こういうことです。
つまり、ソフトは能動的な存在ではないので、普通の意味では「やりとり」はできません。
だから、ここでは「やりとり」のシミュレーションをやっているのだと思います。
そこで、次の話を思い出してください
a) まずテストを作り、コードを書く前に実行してテストが失敗するのを確認する。
b) うまく通っているテストに対して、コードにわざわざ間違いを入れて、テストが
失敗するのを確認する。
* 実際に Unit Testをやっていると、b)もやりたくなりますし、やっていると思います。
こういう行為は、テストとコードは開発者とソフトの間の「やりとり」をするための
フィードバックループを構成しているということを意味しているように思えます。
普通なら、テストコードをテストするために、また別のテストを書かなくてはならない
ところですが、それをしないでテスト対象のコードをいじることでその替りにしています。
つまり、このペアは一方が変るともう一方も変るようなそんな関係にあるわけです。
そのあたりをループだとかんがえています。フィードバックループには、その変更を
行う開発者も含めなくてはなりませんが、コミュニケーションの場とか言語に相当する
ものが、このテスト-コード・ペアのように思います。
このフィードバックループの特徴は
1. 頻繁に行われる--普通の会話と同じように、短い時間でのやりとりができている
2. 意図のずれがあるときに、すぐに分る。ずれていないときは何も起らない。
まさにコミュニケーションのカタチだと思います。(-- 色眼鏡でみているような気がします)
また、この特徴が重要なのだとすると、これまでの開発手法における「テスト」と
XPの「テスト」はなにか違う視点が必要なようにも思います。
少なくとも、コードを先に修正してはならないのは、このことから導かれます。
コードを先に修正することを許すと、コードもまた変化の発生源となり、やっかいなものが
またひとつ増えてしまうからです。
さて、原点であるchangeという話に戻ると、Test First DesignやRefactoringにおけるテスト-コード
のペアが、コミュニケーションのシミュレーションであるのは、人間(特に開発者)の頭の中で起った
変化を迅速にシステム全体に波及させるための道具です。
そう考えたとき、テストはどうなっていなくてはならないのか...
今、考え中...