太特麼的難寫了！

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

剛好罈子裡這篇部落格：關於拒絕測試驅動開發（NoTDD），看評論爭議不小，而這個問題也是我最想寫的，所以，蹭個熱點，呵呵。

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

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

為什麼呢？

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

程式設計師學習交流群：702895049。群裡有分享的視訊，還有思維導圖
群公告有視訊，都是乾貨的，你可以下載來看。主要分享分散式架構、高可擴充套件、高效能、高併發、效能優化、Spring boot、Redis、ActiveMQ、Nginx、Mycat、Netty、Jvm大型分散式專案實戰學習架構師視訊。

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

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

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

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

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

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

一通百通。

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

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

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

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

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

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

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

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

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

再說點題外話吧。

【野生程式設計師】：優先招聘是意氣之作，但並非完全意氣用事，在我該不該轉行？（一）野生程式設計師的優勢一文裡，我就較為詳細的闡述了野生程式設計師的優勢。簡單的說：做架構，做專案管理，需要一個更巨集大的視野，而不僅僅是二進位制和計算機原理。

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

程式設計師學習交流群：702895049。群裡有分享的視訊，還有思維導圖
群公告有視訊，都是乾貨的，你可以下載來看。主要分享分散式架構、高可擴充套件、高效能、高併發、效能優化、Spring boot、Redis、ActiveMQ、Nginx、Mycat、Netty、Jvm大型分散式專案實戰學習架構師視訊。

具體到專案中，不管（注意是不管，無論，隨便……）你選擇是不是遵循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點了，超級 =_=

展開寫還有很長很長，強寫腦力也跟不上了。不多說了，分享一波資料 有需要的就進群獲取：程式設計師學習交流群：702895049。群裡有分享的視訊，還有思維導圖
群公告有視訊，都是乾貨的，你可以下載來看。主要分享分散式架構、高可擴充套件、高效能、高併發、效能優化、Spring boot、Redis、ActiveMQ、Nginx、Mycat、Netty、Jvm大型分散式專案實戰學習架構師視訊。