本文是Uncle Bob對軟件行業由來已久的三個頗具爭議的問題的迴應。其中有小部分與其它一些篇章太有相關性，不易閱讀，譯者未將其納入本文之中。有興趣的朋友可以參考Uncle Bob原文。
TDD
這個世上還有人還覺得TDD會導致開發速度減慢的話，就好像是活在石器時代的人一樣。對不起，不過這可是事實。TDD不會令你變慢，它只會使你加快。
好吧， TDD 可不是我的信仰，它只是我的準則之一。就像會計師的複式簿記技術，或是手術檯上的無菌操作。專業人士採納這些準則是因爲他們明白深層的原因，並且在運用這些的過程中也直接獲益。
我本人就經歷了TDD給我的工作所帶來的極大效用，而且也看到它在別人身上的果效。我自身經歷也 看到過TDD幫助程序員構想他們的設計;我自身經歷也看到過它對各種方案的描述方式；我自身經歷也看到過測試所帶來的解耦；我自身經歷也看到過TDD人修改、清理他們代碼時候的有恃無恐。
客觀的說，我不覺得TDD總是合適的。有些情形下我也會打破規則在測試之前先寫代碼。我會把這些情形寫在另篇blog裏。不過，相比之下這種情況很少。一般來說，對我對大家TDD都是讓你更快、更好、更確信的方法。
總而言之是清晰的。TDD是種專業化的準則；TDD實際奏效；TDD讓你更快；TDD不會過時。那些從沒試過TDD的人，卻聲稱TDD會減慢他們的速度，純屬有意忽視。我不在意你的名字是Don Knuth、Jamie Zawinski、Peter Seibel還是Peter Pan。實際的嘗試嘗試吧，然後你纔有評判的權利。
讓我換個方式。我現在直接針對那些聲稱 TDD 會令他們減慢的人，你真的是這麼優秀的開發人員甚至於都不用從頭到尾檢查所寫的代碼嗎？如果讓你充分發揮才能，比起可執行的測試來說，你還能想出別的更好的辦法來檢查你的代碼嗎？比起測試優先來說，你能找到一個更好的方法來保證你一定會寫出測試代碼嗎？
如果可以的話，我是願聞其詳。不過，不要告訴我你只是寫了一點兒單元測試。別告訴我說你是人工檢查代碼的。別告訴我說你是做設計的,所以不用編寫測試代碼。那些都是石器時代的觀念了。我知道，我也曾經經歷過那個遙遠的年代。
信奉設計模式
Tim Bray說過：
經驗告訴我沒有比信奉設計模式更能爲大型軟件項目帶來災難的了。
他當然是對的。信奉設計模式是一隻危害團隊的害羣之馬，而且會扼殺稚嫩的項目於搖籃之中。讓我們先搞清楚這信奉的到底是什麼。信奉設計模式就是秉着認爲使用設計模式總是好的的滿腔熱情。
是這樣的，這些設計模式不好，也不壞。它們就是它們。設定好某種特定的軟件設計情形下，可能會有某個模式適合而且有益。某些模式可能會有害。很可能現在爲止所編目的衆多設計模式中沒有一個是足夠貼切以至於你可以合上書本，然後問題就迎刃而解了。
也有另一種認同--不要用設計模式。你不去使用模式。模式就是僵化的。如果某種模式恰好解決當下問題，那肯定會非常容易看出來。沒錯，一般來說，沒完成代碼你是不會認出這個模式來的。你回頭看了看代碼，然後認出來：“噢，這是個裝飾模式！（Decorator）”
我是說設計模式無用嗎？
絕不！ 我希望你們都讀一讀設計模式的相關書籍。我希望你們從裏到外的理解這些模式。如果我點到“訪問者(Visitor)”，我希望你能夠不假思索的在白板上劃出此種模式的所有不同形式。我期待你能正確的理解其中的名詞和角色。我期待你理解模式。
不過我不想讓你們使用模式，不想讓你們相信模式，不想你把模式當成是種信仰。我期待當它們出現的時候你們能夠認出它們來，而且在代碼中做出規範化標示來，這樣其他人也能認出它們。
設計模式有巨大的果效。他們有稱謂。讀代碼的時候你就會發現“組合(Composite)”，如果作者也是按“組合”模式的規則來安排代碼的名詞和角色的話，你馬上就能明白這部分代碼的功能。非常強大！
線程同步最小化
頭一篇Duct Tape的blog中我說了這樣的話：
我發現自己很煩感Joel的觀點。他說大多數程序員都不夠聰明，他們用不來泛型、設計模式、多線程、COM、等等。我不認爲是這樣的。我覺得程序員不夠聰明去使用這些工具很可能是因爲他們在程序員學習期學的不夠聰明。
Tim迴應說：
...多線程是問題的一部分，但不是解決方案的一部分。基本上沒有應用程序開發人員能很好的理解線程，以至於可以避免出現死鎖、爭用，還有髮指的曾出不窮的bug。而COM則是我職業生涯慘遭的最濫的一坨垃圾之一。
線程同步真的是問題的一部分嗎？是的！同步確實是問題的一大部分。沒錯，同步的第一準則是：不要。第二準則是：真的，不要。
問題是有時候你沒有選擇。這些情況下，你毫無疑問的必須要用同步，你應該從裏到外的搞清楚它。
我完完全全的拒絕認同忽視是最佳的防護。我拒絕認同缺少技能會變成個優勢。所以我希望你們明白線程同步。我希望我一喊出“哲學家就餐問題”你就能跑到白板上寫出所有不同的解決方案。如果我大叫“死鎖”，我希望你馬上指出原因以及解決辦法。
是這樣的。如果你希望避免使用什麼，先徹頭徹尾的理解它吧。
（原文鏈接網址： http://blog.objectmentor.com/articles/2009/10/06/echoes-from-the-stone-age ; Robert C. Martin 的英文 blog 網址： http://www.butunclebob.com/ArticleS.UncleBob ）
本文作者Robert C. Martin
Robert C. Martin 是Object Mentor 公司總裁，面向對象設計、模式、UML 、敏捷方法學和極限編程領域內的資深顧問。他不僅是Jolt 獲獎圖書《敏捷軟件開發：原則、模式與實踐》（中文版）（《敏捷軟件開發》（英文影印版））的作者，還是暢銷書Designing Object-Oriented C++ Applications Using the Booch Method 的作者。Martin 是Pattern Languages of Program Design 3 和More C++ Gems 的主編，並與James Newkirk 合著了XP in Practice 。他是國際程序員大會上著名的發言人，並在C++ Report 雜誌擔任過4 年的編輯。