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

想在園子裏寫點東西已經好久了，但一直沒有落筆，忙着作 一塊兒幫 的開發直播，還有些軟文作推廣，還要作奶爸帶孩子，還要……好吧，我認可，真正的緣由是：

太特麼的難寫了！

 

但再難寫也要寫啊，要等到「能寫好了再寫」，怕是黃花菜都涼了——尤爲是技術類文章，時效性很是強的。

恰好罈子裏這篇博客：關於拒絕測試驅動開發（NoTDD），看評論爭議不小，而這個問題也是我最想寫的，因此，蹭個熱點，呵呵。

 

其實我很好奇，博客下面熱烈討論的童鞋，有多少人是真正的在項目中堅持過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的機會實際上是很是渺茫的，就我目前能想到的：

1. 開發團隊，尤爲是架構師必須有至關的水平。我在架構之路（三） 單元測試就講過：單元測試不是那麼好寫的！凡是可（易於）測試的代碼，必定是「低耦合」的，模塊之間是具備至關大的「獨立性」的，否則相互牽連，將很是難以測試。而隨着業務邏輯的耦合度（複雜度）愈來愈高，解耦的難度也就愈來愈高。反正據個人觀察，通常的開發團隊根本hold不住。有時候想一想，很是之詭異：耦合度不高的項目，其實又沒有多大的必要作TDD？
2. 項目負責人對項目可以長期存活具備強大的信心。TDD的實踐，是前期投資，後期收穫。至關長一段時間，你都會以爲寫單元測試很是無聊，只有到了後期，業務邏輯愈來愈複雜，處處都是千絲萬縷的聯繫，牽一髮而動全身，常常一改動單元測試就跑不過的時候，你纔會以爲「咦？這玩意還真的有用呢！」可是，注意這個可是，項目負責人有沒有足夠的信心：這個項目能撐到那個時候？！市場朝三暮四變化無常，幾乎全部人都是走一步看一步，摸着石頭過河，哪裏能顧得那麼長遠？
3. 項目從一開始就不趕工期，容許使用大量（至少是雙倍）的時間來寫單元測試。就算是我有信心這個項目沒問題，但時間容許不容許？商場上爭的就是一個先手，快魚吃慢魚，要快，要搶先佔領陣地。這就和強行軍同樣，確實有不少問題，不如步步爲營穩妥，沒有重武器，會有掉隊減員，部隊很是虛弱……但只要先到達陣地，其餘一切都在所不惜。

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

 

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

固然不是的！

 

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

 

真的頂不住了！

12點了，超級 =_=

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

 

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