次に、私は実行可能なコードが将来の判断材料となるようにしていますが、それは大がかりなアーキテクチャや、憶測に基づいた大規模システムにしたくないからです。それは正しい判断です。話を元に戻しますが、実行可能なコードを書き始める前に、どれぐらいの時間を使いますか?例えば、最終的に200万行ぐらいになるシステムだとしたらどうでしょうか?うーん。200万行という規模は、経験上かなり小規模ですね。個々のシステムによると思いますが、シンプルな通信業界向けのシステムであると仮定しましょう。C++のシステムという前提です。少なくともコンストラクタとデストラクタは、然るべきものを作ります。テストは書かないのですか?関連をテストするための。間違いなく書くテストは、例えばシステムの起動や終了時にメモリが正常であるかなどをきちんと確認できるテストです。30分といったところでしょう。素晴らしい!では我々の相違点はどこにあるのでしょうか?おそらくそれはTDDとプロフェッショナリズムの考え方についてではないでしょうか。次はそのことについて話しましょう。そのことについては個別に反論はありますが、我々の間では解決できるものだと考えています。それはそれでよいのですが。これを聞いている人達のために再度明確にしておきたいと思います。正しいやり方をしている人に出会えた時に、以前からこの種の問題の回避方法は、話合われてきたのだと考えるようになりました。したことは、TDDの書籍や、TDD入門では扱われていません。North氏が今BDDと呼んでいるような手法に乗り換えてきています。私はBDDは本当に素晴らしいと思っています。(RSpecや、低レベルな部分に引きずられているところを除けば、ですが。)すでに正しいやり方をしている人はたくさん居るのに、それをTDDと呼んでしまっています。その結果、本を買ってTDDを調べ「アーキテクチャはテストによってしか得られないのだ」という古い考え方に辿り着いてしまうことを懸念しています。いうセリフをこの6カ月のチュートリアルで4回聞きました。あなたが言ったようにそれはただの馬糞です。TDDを実践している人達、でしょうか。私にとって「プロフェッショナル」というのは単にその分野で仕事をしてお金を稼げる人のことです。それは私も理解しています。私はそこから一歩進めたいのです、なぜなら我々の業界はどこかプロフェッショナルの基準というものに欠けているからです。スタート地点として、あなたの定義を確認する必要がありそうですね。すれば議論ができると思います。実際に定義があるわけではなくて、口上みたいなものです。私が思うに、近頃ではユニットテストをしていないコードを納品する開発者は無責任であるということです。これを正すのに一番良い方法は、TDDを実践することでテストしていないコードが納品されないようにすることです。ここは重要で深いポイントだと思うので、例を出して反論させてください。他の例も出せますが一例として。コードインスペクションやペアプログラミングはとてもよいもので、きっとすごい価値があるという見解に対して、手を振り回してなんやかんやいちゃもんを付けることもできますが、それは別の機会にしましょう。重要で、的を射ていると思っていることを言わせてください。ユニットテストが何なのかということに注目してみましょう。ユニットテストが何なのかというと、APIや、引数を持つ状態空間がうまく動くか調査するもので、それが半ダースとか百とか、場合によっては数百万(2の32乗)ぐらいの数になることもあります。それを淡々と試行してゆくわけです。これは本当に発見的なやり方です。やってバグを見つけられるのは本当に幸運としか言いいようがないです。Contract)」です。「契約による設計」では事前条件と事後条件と、そして不変表明を書きます。殆どの言語ではこの技術はサポートされていません。この技術は静的に条件のチェックができる言語でしか使用できないし、Eiffel以外の言語では成熟しているとは言えません。似たような機能を基盤技術に追加することはできます。「契約による設計」はあらゆる面でTDDより優れていると考えています。コードを堅牢にしたいときや、外部からの見え方に焦点を当てたいとき、などが長所です(そう私は思います)。少なくとも自分にとっては、この「契約」はテストよりも効果的だと気付きました。言うと、より広範囲なカバレッジを実質的に保証してくれます。無作為に適当な値をいくつかばらまくより、引数の入力範囲をカバーすることができるからです。Development)と呼んでいるものに取りかかっています。これは何をしているかというと、まず「契約」を設定し、それに基づいた任意の値をいくつか入力してみます。ここで事前条件を満たしていなければ、それはテストは失敗することがわかるので、実行しません。テストをしてみて実行後に事後条件が満たされていれば問題無いですが、そうでなければバグです。彼らは実際にこの手法を行ってみました。テストを自動実行できるツールも使いました。Eiffelライブラリで、1週間使ってこれを実行してみたところ、20年間使われてきたEffielライブラリで、7つのバグを見つけてしまいました。これはちょっと興味深いですね。ところで、契約による設計では、ビジネス的な意義を突き止めうる方法で、コードを意識的に表現していますが、TDDで問題だと思うのは、多くの開発者がビジネス的な意義をクラスレベルまで落とさないといけないということです。これは事実そうなっていると思います。時としてビジネス的な意義を突き止めるための手段が、クラスレベルでAPIを追跡するしかないことがありますが、それは本当に大変なことです。いうトラブルは私も経験があります。この話はずいぶん昔に一段落したと思っていました。それからクラスの不変表明を明確にするんでしたよね。テスト駆動開発、またはユニットテストの組み合わせでもいいですが、実質的には同じことをしています。メソッドの引数の入力や戻り値のチェックの組み合わせを明確にしたり、あなたが言っていたような状態空間の調査もします。いつも思うのですが、それは表裏一体の関係です。いつでも契約をユニットテストに置き換えることもできますし、逆も可能です。あなたも知っているように私は依存関係マニアなので、依存関係の方向が違ういう点が異なるとは言っておきましょう。ユニットテストはプロダクションコードに依存しています。これは問題無いと思います。プロダクションコードはユニットに依存していません。一方で契約はプロダクションコードを汚してしまい、それが悩みの種になります。それは無理に二元的な考え方をしているのではないでしょうか。考えるべきは一つしかなくて、それはコードであり、コードはつまり設計そのものです。それ以外はリーンとは言えません。ユニットテストを使っている典型的なプロジェクトでは、コード量とテストの量はだいたい同じです。コードがあるところにはバグがあります。自分の作業速度を半分にしているようなものです。知られている例として一番有名なのは、ADAコンパイラがテスト駆動開発を使うことで、逆にバグを増やしてしまったというものです。これは、テストの量を増やすことで、コードの量を増やしてしまったことが原因です。(「契約による設計」の)表明を使えば、インタフェースが持つセマンティクスとコード自体との間に良い、というかむしろ不可欠の結合を持つことができます。一方で、テストを使った結合は、はるかに厄介なもので、管理しにくいと言えます。コードの量に対する考え方の違いに驚いています。実際にどうやって使われているかを見てきましたが、(「契約による設計」の)表明のように書かれたJUnitテストは良いものだと思います。いうふうに書かれていないテストが多かったです。厄介なテストがあるというところは同意しますが、厄介なコードもあります。あなたは「ツールは誤用されがちなので、それを使うべきではありません。」ということを理由にしていますが、それは良くない考え方です。それを言ってしまうと、何もできなくなってしまいます。いえ、そんなことは言っていません。私が言っているのは、幅広い手法のなかで実際に使われている手法を、私がどう見ているか、と、それから、それがちゃんと理解されていないということです。