TDDは優れた設計につながりますか？
「単体テストの作成」状態からTDDに移行中です。
Johannes Brodwallが以前にアーキテクチャ段階のいずれかを回避することからかなり許容できる設計を作成しているのを見ました。それが本当の即興だったのか、彼が前もって考えていたのかをすぐに尋ねます。
私はまた、誰もが明示的な設計の悪いパターンを書くことを防ぐ経験を持っていることを明確に理解しています。
しかし、コードリトリートに参加した後は、最初にテストを書くことが間違いから私たちを救うことができるとは思いません。しかし、コード後のテストは間違いをはるかに早く引き起こすと私は信じています。
したがって、この夜の質問は、TDDを長期間使用している人々に、前もって考えずに設計の結果についての経験を共有することを求めています。彼らが実際にそれを練習して、ほとんど適切なデザインを手に入れたら。または、TDDに関する私の小さな理解で、おそらくアジャイルです。
経験から：
TDDが必ずしも優れたデザインにつながるとは限りません。 TDDを使用して設計が不十分なプログラムを取得することは可能であり、本当に簡単です。
TDDは、リファクタリングを使用して設計を高速化するための単なるツールであり、プログラムの設計を魔法のように見せることはありません。 TDDは設計ヘルプツールです。 TDDから得られる設計の品質は、設計パターンへのリファクタリングを使用する開発者の能力、またはSOLID原則へのリファクタリングを使用する能力に大きく依存します。
開発者は、継続的なリファクタリングを使用してデザインを出現させます。これはTDDの最も重要な側面です：リファクタリング。
継続的なリファクタリングを行わずにTDDを適用すると、BDUFを適用するよりも最悪のシステムの設計が非常に悪くなることがよくあります。
TDDは、「emergent design」という概念に関連していることがよくあります。アジャイルでは、機能ごとにソフトウェアを段階的に構築することがよくあります。したがって、最初からどのアーキテクチャが必要になるかを正確に知ることはできません。それは、時間とともに進化/出現します。したがって、新しい機能を追加するときは常に、アプリケーションの設計を改善するためにリファクタリングを行います。継続的/段階的な設計です。 TDDがアジャイルプロセスで重要なのはそのためです。
BDUFはTDDと互換性がありません。すでに設計を念頭に置いてソフトウェアを起動することに問題はありません。 TDDを使用すると、その設計をすばやく配置できます。そして、あなたが考えた設計が間違っていた場合、TDDはそれをうまくそして安全にリファクタリングすることを可能にします。繰り返しますが、これは単なるツールであり、アイデアをより迅速に開発し、安全かつ迅速にものを設計するのに役立ちます。
したがって、BDUF + TDDまたはEmergent Design + TDDのいずれかを実行できます。後者は、反復的な作業方法のため、アジャイルコミュニティではより一般的です。
すべての場合において、一定のリファクタリングを行うことをいとわずに新しい設計を試みようとするべきではありません。それらは両方とも一緒になり、実際には多くの規律が必要です。リファクタリングを適用せずに新しい機能を追加し続けると、物事がすぐに制御不能になります。
リファクタリングは、製品コードとテストコードの両方に適用されます。
質問についてより深い洞察を得るために読むべき興味深い記事はここにあります：
それはすべて、プログラマーの考え方に依存します。
- 以前にTDDを使用したことがある場合は、優れたデザインが得られる可能性があります。
- TDDが外部から課されている場合、プログラマーが快適に使用できる既存のパターンを壊すだけです。
- 一方、チームは共通のパターンを使用して、ランダムに異なる方向に進むのではなく、全員が同じデザインの一部を作成する必要があります
だから、どれほど破壊的なプロセスを課したいかと、プログラマーが独自の技術を使用して可能な限り最高のデザインを作成することをどれだけ信頼できるかとのバランスです。以前のコードがどのように破損していたかについてのフィードバックを得ることは、プログラマーにとって良質の指標です。