想在園子里寫點東西已經(jīng)很久了，但一直沒有落筆，忙著做 一起幫 的開發(fā)直播，還有些軟文做推廣，還要做奶爸帶孩子，還要……好吧，我承認(rèn)，真正的原因是：

太特么的難寫了！

 

但再難寫也要寫啊，要等到“能寫好了再寫”，怕是黃花菜都涼了——尤其是技術(shù)類文章，時效性非常強的。

剛好壇子里這篇博客：關(guān)于拒絕測試驅(qū)動開發(fā)（NoTDD），看評論爭議不小，而這個問題也是我最想寫的，所以，蹭個熱點，呵呵。

 

其實我很好奇，博客下面熱烈討論的童鞋，有多少人是真正的在項目中堅持過TDD的。

我公司里的項目，從來沒有哪一個項目是要求TDD、能夠TDD的；我自己的項目，堅持過TDD一段時間，而且應(yīng)該是非常久的一段時間，尤其是Entity部分，但現(xiàn)在我基本上都已經(jīng)放棄了。

為什么呢？

可以洋洋灑灑千言萬語，也可以簡簡單單三個字：不劃算。

 

其實不僅僅是TDD，還包括三層架構(gòu)、設(shè)計模式、ORM等等這些東西，存在大量的爭論，莫衷一是：說它好的把它捧到了天上去，說它不行的批得它體無完膚，雙方都有大牛為其站臺，都可以一二三四五的列出長長的清單，而且每一條都很有道理……

當(dāng)討論變成了一種辯論，當(dāng)辯論變成了一種罵戰(zhàn)，最后拼的就是誰的態(tài)度更堅決，誰的言辭更犀利，誰的聲音更大……所以雙方的觀點更加的偏激、對立，而這其實無助于我們客觀冷靜的來分析問題。

 

說理太枯燥了點，還是聽飛哥講故事吧，呵呵。

 

最早，我剛接觸“設(shè)計模式”。什么玩意兒??？！整本書，就一個感覺，“脫了褲子放屁”。明明一個對象，new一下不就OK了么？什么Factory啊Builder啊，搞毛線呢？所以一直是云里霧里的，包括那些開閉原則、依賴倒置，都似懂非懂的，沒幫上我什么忙。

直到有一天，也不知是在哪里，我看到了三個字“上下文”，或者說一句話，大意是：只有理解了上下文，理解了設(shè)計模式想要解決的“問題”，你才能真正的理解設(shè)計模式。不知道是不是那時候積累也差不多了，茅塞頓開恍然大悟！

我在架構(gòu)之路（一）：目標(biāo)里說過：設(shè)計模式是藥，看評論其實很多同學(xué)沒有理解，對照這句話看能不能明白過來：理解了設(shè)計模式想要解決的“問題”……？要解決的問題就是“病”，沒病就不要亂吃藥；同理，沒有“問題”，你也不要亂用設(shè)計模式。

 

一通百通。

所以從最基礎(chǔ)的面向?qū)ο蟆⒌饺龑蛹軜?gòu)、ORM、以及敏捷開發(fā)、TDD……，所有這些概念方法，本質(zhì)上都是要解決問題的，而且基本上也是能夠解決問題的。

而你，認(rèn)為它“沒用”，其實最大的原因是：你還沒碰到這方面的問題。

在這里，大家一定要區(qū)分兩個概念：“它解決不了問題”和“它（對我）沒用”。還是用藥做比喻，“這藥治不了病”，和“這藥（對我）沒用”是兩個概念。而且尤其要注意的是這兩個字：對我。

換到項目中，就是這種架構(gòu)這種開發(fā)模式，適不適合這個項目，能不能解決這個項目開發(fā)中遇到的問題。

其實之前我也看到過類似的提法，比如：xxx適合“大”項目。但用“大”和“小”來區(qū)分項目，毛糙了一些，很多時候，并不見得正確。最正確的做法是：你了解項目的特點，同時也了解各種模式的優(yōu)劣，從而能夠正確的匹配和選擇。當(dāng)然，這是一個非常龐大的話題，這里沒辦法展開了。

 

好，上面我們提到了“優(yōu)劣”，所謂優(yōu)勢和劣勢，但其實，這個提法并不準(zhǔn)確。優(yōu)勢，大家都可以承認(rèn)，解決了問題嘛；但劣勢……什么叫做劣勢？不服……

我更愿意用另一個詞：成本。

“天下沒有免費的午餐”。

這是一個經(jīng)濟(jì)學(xué)上的諺語。一提到這話，我就想起我大學(xué)的時候坐在教室里聽老師講《西方經(jīng)濟(jì)學(xué)》……往事歷歷在目，誰曾想，我會是今天這個樣子？

再說點題外話吧。

【野生程序員】：優(yōu)先招聘是意氣之作，但并非完全意氣用事，在我該不該轉(zhuǎn)行？（一）野生程序員的優(yōu)勢一文里，我就較為詳細(xì)的闡述了野生程序員的優(yōu)勢。簡單的說：做架構(gòu)，做項目管理，需要一個更宏大的視野，而不僅僅是二進(jìn)制和計算機原理。

這里，我們還是回過頭來看，什么叫做“天下沒有免費的午餐”？不要理解為“做人不要貪心以免上當(dāng)”之類的喲！你可以理解為：做任何事情都需要成本。但我更喜歡另一種說法：凡是選擇，必有代價。

 

具體到項目中，不管（注意是不管，無論，隨便……）你選擇是不是遵循TDD的規(guī)范要求，只要你選擇了，就必然有代價：

  • 不使用TDD，就會在代碼的重構(gòu)、維護(hù)、健壯性等方面付出代價；

  • 使用TDD，就會在測試代碼的開發(fā)和維護(hù)上付出額外的代價。

無論你怎么選，一定是要付出“代價”的。換言之，代碼的“低耦合”“可測試”“便于重構(gòu)”……不可能從天上掉下來，一定是有成本的！

 

這本來是一個最簡單不過的道理。

然而，當(dāng)我們迫切的想達(dá)到一種目標(biāo)——尤其是這種目標(biāo)是美妙的、神圣的、寄托了我們某種強烈情感的時候，我們常常會忘記達(dá)成這個目標(biāo)的成本。

就個人而言，就是通宵達(dá)旦廢寢忘食樂此不疲，這是你自個兒的事；但對于團(tuán)隊，對于項目呢？“不計一切代價”就是一種蠻干就是瞎搞，后果往往是災(zāi)難性……

另一個很有意思的現(xiàn)象：我們的輿論，我們的文化，是鼓勵“不惜一切代價”是鼓勵“克服重重困難”的，這會讓我們有一種莫名的沖動、一種熱血沸騰的快感。理智和感性天然就是不兼容的？

 

那么，我是反對TDD的？

如果你心里還有這樣的想法，說明你還是沒弄明白我在說什么。

無所謂支持和反對，沒有這樣簡單化的答案。

事實上，你需要的，是做一個成本和收益的分析：針對特定的、具體的項目！

 

沒有一個放之四海而皆準(zhǔn)的準(zhǔn)則。

不同的項目，有不同的要求，應(yīng)該因地制宜的采取相應(yīng)的策略。

 

這樣談下去還是會很空，我以 一起幫 為例。

我為什么要放棄TDD？因為我對這個項目沒有太大的信心，我目前最需要的，是盡快的把項目的原型拿出來，放到市場上進(jìn)行檢驗：大家喜不喜歡，有沒有前景，收集正面的反面的意見反饋……如果大致符合預(yù)期，我就繼續(xù)做下去；否則，就要快速的進(jìn)行調(diào)整。而我現(xiàn)在的人手又非常有限，好吧，其實就我一個人，所有的代碼都得我一個人寫；好在網(wǎng)站出bug問題不是很大，所有的用戶都是種子用戶，他們可以直接的給我反饋而不會因為一兩個bug離我而去……

所以綜合上面種種考慮，我并不需要TDD，至少暫時不需要。也就是說，代碼質(zhì)量差一點就差一點，可以忍受。如果項目擊中了用戶的痛點，我可以以后花更大的代價來“補”；如果項目針對的是一個“偽需求”，我就應(yīng)該盡快止損。

你看，并不是TDD不好，并不是TDD沒用，而是我現(xiàn)在“用不著”——這才是三觀最“正”的，最無懈可擊的理由。·

順便說一下，我現(xiàn)在采取的策略，我把它稱之為“懶人策略”：一開始不寫unit test，但一旦出現(xiàn)bug，fix bug之前，首先寫unit test，然后在fix。（慚愧啊，仔細(xì)想想，這一點我都沒完全做到，(⊙﹏⊙)b）

 

其實我覺得呀，當(dāng)然僅僅是“覺得”了，大多數(shù)的“大?！眰?，其實是明白這一點的——雖然他們從沒有像我這樣系統(tǒng)明確的表述出來。

我這樣推斷的原因是：現(xiàn)實中確實沒有太多TDD實踐的項目。

實踐TDD的機會其實是非常渺茫的，就我目前能想到的：

  1. 開發(fā)團(tuán)隊，尤其是架構(gòu)師必須有相當(dāng)?shù)乃健Ｎ以?a class="postTitle2" style="margin: 0px; padding: 0px; color: rgb(0, 0, 0);">架構(gòu)之路（三） 單元測試就講過：單元測試不是那么好寫的！凡是可（易于）測試的代碼，一定是“低耦合”的，模塊之間是具有相當(dāng)大的“獨立性”的，不然相互牽連，將非常難以測試。而隨著業(yè)務(wù)邏輯的耦合度（復(fù)雜度）越來越高，解耦的難度也就越來越高。反正據(jù)我的觀察，一般的開發(fā)團(tuán)隊根本hold不住。有時候想想，非常之詭異：耦合度不高的項目，其實又沒有多大的必要做TDD？

  2. 項目負(fù)責(zé)人對項目能夠長期存活具有強大的信心。TDD的實踐，是前期投資，后期收獲。相當(dāng)長一段時間，你都會覺得寫單元測試非常無聊，只有到了后期，業(yè)務(wù)邏輯越來越復(fù)雜，到處都是千絲萬縷的聯(lián)系，牽一發(fā)而動全身，經(jīng)常一改動單元測試就跑不過的時候，你才會覺得“咦？這玩意還真的有用呢！”但是，注意這個但是，項目負(fù)責(zé)人有沒有足夠的信心：這個項目能撐到那個時候？！市場朝秦暮楚變化無常，幾乎所有人都是走一步看一步，摸著石頭過河，哪里能顧得那么長遠(yuǎn)？

  3. 項目從一開始就不趕工期，允許使用大量（至少是雙倍）的時間來寫單元測試。就算是我有信心這個項目沒問題，但時間允許不允許？商場上爭的就是一個先手，快魚吃慢魚，要快，要搶先占領(lǐng)陣地。這就和強行軍一樣，確實有很多問題，不如步步為營穩(wěn)妥，沒有重武器，會有掉隊減員，部隊非常虛弱……但只要先到達(dá)陣地，其他一切都在所不惜。

所以，我非常好奇，究竟有多少童鞋真正參與過一個嚴(yán)格按TDD模式實施項目？

想在園子里寫點東西已經(jīng)很久了，但一直沒有落筆，忙著做 一起幫 的開發(fā)直播，還有些軟文做推廣，還要做奶爸帶孩子，還要……好吧，我承認(rèn)，真正的原因是：

太特么的難寫了！

 

但再難寫也要寫啊，要等到“能寫好了再寫”，怕是黃花菜都涼了——尤其是技術(shù)類文章，時效性非常強的。

剛好壇子里這篇博客：關(guān)于拒絕測試驅(qū)動開發(fā)（NoTDD），看評論爭議不小，而這個問題也是我最想寫的，所以，蹭個熱點，呵呵。

 

其實我很好奇，博客下面熱烈討論的童鞋，有多少人是真正的在項目中堅持過TDD的。

我公司里的項目，從來沒有哪一個項目是要求TDD、能夠TDD的；我自己的項目，堅持過TDD一段時間，而且應(yīng)該是非常久的一段時間，尤其是Entity部分，但現(xiàn)在我基本上都已經(jīng)放棄了。

為什么呢？

可以洋洋灑灑千言萬語，也可以簡簡單單三個字：不劃算。

 

其實不僅僅是TDD，還包括三層架構(gòu)、設(shè)計模式、ORM等等這些東西，存在大量的爭論，莫衷一是：說它好的把它捧到了天上去，說它不行的批得它體無完膚，雙方都有大牛為其站臺，都可以一二三四五的列出長長的清單，而且每一條都很有道理……

當(dāng)討論變成了一種辯論，當(dāng)辯論變成了一種罵戰(zhàn)，最后拼的就是誰的態(tài)度更堅決，誰的言辭更犀利，誰的聲音更大……所以雙方的觀點更加的偏激、對立，而這其實無助于我們客觀冷靜的來分析問題。

 

說理太枯燥了點，還是聽飛哥講故事吧，呵呵。

 

最早，我剛接觸“設(shè)計模式”。什么玩意兒??？！整本書，就一個感覺，“脫了褲子放屁”。明明一個對象，new一下不就OK了么？什么Factory啊Builder啊，搞毛線呢？所以一直是云里霧里的，包括那些開閉原則、依賴倒置，都似懂非懂的，沒幫上我什么忙。

直到有一天，也不知是在哪里，我看到了三個字“上下文”，或者說一句話，大意是：只有理解了上下文，理解了設(shè)計模式想要解決的“問題”，你才能真正的理解設(shè)計模式。不知道是不是那時候積累也差不多了，茅塞頓開恍然大悟！

我在架構(gòu)之路（一）：目標(biāo)里說過：設(shè)計模式是藥，看評論其實很多同學(xué)沒有理解，對照這句話看能不能明白過來：理解了設(shè)計模式想要解決的“問題”……？要解決的問題就是“病”，沒病就不要亂吃藥；同理，沒有“問題”，你也不要亂用設(shè)計模式。

 

一通百通。

所以從最基礎(chǔ)的面向?qū)ο蟆⒌饺龑蛹軜?gòu)、ORM、以及敏捷開發(fā)、TDD……，所有這些概念方法，本質(zhì)上都是要解決問題的，而且基本上也是能夠解決問題的。

而你，認(rèn)為它“沒用”，其實最大的原因是：你還沒碰到這方面的問題。

在這里，大家一定要區(qū)分兩個概念：“它解決不了問題”和“它（對我）沒用”。還是用藥做比喻，“這藥治不了病”，和“這藥（對我）沒用”是兩個概念。而且尤其要注意的是這兩個字：對我。

換到項目中，就是這種架構(gòu)這種開發(fā)模式，適不適合這個項目，能不能解決這個項目開發(fā)中遇到的問題。

其實之前我也看到過類似的提法，比如：xxx適合“大”項目。但用“大”和“小”來區(qū)分項目，毛糙了一些，很多時候，并不見得正確。最正確的做法是：你了解項目的特點，同時也了解各種模式的優(yōu)劣，從而能夠正確的匹配和選擇。當(dāng)然，這是一個非常龐大的話題，這里沒辦法展開了。

 

好，上面我們提到了“優(yōu)劣”，所謂優(yōu)勢和劣勢，但其實，這個提法并不準(zhǔn)確。優(yōu)勢，大家都可以承認(rèn)，解決了問題嘛；但劣勢……什么叫做劣勢？不服……

我更愿意用另一個詞：成本。

“天下沒有免費的午餐”。

這是一個經(jīng)濟(jì)學(xué)上的諺語。一提到這話，我就想起我大學(xué)的時候坐在教室里聽老師講《西方經(jīng)濟(jì)學(xué)》……往事歷歷在目，誰曾想，我會是今天這個樣子？

再說點題外話吧。

【野生程序員】：優(yōu)先招聘是意氣之作，但并非完全意氣用事，在我該不該轉(zhuǎn)行？（一）野生程序員的優(yōu)勢一文里，我就較為詳細(xì)的闡述了野生程序員的優(yōu)勢。簡單的說：做架構(gòu)，做項目管理，需要一個更宏大的視野，而不僅僅是二進(jìn)制和計算機原理。

這里，我們還是回過頭來看，什么叫做“天下沒有免費的午餐”？不要理解為“做人不要貪心以免上當(dāng)”之類的喲！你可以理解為：做任何事情都需要成本。但我更喜歡另一種說法：凡是選擇，必有代價。

 

具體到項目中，不管（注意是不管，無論，隨便……）你選擇是不是遵循TDD的規(guī)范要求，只要你選擇了，就必然有代價：

  • 不使用TDD，就會在代碼的重構(gòu)、維護(hù)、健壯性等方面付出代價；

  • 使用TDD，就會在測試代碼的開發(fā)和維護(hù)上付出額外的代價。

無論你怎么選，一定是要付出“代價”的。換言之，代碼的“低耦合”“可測試”“便于重構(gòu)”……不可能從天上掉下來，一定是有成本的！

 

這本來是一個最簡單不過的道理。

然而，當(dāng)我們迫切的想達(dá)到一種目標(biāo)——尤其是這種目標(biāo)是美妙的、神圣的、寄托了我們某種強烈情感的時候，我們常常會忘記達(dá)成這個目標(biāo)的成本。

就個人而言，就是通宵達(dá)旦廢寢忘食樂此不疲，這是你自個兒的事；但對于團(tuán)隊，對于項目呢？“不計一切代價”就是一種蠻干就是瞎搞，后果往往是災(zāi)難性……

另一個很有意思的現(xiàn)象：我們的輿論，我們的文化，是鼓勵“不惜一切代價”是鼓勵“克服重重困難”的，這會讓我們有一種莫名的沖動、一種熱血沸騰的快感。理智和感性天然就是不兼容的？

 

那么，我是反對TDD的？

如果你心里還有這樣的想法，說明你還是沒弄明白我在說什么。

無所謂支持和反對，沒有這樣簡單化的答案。

事實上，你需要的，是做一個成本和收益的分析：針對特定的、具體的項目！

 

沒有一個放之四海而皆準(zhǔn)的準(zhǔn)則。

不同的項目，有不同的要求，應(yīng)該因地制宜的采取相應(yīng)的策略。

 

這樣談下去還是會很空，我以 一起幫 為例。

我為什么要放棄TDD？因為我對這個項目沒有太大的信心，我目前最需要的，是盡快的把項目的原型拿出來，放到市場上進(jìn)行檢驗：大家喜不喜歡，有沒有前景，收集正面的反面的意見反饋……如果大致符合預(yù)期，我就繼續(xù)做下去；否則，就要快速的進(jìn)行調(diào)整。而我現(xiàn)在的人手又非常有限，好吧，其實就我一個人，所有的代碼都得我一個人寫；好在網(wǎng)站出bug問題不是很大，所有的用戶都是種子用戶，他們可以直接的給我反饋而不會因為一兩個bug離我而去……

所以綜合上面種種考慮，我并不需要TDD，至少暫時不需要。也就是說，代碼質(zhì)量差一點就差一點，可以忍受。如果項目擊中了用戶的痛點，我可以以后花更大的代價來“補”；如果項目針對的是一個“偽需求”，我就應(yīng)該盡快止損。

你看，并不是TDD不好，并不是TDD沒用，而是我現(xiàn)在“用不著”——這才是三觀最“正”的，最無懈可擊的理由。·

順便說一下，我現(xiàn)在采取的策略，我把它稱之為“懶人策略”：一開始不寫unit test，但一旦出現(xiàn)bug，fix bug之前，首先寫unit test，然后在fix。（慚愧啊，仔細(xì)想想，這一點我都沒完全做到，(⊙﹏⊙)b）

 

其實我覺得呀，當(dāng)然僅僅是“覺得”了，大多數(shù)的“大牛”們，其實是明白這一點的——雖然他們從沒有像我這樣系統(tǒng)明確的表述出來。

我這樣推斷的原因是：現(xiàn)實中確實沒有太多TDD實踐的項目。

實踐TDD的機會其實是非常渺茫的，就我目前能想到的：

  1. 開發(fā)團(tuán)隊，尤其是架構(gòu)師必須有相當(dāng)?shù)乃健Ｎ以?a class="postTitle2" style="margin: 0px; padding: 0px; color: rgb(0, 0, 0);">架構(gòu)之路（三） 單元測試就講過：單元測試不是那么好寫的！凡是可（易于）測試的代碼，一定是“低耦合”的，模塊之間是具有相當(dāng)大的“獨立性”的，不然相互牽連，將非常難以測試。而隨著業(yè)務(wù)邏輯的耦合度（復(fù)雜度）越來越高，解耦的難度也就越來越高。反正據(jù)我的觀察，一般的開發(fā)團(tuán)隊根本hold不住。有時候想想，非常之詭異：耦合度不高的項目，其實又沒有多大的必要做TDD？

  2. 項目負(fù)責(zé)人對項目能夠長期存活具有強大的信心。TDD的實踐，是前期投資，后期收獲。相當(dāng)長一段時間，你都會覺得寫單元測試非常無聊，只有到了后期，業(yè)務(wù)邏輯越來越復(fù)雜，到處都是千絲萬縷的聯(lián)系，牽一發(fā)而動全身，經(jīng)常一改動單元測試就跑不過的時候，你才會覺得“咦？這玩意還真的有用呢！”但是，注意這個但是，項目負(fù)責(zé)人有沒有足夠的信心：這個項目能撐到那個時候？！市場朝秦暮楚變化無常，幾乎所有人都是走一步看一步，摸著石頭過河，哪里能顧得那么長遠(yuǎn)？

  3. 項目從一開始就不趕工期，允許使用大量（至少是雙倍）的時間來寫單元測試。就算是我有信心這個項目沒問題，但時間允許不允許？商場上爭的就是一個先手，快魚吃慢魚，要快，要搶先占領(lǐng)陣地。這就和強行軍一樣，確實有很多問題，不如步步為營穩(wěn)妥，沒有重武器，會有掉隊減員，部隊非常虛弱……但只要先到達(dá)陣地，其他一切都在所不惜。

所以，我非常好奇，究竟有多少童鞋真正參與過一個嚴(yán)格按TDD模式實施項目？

http://www.cnblogs.com/freeflying/p/7080244.html