テスト駆動開発（および一般的なアジャイル）のこの制限は実際に関連していますか？

テスト駆動開発（TDD）では、最適ではないソリューションから開始し、テストケースを追加してリファクタリングすることにより、より良いソリューションを繰り返し生成します。ステップは小さいと想定されています。つまり、新しいソリューションはそれぞれ前のソリューションの近くにあることになります。

これは、勾配降下法やローカル検索などの数学的なローカル最適化方法に似ています。このような方法のよく知られた制限は、グローバルな最適値、または許容可能なローカルな最適値を見つけることを保証しないことです。開始点が悪い解の大きな領域によってすべての許容可能な解から分離されている場合、そこに到達することは不可能であり、メソッドは失敗します。

より具体的に言うと、いくつかのテストケースを実装した後、次のテストケースではまったく異なるアプローチが必要になるというシナリオを考えています。前の作業を破棄して、最初からやり直す必要があります。

この考え方は、TDDだけでなく、小さなステップで進行するすべてのアジャイルメソッドに実際に適用できます。この提案されたTDDとローカル最適化の類推には重大な欠陥がありますか？

このような方法のよく知られた制限は、グローバルな最適値、または許容可能なローカルな最適値を見つけることを保証しないことです。

比較をより適切にするために、ある種の問題では、反復最適化アルゴリズムが適切なローカル最適値を生成する可能性が非常に高く、他の状況では失敗する可能性があります。

いくつかのテストケースを実装した後、次のテストケースではまったく異なるアプローチが必要になるというシナリオを考えています。前の作業を破棄して、最初からやり直す必要があります。

これが現実に起こりうる状況を想像することができます。間違ったアーキテクチャを選択した場合、既存のすべてのテストを最初から再作成する必要があります。オペレーティングシステムAのプログラミング言語Xで最初の20個のテストケースの実装を開始するとしましょう。残念ながら、要件21には、プログラム全体をオペレーティングシステムBで実行する必要があります。したがって、ほとんどの作業と言語Yでの再実装を破棄する必要があります（もちろん、コードを完全に破棄するのではなく、新しい言語とシステムに移植します）。

これは、TDDを使用する場合でも、事前に全体的な分析と設計を行うことをお勧めします。ただし、これは他の種類のアプローチにも当てはまるため、これは固有のTDD問題とは思わない。また、実際のプログラミングタスクの大部分では、標準アーキテクチャ（プログラミング言語X、オペレーティングシステムY、ハードウェアXYZ上のデータベースシステムZなど）を選択するだけで、TDDのような反復またはアジャイル手法を比較的確実に実行できます。行き止まりにはなりません。

ロバートハーヴェイを引用して：「ユニットテストからアーキテクチャを成長させることはできません。」またはpdr：「TDDは、私が最高の最終設計に到達するのを助けるだけでなく、より少ない試行でそこに到達するのに役立ちます。」

実際にあなたが書いたもの

開始点がすべての許容可能な解決策から悪い解決策の大きな領域によって分離されている場合、そこに到達することは不可能であり、メソッドは失敗します。

真実になる可能性があります-間違ったアーキテクチャを選択すると、そこから必要なソリューションに到達しない可能性があります。

一方、事前に全体的な計画を立てて適切なアーキテクチャを選択する場合、TDDを使用することは、「グローバルな最大」（または少なくとも十分な最大）数サイクル。

TDDには極大の問題はないと思います。あなたが正しく気づいたように、あなたが書くコードはかもしれませんが、それがリファクタリング（機能を変更せずにコードを書き換える）が整っている理由です。基本的に、テストの増加に伴い、必要に応じてオブジェクトモデルの重要な部分を書き換えることができますが、テストのおかげで動作は変更されません。テストは、システムに関する不変の真理を示します。したがって、局所的および絶対的最大値の両方で有効である必要があります。

TDDに関連する問題に興味がある場合は、よく考える3つの異なる問題に言及できます。

1. 完全問題：システムを完全に記述するために必要などのように多くのテスト？「例によるコーディング」はシステムを記述する完全な方法ですか？

2. 硬化問題：へのインタフェースをテスト何は、不変のインタフェースを持っている必要があります。テストは不変の真理を表します、覚えておいてください。残念ながら、これらの真実は、ほとんどの場合、外部に面するオブジェクトについてのみ、私たちが書くコードのほとんどについては知られていません。

3. テスト損傷問題：アサーションがテスト可能にするために、我々は次善のコード（たとえば、あまりパフォーマンスを）記述する必要があります。コードができる限り良好になるようにテストを作成するにはどうすればよいですか？

コメントに対処するために編集：ここでは、リファクタリングによって「ダブル」関数の極大値を抽出する例を示します。

テスト1：入力が0の場合、ゼロを返します

実装：

function double(x) {
  return 0; // simplest possible code that passes tests
}

リファクタリング：不要

テスト2：入力が1の場合、2を返す

実装：

function double(x) {
  return x==0?0:2; // local maximum
}

リファクタリング：不要

テスト3：入力が2の場合、4を返す

実装：

function double(x) {
  return x==0?0:x==2?4:2; // needs refactoring
}

リファクタリング：

function double(x) {
  return x*2; // new maximum
}

あなたが数学用語で説明しているのは、私たちが自分自身を隅に描くと呼ぶものです。この発生はTDDに限定されることはほとんどありません。ウォーターフォールでは、そこに到達するためだけにグローバルな最大値を確認し、次の丘の上にもっと良いアイデアがあることを理解することを望んで、数ヶ月間の要件を収集し、注ぐことができます。

違いは、この時点で完璧であるとは決して思わなかったアジャイル環境にあるため、古いアイデアを捨てて新しいアイデアに移行する準備が整いました。

TDDに固有の機能として、TDDで機能を追加する際にこれが発生しないようにするテクニックがあります。それが変換優先の前提です。TDDにリファクタリングする正式な方法がある場合、これは機能を追加する正式な方法です。

では彼の答え、@Sklivvzは説得力の問題が存在していないと主張しています。

私はそれが問題ではないことを主張したい：反復的な方法論全般とアジャイル、特にTDDの基本的な前提（および存在理由）は、グローバルな最適化だけでなく、ローカルな最適化でもないということです」知られています。言い換えると、それが問題であったとしても、とにかくそれを繰り返し行う方法はありません。基本的な前提を受け入れると仮定します。

TDDとアジャイルのプラクティスは、最適なソリューションの作成を約束できますか？（または、「良い」ソリューションでさえ？）

ではない正確に。しかし、それは彼らの目的ではありません。

これらの方法は、ある状態から別の状態への「安全な通過」を提供するだけであり、変更には時間がかかり、困難で、リスクが高いことを認めています。そして、両方のプラクティスのポイントは、アプリケーションとコードが実行可能であり、要件をより迅速かつ定期的に満たすことが実証されていることを保証することです。

... [TDD]は、要件を満たすことが証明されていないソフトウェアの追加を可能にするソフトウェア開発に反対しています ... KDDは、2003年にTDDが推奨することを述べた技術を開発または「再発見」したとされています自信をデザインし、刺激します。（ウィキペディア）

TDDは、コードの各「チャンク」が要件を満たすことを保証することに焦点を当てています。特に、貧弱なコーディングによって要件を推進するのではなく、コードが既存の要件を確実に満たすのに役立ちます。しかし、実装が何らかの形で「最適」であることを約束するものではありません。

アジャイルプロセスに関して：

作業ソフトウェアは進捗状況の主な指標です...各反復の終わりに、利害関係者と顧客の代表者は進捗状況を確認し、投資収益率を最適化するために優先順位を再評価します（Wikipedia）

敏ility性は最適なソリューションを探していません。ROIを最適化することを目的とした、実用的なソリューションです。それは後よりも早く実用的なソリューションを約束します; 「最適な」ものではありません。

しかし、その質問は間違っているので、OKです。

ソフトウェア開発のOptimumsは、あいまいで移動するターゲットです。通常、要件は流動的であり、上司の上司でいっぱいの会議室で、あなたの恥ずかしいことにのみ現れる秘密に満ちています。そして、ソリューションのアーキテクチャとコーディングの「本質的な良さ」は、同僚と管理上の大君の意見の分かれた主観的な意見によって評価されます。誰も実際に良いソフトウェアについて何も知らないかもしれません。

最低限で、TDDとアジャイルプラクティスは困難を認め、二つのものを最適化しようとしている客観的かつ測定：作業V-ない作業。そしてスーナーV以降。。

また、客観的な指標として「仕事」と「早い」があったとしても、それらを最適化する能力は、主にチームのスキルと経験に左右されます。

努力が最適なソリューションを生み出すときにあなたが理解できることには、次のようなものがあります。

• 堅実な原則
• きれいなコード
• デザインパターン
• 熟練した経験豊富な人を雇う...

等..

_{それらのそれぞれが実際に最適なソリューションを生成するかどうかは、尋ねるべきもう1つの大きな質問です。}

これまで誰も追加していないことの1つは、あなたが説明している「TDD開発」は非常に抽象的で非現実的であることです。アルゴリズムを最適化する数学的アプリケーションでのようなものかもしれませんが、ほとんどのコーダーが取り組んでいるビジネスアプリケーションではあまり起こりません。

現実の世界では、テストは基本的にビジネスルールを実行および検証しています。

たとえば、顧客が妻と2人の子供を持つ30歳の非喫煙者である場合、プレミアムカテゴリは「x」などです。

プレミアム計算エンジンは、非常に長い間修正されるまで繰り返し変更されることはありません。ほとんどの場合、アプリケーションが稼働している間はそうではありません。

実際に作成したのはセーフティネットであるため、顧客の特定のカテゴリに新しい計算方法が追加されたときに、古いルールが突然破られて間違った答えを出すことはありません。デバッグの最初のステップが、バグを修正するコードを記述する前にエラーを再現するテスト（または一連のテスト）を作成することである場合、セーフティネットはさらに便利です。その後、1年後に、誰かが誤って元のバグを再作成した場合、コードがチェックインされる前に単体テストが中断します。しかし、それはあなたの仕事の大部分ではないはずです。

邪魔になるとは思わない。ほとんどのチームには、たとえホワイトボードに書いても、最適なソリューションを思い付くことができる人はいません。TDD /アジャイルは邪魔になりません。

多くのプロジェクトは最適なソリューションを必要とせず、必要なものは、この分野で必要な時間、エネルギー、フォーカスが作成されます。他のすべてのものと同様に、最初に構築する傾向があります。その後、高速にします。パフォーマンスがそれほど重要な場合は、何らかのプロトタイプを使用してこれを実行し、多くの反復を通じて得られた知恵で全体を再構築できます。

いくつかのテストケースを実装した後、次のテストケースではまったく異なるアプローチが必要になるというシナリオを考えています。前の作業を破棄して、最初からやり直す必要があります。

これは発生する可能性がありますが、発生する可能性が高いのは、アプリケーションの複雑な部分を変更する恐れです。テストを受けていないことは、この領域に大きな恐怖感をもたらす可能性があります。TDDと一連のテストの利点の1つは、変更する必要があるという概念でこのシステムを構築したことです。このモノリシックに最適化されたソリューションを最初から考え出すと、変更するのが非常に困難になる可能性があります。

また、これを最適化不足の懸念のコンテキストに入れてください。パフォーマンスに過度に集中しているため、必要のないものを最適化し、柔軟性のないソリューションを作成することに時間を費やすことはできません。

「ローカル最適」のような数学的概念をソフトウェア設計に適用するのは欺くことができます。このような用語を使用すると、ソフトウェア開発は実際よりもはるかに定量的で科学的に聞こえます。コードに「最適」が存在したとしても、それを測定する方法はなく、したがって到達したかどうかを知る方法もありません。

アジャイルな動きは、ソフトウェア開発を数学的手法で計画および予測できるという信念に対する実際の反応でした。良くも悪くも、ソフトウェア開発は科学というよりも技術のようなものです。