2014年我一直從事在敏捷實踐諮詢項目，這也是我很有收穫的一年，特別是諮詢項目的每一點改變，無論是代碼質量的提升，仍是自組織團隊的建設，都能讓咱們感到欣慰。涉及人的問題都是複雜問題，改變人，改變一個組織是個更復雜問題，這裏可能涉及不少的非技術，非能力問題。程序員
在2014年12月我在某企業內部推行TDD(測試驅動開發)培訓，一共分4個課時完成一個特定需求的例子，看着你們一步一步的加深對TDD的理解，直到2014-12-31，也是2014的最後一天下午培訓完TDD課程，通過一系列的總結事後，某參與人員說道：「單元測試須要寫更多的代碼，可是從項目的整體來看，一個字‘值’.」。緊接着後來某參與人員發了一份其關於TDD培訓感覺，名叫《TDD隨想錄》也將是本文的主題，本文或許更好的說是轉載此文，瞭解一個開發人員對TDD瞭解的心路歷程，以及對TDD的見解。github
注：原文發佈與hxfirefox的https://github.com/hxfirefox/blog/blob/master/TDD/TDD%E9%9A%8F%E6%83%B3%E5%BD%95.md.編程
原文以下：設計模式
TDD隨想錄
謹以本文獻給TDD的開創者與傳播者安全
本文純屬我的經歷，若有雷同純屬巧合app
我從不以爲本身是一個好的程序員，甚至可能連合格都談不上，不過在心裏深處我卻渴望着在編程這件事上得到成功。框架
惋惜每次審視本身寫的暫且稱之爲代碼的東西，都會有挫折感，想重構卻又感受盤根錯節，難如下手;想重寫卻又感受本身好不容易寫出來的，也花了很多心思，就這樣丟棄心有不甘。post
也曾思考過如何才能寫好代碼，有段時間以爲只有嚴格符合編程規範的代碼纔是好代碼進而如同遵照戒律同樣地字字斟酌，還有段時間以爲只有用上設計模式才能稱之優秀代碼進而非模式不用，一切套用模式。不過這些都沒有讓我走出開發的迷霧，永遠是加不完的班，修不完的bug。
到底是否有一種方法可以讓我撥開開發迷霧，至少可以讓我可以輕鬆地修剪代碼，下降bug發生率，那麼我以爲這種方法在我身上就是成功的。
初次接觸到TDD是經過公司內部的「代碼大全培訓」，猶如十月革命中阿芙勒爾號的一聲炮響，爲我打開了軟件開發的視野。先測試後開發，小步迭代，持續集成，這些新名詞忽然涌進了個人大腦，既新鮮又晦澀。猶如人的幼年容易犯幼稚病同樣，初識這些新名詞就覺得了解了TDD的一切，結果卻發如今實踐過程當中到處碰壁，舉步維艱。對TDD中每一個環節真正隱含的開發思想的囫圇吞棗，讓這一次的培訓只在我腦中留下TDD的一個模糊身影:爲軟件開發結下一張安全網。
雖然未領悟精髓，但培訓後體驗和直覺告訴我TDD是一條通往我向往的軟件成功的道路，儘管本身摸索前行比較坎坷。很幸運的是團隊得到了隨隊敏捷教練的支持，結對讓我係統地瞭解到了TDD的思想。
測試先行，其實講的是需求邊界，測試不是漫無目的而是精確計算成本的一項活動。測試從何而來，從需求來，需求推演出測試，也規劃出產品邊界，不能反映需求的測試是一種浪費，所以引伸出開發須要講求適當。開發是一項功利性的活動，永遠都在追求盈利，而測試就一條紅線，一旦跨過就意味着虧損。
小步迭代，「讓子彈飛」中有句話很經典:步子要一步一步邁，一步邁大了，咔，容易扯着蛋。代碼堆疊的後遺症是複雜，複雜到沒人願意觸碰，且不停地咒罵這代碼有多爛，這是步子邁太大的真實寫照。TDD講求的小步迭代是寫完一個測試再去寫完一個實現，每一個實現都是經過測試的，如此累加小勝爲大勝，最後全部代碼的收尾也不過是讓最後一個測試經過而已，就是這樣簡單。
重構，這是我最喜歡的部分，爲啥？由於這裏面全部的活動都會要求你去思考，且看上去都像是讓你的代碼向着大師級代碼前進。漂亮的代碼並非堆砌各類技巧，而是在正確的時間，正確的地點作正確的事，重構很容易實現這個目標。重構是一件讓人一旦開始就會欲罷不能的事，會讓開發者在整個開發階段都可以不停地去思考、實踐再思考，直到沒法再添加或刪除一個字母。
持續集成，你終究是須要交付產品的，產品就是客戶須要的價值，就如同廚師終究會端出客人點的大餐同樣，沒有哪一個廚師是把全部食材羅列着呈現給你的，而是混合在一塊兒，蒸煮燉燒，有些食材須要先處理，這樣吃起來才軟硬適中，而有些則是最後下鍋，這樣吃起來才鮮嫩多汁，廚師就是這樣一步步將食材集成起來，每一步的處理都是可用都是有價值的，都是爲後續進行的鋪墊。軟件開發也同樣，持續集成就要保證每一次的完成都是有價值均可覺得後續提供支撐。
寫到這裏也許會有人問你如何知道TDD是真理，是康莊大道，它必定適合每一個人嗎？不，我並不知道，我所寫的一切只是發生在我身上的一段經歷。這段經歷告訴我TDD迫使我去更多的思考，去切割我那些冗長且複雜又不切實際的胡思亂想，把它們碾碎成一個個小片斷，提煉，過濾，不斷累加，最終變成最接近交代價值的東西，而這最終的東西正是我一直在追求的那個成就感。若是想要知道TDD是否是適合本身，最好的辦法就是去嘗試，去親身體驗一下，不管好壞也許你能得到比我更多的體會。
博主總結
TDD並非萬能的，可是TDD也不是一無可取的，重要的是用方法論的人，引入某同事一句話：
站在教學的角度來說，我仍是很推崇TDD的，TDD是一個很好的思惟框架，若是非要教人一個思惟框架的話就得教TDD， 否則人會瞎碰，不思考，不總結，不結果導向，靠靈感編程，憑直覺設計，撞大運修bug。最糟糕的是由於沒有好的習慣 會連續不斷的發生靈異現象。同一道題，習慣很差的人作，總能作出無數種新問題來。並且問題套問題，給他解決要浪費 我半天時間，若是他學會了TDD出的錯只在最近一個引入的變化裏，就好糾正多了。甚至他本身都能糾正。
博主非常贊同該同事的見解，而且做者認爲：
tdd重要的不是測試代碼自己，是解決問題的思惟，也許能夠泛化，哪怕沒測試，若是可以作到快速驗證，反饋，價值的 穩定疊加，有足夠信心，也何嘗不可。也許你會說測試能夠cover功能，那麼若是隻有這一點的話，我更喜歡BDD (behavior-driven development)，由於這具備用戶最終的使用價值。若是你說快速定位bug，咱們我更傾向於BDD (bug-driven development，自創的)。這寫都是TDD的結果致使的好處所在，而價值反饋思惟纔是實現TDD背後原理。 TDD驅使咱們以結果導向，使得咱們簡單設計(並非無設計)，平常重構咱們的代碼庫，注重交付價值流穩定疊加。
世上並無放之四海皆準的法則，TDD好壞在於你的判斷，方法論的主體在於使用的人，本文並不會給你一個完美的答案，這須要你本身的發掘。