軟件開發過程有一個很自然的比喻：建樓房，要畫圖紙、搭架構、砌磚頭。這個比喻大體說得過去，問題是，這個“磚頭”絕非普通的磚頭，具有以下特性：
一、每一塊都由手工製作；
二、每一塊的材質、形狀、尺寸都不同；
三、任何一塊有問題，在某種天氣下，房子會漏水；如果1%甚至1‰的磚頭有問題，房子會到處漏水；更嚴重的是，一塊或多塊磚頭有問題，還可能造成房子在某些時間倒塌。
正是因爲“磚頭”的上述特性，所以存在兩個80%：軟件的質量，80%依賴於代碼；軟件的開發成本，80%用於編寫合格代碼，請注意，是“合格代碼”，不是“代碼”，後期的測試和排錯，也是編寫“合格代碼”的組成部分。即使兩個80%不準確，改爲70%，甚至60%，決定軟件質量和開發成本的大頭，也仍然是編碼。不重視編碼過程的改進，提升質量和產能就失去了最主要的着力點，必然會感覺什麼措施都效果不明顯。
如果建樓房的磚頭也具有上述特性，相信任何一個建築商，都會絞盡腦汁，找出一次性做出合格磚頭的辦法，而不是等到樓房建起來再查找和修補有問題的磚頭。
軟件開發，有沒有一次性編寫合格代碼的方法？有，例如TDD。TDD是敏捷開發的核心實踐之一， Ruby On Rails的創始人DavidHeinemeier曾說，當年它打開了一扇門，讓自己看到了高質量代碼的全新世界。
然而，TDD太難了，而且爲了解決可測性問題，需要做很多額外工作，例如爲了支持Mock而做的很多重構。David Heinemeier近日發表了一篇文章：《TDD已死，測試永生》，痛批TDD過於偏重單元測試，過於瑣碎，會使系統同許多中間層、中間對象組成，帶來複雜臃腫的架構。他明確聲明自己將放棄TDD。
如果對TDD進行改進，消滅它的主要成本，並放大它的效益，就得到了一個大幅提升代碼質量、大量降低開發成本的開發方式，這種開發方式，就是easy TDD，簡稱eTDD。
eTDD如何做到消滅TDD的主要成本、放大TDD的效益呢？答案是利用工具：由工具完成苦活、髒活、重活；由工具描述程序行實現可視編程。
苦活、髒活、重活包括：編寫測試驅動、編寫樁代碼、編寫Mock、覆蓋統計、找出遺漏用例、編寫測試報告，並避免僅僅爲了單元測試而做的重構，總之一句話：除了測試數據需要人工設定外，其他都由工具完成，這樣，就消滅了TDD的主要成本。
可視編程則顯著放大TDD的效益。可視編程就是編寫代碼時，可以隨時察看程序行爲。程序行爲，就是在什麼輸入下，會執行哪些代碼，會產生什麼輸出。單元測試的輸出可以完整描述程序行爲，使程序行爲可視，這是極寶貴資源，TDD忽略了這一點，甚爲可惜。利用可視編程，程序員寫幾行代碼，就可以看看程序會做什麼，從而驗證思路、發現錯誤、激發靈感。對於比較複雜的程序，用可視編程編寫合格代碼的效率，是傳統方式的4、5倍，同時，還能降低編程的勞動強度，保護程序員的健康。
人類生產力的提升，絕大多數依賴工具的進步，軟件開發也不例外。編程是高技術工作，人才成本很高，而且會越來越高，一名月薪1萬的程序員，公司要付出的實際成本爲1.5萬至2萬，折算成小時成本，大概是100元，即手工編寫測試代碼，1小時要付出100元，而這種工作完全可以由工具代勞。eTDD將麻煩的事情交給工具，避免了以手工爲主的TDD所產生的高成本，更重要的是，eTDD簡單易行，不用考慮讓人頭疼的“可測性”問題，因爲解決可測性問題，是eTDD工具的基本功能。eTDD可以在項目週期的任意時段引入，還可以部分引入，例如，只對較底層或較重要的代碼使用eTDD。總之，只要使用合適的工具，eTDD很容易實施，效果立竿見影。
eTDD與傳統方式對比實驗，以及實際開發任務實驗，可以證明：eTDD使編程產能翻二番，當然，這是指單純編寫合格代碼的產能。除了編寫代碼，程序員的工作還包括：對技術難點的研究、查閱文檔、溝通、開會、寫文檔、發呆等等，這些時間，eTDD當然不能產生作用。一般來說，如果沒有大規模的需求變更，eTDD縮短開發週期30%是可以預期的。這裏說的開發週期並不是“計劃”週期，而是“實際”週期，例如，計劃三個月完成的項目，實際週期往往是六個月，如果用eTDD，則可以四個月完成。縮短開發週期只是eTDD的次要效益，eTDD的首要效益，是保證代碼質量。
關於eTDD的更詳細信息，請下載瀏覽eTDD電子書：
PDF格式CSDN下載：http://download.csdn.net/detail/dellfox/7313953
PDF格式：http://www.kailesoft.com/download/eTDD_pdf.rar
Word格式：http://www.kailesoft.com/download/eTDD_word.rar
電子書內容包括：eTDD概念、過程、示例、關鍵技術、實驗過程與結果、效益分析。如果對eTDD的效益有所懷疑，還可以依照電子書中的說明，親自進行小實驗或實際任務實驗。