これは、多数派が支配すべきだという意味ではない。委員会によって設計されたアーキテクチャは、肥大化し、焦点が定まらない傾向がある。私たちの経験では、理想的なバランスとは、多様な経験と視点を持つ数人の仲間が、より良い情報に基づいた決定を下すために、主張に異議を唱えることである。 再利用の目標が誤った決定を左右するようなことがあってはならない。その代わり、再利用は理にかなった場合のみ行うこと。 コード、コンポーネント、設計、あるいはコンフィギュレーションの再利用は、最初は良いアイディアのように聞こえる。経営陣は、再利用によってコストが削減され、納期が短縮され、品質が向上すると信じて、このコンセプトを推進したがる。チームは、MVPをより早く提供するために既存のアプリケーションの大部分を再利用することを決定するかもしれないし、かなり成功した製品を提供するために作成された既存のアーキテクチャを再利用す

この記事は，TDDに見切りをつけたある大学教授の経験と，Uncle Bobの反論を要約したものだ。 ソフトウェア工学の大学教授を退官したIan Simmerville氏には，“Software Engineering, 10th edition”を含む数冊の著書がある。同書の第８章はすべてソフトウェアテストに関する内容であり，特に8.2章ではTDDを取り上げている。それらの章で紹介された考え方を何度も引き合いに出しながら，Sommerville氏は先日の記事に，“TDDはソフトウェア工学の大きな進歩です。いくつかのクラスのシステムにおいては，それが有効であることが明らかです。”と述べて，次のような“TDDフレンドリ”なシステムの一覧を紹介している。 階層化アーキテクチャ 合意された成功基準を持ち，それに準拠したテストに基づいて構築されるシステム。 自身のコントロールを越えてシステムと対話す

1992年にWard Cunningham氏が、技術系ではないステークホルダにこの問題を伝えるために、初めて「技術的負債」というメタファを使いました。品質の低いコードと自動テストによるカバレッジがないことは、財務的負債と比較されます。このようなコードは、開発者だけでなく、すべてのステークホルダが負う財政的な重荷になり、将来的に利息が課される負債になります。元本額は、コードベースを将来簡単に変更できるようにリファクタリングするコストです。利息は、チームがよいコードではなく、汚いコードに取り組まなければならない場合に、将来支払う余分なコストです。 財務的負債とは違い、技術的負債は返済しなくてもよい負債です。時には、返済するのが無駄なこともあります。ある部分のコードを読んだり、変更したりすることはめったにないか、決して起こらないかもしれません。そのため、技術的負債も、どのくらい起きそうかを考慮す