怎么理解呢？這位女士以Nike作比喻。第一步是設計Nike鞋，這就是發現價值，可能獲得100美元的價值；然后再拿到中國來生產，大約是10美元；最后再將生產好的鞋子，貼上Nike的商標送回到美國去賣，又可以收獲90美元。一雙鞋售價200美元，而生產價值所能收獲的卻只有10美元。這一步獲取利益最低，我們中國的公司卻做得最好。而怎么去發現價值，然后又怎樣去鞏固自己的品牌和知名度，中國的公司就做得不那么好了。

　　據我的了解，國內的軟件開發應用TDD相對較少，很多人認為：測試驅動開發是個好東東，但似乎不符合中國國情。說到原因，最多的一條就是項目時間緊，沒有時間寫測試代碼。在項目中，到底該不該使用TDD，大多數人持懷疑或觀望的態度。這種態度與觀點，就讓我想起了如上《對話》中的這一段話。

　　再仔細分析企業運行價值鏈的三步走，我覺得和軟件開發的TDD價值鏈很相似。第一步，是發現價值。應用到TDD中，就是測試先行，通過測試來驅動我們編寫代碼。第二步，生產價值。毋庸置疑，這正是編寫代碼的一個階段。而第三步，就是收獲價值，在TDD中，我們收獲的不僅有開發后完整的產品，同時還收獲了完整的測試套件。和Nike鞋的生產一樣，我們在軟件開發中，過度地重視了第二步生產價值階段，而對于第一步和第三步，要么是忽略了，要么就是沒有提高到相應的高度。

　　一、發現價值與生產價值

　　習慣了傳統開發模式的程序員，非常不適應寫代碼之前，先寫測試的方法，這其中也包括我。那么，我們一般是怎樣去發現價值的呢？首先通過需求分析，然后進入設計階段。在設計階段期間，再圍繞需求分析的結果，更多的是從實現的角度，而非從客戶應用的角度出發。TDD顛覆了這種模式。因為需要測試先行，就驅動了程序員必須從功能出發、從應用出發。在寫測試代碼的過程中，我們需要考慮要實現那些功能，相應的類的名稱、對象的創建方式，以及可能會應用到的模式和策略，如此種種，在這個過程中，如剝筍子一般逐漸地規定出來了。

　　在這個過程中，我們要審慎地選擇測試的步子。昂首闊步雖然顯得氣勢軒昂，行進快速，但往往會忽略沿途的風景。在測試驅動開發中，我建議你小心的規劃測試樣例，從測試樣例的逐步完善中，漸進地驅動出你更加完善的代碼。例如，我需要開發一個智能的個人助理，它目前能提供的功能是：能夠讓用戶定制自己感興趣的類別，然后個人助理根據用戶的定制進行搜索，并將搜索得到的結果按不同的類別進行存儲。

　　我們來嘗試一下TDD的過程。根據對功能的分析，我們首先應該有一個智能助理對象，測試代碼如下：
　　[Test]
　　public void TestSmartAssistor()
　　　　{
 　　　　　　SmartAssistor assistor = new SmartAssistor();
　　　　　　 Assert.IsNotNull(assistor);
　　　　}
　　當然，這段代碼是連編譯都無法通過的，我們還需要創建SmartAssistor類型。然而，不要小瞧了這一步，它實際上促使你對項目進行初步的理解，至少，你需要想好這個將要創建的類型，它的名字是什么？這就是一種驅動力。（為了簡便起見，在本文只列出測試代碼）

更多軟考資料請訪問：考試吧軟件水平考試欄目

希望與更多網友交流，請進入考試吧軟件水平考試論壇