也談TDD，以及三層架構、設計模式、ORM……：沒有免費的午餐

太特麼的難寫了！

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

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

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

為什麼呢？

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

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

當讨論變成了一種辯論，當辯論變成了一種罵戰，最後拼的就是誰的态度更堅決，誰的言辭更犀利，誰的聲音更大……是以雙方的觀點更加的偏激、對立，而這其實無助于我們客觀冷靜的來分析問題。

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

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

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

一通百通。

是以從最基礎的面向對象、到三層架構、ORM、以及靈活開發、TDD……，所有這些概念方法，本質上都是要解決問題的，而且基本上也是能夠解決問題的。

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

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

換到項目中，就是這種架構這種開發模式，适不适合這個項目，能不能解決這個項目開發中遇到的問題。

其實之前我也看到過類似的提法，比如：xxx适合“大”項目。但用“大”和“小”來區分項目，毛糙了一些，很多時候，并不見得正确。最正确的做法是：你了解項目的特點，同時也了解各種模式的優劣，進而能夠正确的比對和選擇。當然，這是一個非常龐大的話題，這裡沒辦法展開了。

好，上面我們提到了“優劣”，所謂優勢和劣勢，但其實，這個提法并不準确。優勢，大家都可以承認，解決了問題嘛；但劣勢……什麼叫做劣勢？不服……

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

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

這是一個經濟學上的諺語。一提到這話，我就想起我大學的時候坐在教室裡聽老師講《西方經濟學》……往事曆曆在目，誰曾想，我會是今天這個樣子？

再說點題外話吧。

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

具體到項目中，不管（注意是不管，無論，随便……）你選擇是不是遵循TDD的規範要求，隻要你選擇了，就必然有代價：

不使用TDD，就會在代碼的重構、維護、健壯性等方面付出代價；

使用TDD，就會在測試代碼的開發和維護上付出額外的代價。

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

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

然而，當我們迫切的想達到一種目标——尤其是這種目标是美妙的、神聖的、寄托了我們某種強烈情感的時候，我們常常會忘記達成這個目标的成本。

就個人而言，就是通宵達旦廢寝忘食樂此不疲，這是你自個兒的事；但對于團隊，對于項目呢？“不計一切代價”就是一種蠻幹就是瞎搞，後果往往是災難性……

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

那麼，我是反對TDD的？

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

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

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

沒有一個放之四海而皆準的準則。

不同的項目，有不同的要求，應該因地制宜的采取相應的政策。

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

是以綜合上面種種考慮，我并不需要TDD，至少暫時不需要。也就是說，代碼品質差一點就差一點，可以忍受。如果項目擊中了使用者的痛點，我可以以後花更大的代價來“補”；如果項目針對的是一個“僞需求”，我就應該盡快止損。

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

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

其實我覺得呀，當然僅僅是“覺得”了，大多數的“大牛”們，其實是明白這一點的——雖然他們從沒有像我這樣系統明确的表述出來。

我這樣推斷的原因是：現實中确實沒有太多TDD實踐的項目。

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

項目負責人對項目能夠長期存活具有強大的信心。TDD的實踐，是前期投資，後期收獲。相當長一段時間，你都會覺得寫單元測試非常無聊，隻有到了後期，業務邏輯越來越複雜，到處都是千絲萬縷的聯系，牽一發而動全身，經常一改動單元測試就跑不過的時候，你才會覺得“咦？這玩意還真的有用呢！”但是，注意這個但是，項目負責人有沒有足夠的信心：這個項目能撐到那個時候？！市場朝秦暮楚變化無常，幾乎所有人都是走一步看一步，摸着石頭過河，哪裡能顧得那麼長遠？

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

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

那麼，TDD是不是就不值得學習了呢？

當然不是的！

+++++++++++++++++++++

真的頂不住了！

12點了，超級 =_=

展開寫還有很長很長，強寫腦力也跟不上了。先這樣吧，有時間我們下次再聊，晚安，各位。

呵呵，偶然中發現的，小小的一個成就，紀念一下。