(これは TDD のメリットを調査するための質問ではありません。そのような議論の場は他にもあります。事前に感謝します。)
私は、テスト駆動開発や NUnit に対する不満を報告している、この手法の初心者である開発者が多すぎるのを経験してきました。
次のような否定的な意見を耳にします。
「NUnitは苦手です。 1年前に試してみましたが、使い方を忘れてしまいました。代わりに、テスト ハーネスとしてアドホックに書いたばかりのこの Windows フォーム アプリを使用してみましょう。テスト コードはとにかく使い捨てのコードです。違いは?とにかく、私のやり方は過去に十分に機能しました。」
「私は TDD について懸念があります。私たちの最後のプロジェクト (ちなみに、TDDを使用した最初で唯一のプロジェクト経験でした) では、もはや設計が何であるかさえ知りません。」
「これ以上のコード コメントは悪いことですか? 気が狂っていますか? 差し支えなければ、本当にやるべきことがいくつかあります。」(昔から、コメントが多いほど良いコメントであり、コメントが多すぎることはありません。)
初心者が、TDD を使用した初めてのプロジェクトで TDD がおそらく満足のいくように「機能しなかった」と不平を言った場合、それは本当に彼らを失敗させた TDDなのか、それとも開発者自身のスキルがまだ良い結果を得るのに十分ではないのか?
そして、彼らがそれを言って私を嫌うことなく、どうすればそれを伝えることができますか?
問題の核心は、私たちの重要な仕事上の関係を危険にさらすことなく、開発者が新しい開発技術で自分たちの初期の不十分な能力をより正直に評価することを奨励するために、開発者に外交的に何を伝えることができるかということです.
通常、多くの開発者は、最初のプロジェクトの段階で、TDD の多くの重要な要素を十分に活用するための実用的な知識をまだ備えていません。
たとえば、私が話した開発コミュニティの不満を言う人は、次のような典型的なものです。
コードのにおいのリストを見たり覚えたりしようとしたことさえありません。
リファクタリングのカタログを調べようとさえしたことがなく、実際のプロジェクトや学習用のおもちゃのプロジェクトでそれらを実践したこともありません。一部の人々にとっては、リファクタリングを非常にうまく行うために、もっと多くの OOP を学ぶ必要があるかもしれません。リファクタリングには、Visual Studio 2005 の [リファクタリング] メニューに項目として表示される「メソッドの名前変更」と「変数の名前変更」だけではありません。
(リファクタリングを介して) 創発的な設計を使用して実装された実際のプロジェクトを調査したり参加したりしたことはありません。事前に設計を使用してプロジェクト全体を実行することと、コードが書かれた後にのみ単体テストを作成するプロジェクト全体を実行することとの違いを知り、それらのいずれかの間のトレードオフと適用性。
彼らは皆、かつてNUnit を使用していたようで、それを使って何をしたとしても、それは TDD だった、と彼らは考えているようです。NUnit または単体テストの存在は、単純に TDD を意味するものではありませんが、それを知るにはまだ十分に理解していません。
これらは賢い人々です。開発者は賢い人です。なぜなら、それが職業全体への入り口だからです。そうしないと、長時間占領できません。もちろん、彼らがこれらの資料を勉強するためにしばらく努力すれば、それを理解することができました。
方法論やその結果を評価するには、経験と知識の合計が明らかに弱すぎるのに、どうやって方法論が弱いと自分に言い聞かせることができるでしょうか?
それは自己防衛的な行動だと私は信じています。またはそれは怠惰です。Fowler's Refactoring book のカタログからリファクタリングを 3 つ挙げることさえできない場合、またはコードのにおいをいくつか挙げることができない場合、あなたはリファクタリングのランク初心者であり、おそらく TDD 方法論全体と、いわゆる 1または 2 プロジェクトの経験は明らかに十分ではありません。
TDD での成功が決定的に依存しているスキルについてもっと学ぶために必要なことを人々にさせるために、人々に何を言うことができるか、または人々の注意をどの資料に向けることができますか?
- 単体テスト、
- リファクタリング、
- デザインパターン、
- オブジェクト指向の設計と分析?
これらの各トピックに関する本が丸ごとあり、中には非常に優れたものもあります。飲み込みやすい学習テクニックもあるかもしれません。私は模範を示して人々に教えることができますが、私自身が彼らに与える時間は限られています。
さらに、彼らは一緒に行きます。彼らはお互いなしではうまく機能しません。単体テストとリファクタリングは、ピーナッツ バターとゼリーのように連携します。単体テストを grep できない場合は、リファクタリングでまったく良い結果が得られないでしょう!! （まだわからない場合は、理由を尋ねてください。新しい人に喜んで説明します。）
また、私が何を言おうと、それが裏目に出ないようにすることも重要です。
同僚をTDD の概念から遠ざけてはなりません。さらに、同僚を私から遠ざけてはなりません。 私はこれから何年もの間、毎週彼らと一緒に働かなければなりません。
プログラミングの他の面で非常に熟練していることをすでに確立している他の長年の上級開発者を動揺させないことは特に困難です。彼らは過去の業績を当然誇りに思っていますが、彼らのエゴやプログラミングのすべてを熟知しているという自己概念は、感情を傷つけることなく対処することはほとんど不可能です. 一部の上級開発者は、他の人から学ぶべきいくつかの新しいテクニックを知らないことに直面する準備ができていません。上級開発者は、プログラミングに関しては専門家であることに慣れていて快適です。また、TDD や関連する手法やテクノロジに関しては完全に非現実的であっても、専門家として見なされることを要求することがあります。
構造化された自動ユニット テストの記述に関して常駐の「抵抗者」の 1 人を好転させるのにかなりの成功を収めた 1 つの方法は、彼らと 1 対 1 でペア プログラミングを使用することです。ペアプログラミングは、より経験豊富で知識のある実践者の直接的な指導とともに、訓練生にいくつかの実際の例と経験を与えると思います.
しかし、ペアプログラミングだけでは不十分です。彼らが学ぶ必要のあるリファクタリング、コードの匂い、OOP の概念、および OOD&A の概念は他にもたくさんあります。