l

2016年2月4日 星期四

為什麼看不懂Kent Beck的Test-Driven Development By Example?

Feb. 03 23:26~Feb. 04 00:29

螢幕截圖 2016-02-04 00.19.55

 

先打個廣告,二月份【看板方法與精實開發實作班】確定開課,早鳥優惠延到2月5日。歡迎鄉民們發揮年終獎金最佳使用方法--提升自己的競爭力 XD。

***

Kent Beck是「發明 發現」TDD的人,不少鄉民學習TDD都讀過Kent Beck的《Test-Driven Development By Example》這本書,但是很多人都覺得很難從書中去理解與實踐TDD。為什麼一位大師寫的書這麼難以親近?

如果鄉民讀過Kent Beck與Martin Fowler這兩位大師的書,該會發覺他們兩位的寫作風格剛好相反。Kent Beck的書像《Extreme Programming Explaine》、《Implementation Patterns》、《Test-Driven Development By Example》等,言簡意賅,點到為止,感覺是寫給「知音」看的,而不是寫給一般鄉民閱讀。Martin Fowler剛好相反,除了他的第一本書《Analysis Patterns》內容比較玄妙以外,其他像是《UML Distilled》、《Refactoring》、《Patterns of Enterprise Application Architecture》等書都算寫得相對平易近人。

Kent Beckt這本TDD的書分成三部分:

  • The Money Example
  • The xUnix Example
  • Patterns for Test-Driven Development

今天只談第一部分:The Money Example。最近Teddy因為要製作「軟體重構入門實作班」的教材,花了點時間把手邊的XP系列和TDD/BDD以及Refactoring的書重新看過,順手做了一次The Money Example。之前讀這本書的時候只是用看的,沒有照著書上一步、一步慢慢操作,感覺真的差很多。這次做完練習之後,發現有幾點因素可能造成許多人覺得對這本書「無感」:

  • 步驟太瑣碎:Kent Bect用近乎「胚胎」等級(比幼幼班還原始XD)的手法來逐步演化這個例子,應該有不少鄉民會覺得:「難道欲練神功,一定要揮刀自宮嗎?(先把自己變笨再來TDD?!)」。這個疑問其實Kent Beck在書中已經自己解答了,他說:「不是要告訴大家真正開發軟體的時候要採用這樣的步驟,但是你必須要具備採用這種步驟的(分析、拆解)能力」。
  • 神來一筆不少鄉民都知道「TDD不是關於測試,而是關於設計」,但是卻鮮少有鄉民說得清楚「關於設計」這一段,弄到最後把TDD搞成測試。仔細看Kent Beck在書中的Money範例,他偷偷套用了大大小小不等的許多設計,像是Value Object(design pattern)、Extract Superclass(refactoring)、Pull Up Field(refactoring)、Pull Up Method(refactoring)、Factory Method(design pattern)還有Expression(metaphor)等。一般人沒有大師的功力,怎麼可能從無到有搞出這些東西?真的是叔叔有練過,小朋友很難學啊。
  • 不需要建模(modeling):最後一點,也是非常關鍵的一點,就是Kent Bent在開始展示這個例子的時候,只給了一個報表當作原始需求,然後用一個To Do List(代辦事項)當作TDD的task。這個To Do List隨著TDD的進行會動態變化。如果鄉民們有看過其他人的TDD範例,一開始大多會有一個簡單的domain model(領域模型),然後再用TDD的方式讓domain model中每一個類別(class)的介面(責任)與關聯變得清楚。但Kent Beck的例子沒有,直接「隔空抓藥」。少了一個表示某種全域觀點的domain model,讓讀者難以想像最後TDD長出來的結果是什麼。

***

老實說Teddy在2003年第一次讀這本書的時候能力不足,也沒看懂,只是覺得Kent Beck也太神了一點,要練到哪一天才能有他這樣的功力啊。為什麼閒來沒事要研究Kent Beck的書難在哪裡?不是吃飽沒事幹,也不是要做什麼學術研究。而是唯有把這些細節弄清楚、弄通,才有辦法在教別人的時候從一個更高的視野來看待TDD,助於學習之後的落實,而不要只侷限於形式與工具的層面。

這段路還沒走完,但已經看到曙光。

***

友藏內心獨白:還說不是太閒。

3 則留言:

  1. 想起這個演講 Ian Cooper: TDD, where did it all go wrong https://vimeo.com/68375232
    也是回到大師懷抱

    回覆刪除
  2. 實在很無言,連這麼簡單的書都不易理解的話,那隨便一本大學等級的數學教科書不就一輩子讀不懂?

    回覆刪除
  3. 說到建模,因為那並不只關於設計階段/解決方案領域,同時也與分析階段/問題領域有關。
    所以字彙表的統一、領域模型的借用及修改、企業應用架構及相關模式的運用,還是不可少的溝通手段。

    大師的隔空抓藥,大概只能說是真的有練過。
    還是多多練工、細細體會來累進實力比較實在。

    回覆刪除