2014年6月28日 星期六

活動:Tainan.py x MOSUT 2014 6 月聚會

歡迎參加本月的 Tainan.py !



恰逢 wen 正在研讀 regular expression,這次聚會日期未定就收到他的投稿 XD
本演講算是 wen 的筆記與心得,投影片本身非常有參考價值


相關補充:

  • Sam 在公司內部介紹過的 regular expression 投影片
  • float 有補充 online tools,我喜歡這一個: Debuggex
  • Arnan 分享了良葛葛的文章: Regex 的強大與哀愁
  • pyMOTW 對 re 的 介紹 (很好的 cook book)
最後再補充「PythonVerbalExpressions」:(寫法可以變成下述方式)
# Create an example of how to test for correctly formed URLs
verbal_expression = VerEx()
tester = (verbal_expression.
            start_of_line().
            find('http').
            maybe('s').
            find('://').
            maybe('www.').
            anything_but(' ').
            end_of_line()
)

# Create an example URL
test_url = "https://www.google.com"

# Test if the URL is valid
if tester.match(test_url):
    print "Valid URL"

#Print the generated regex
print tester.source() # => ^(http)(s)?(\:\/\/)(www\.)?([^\ ]*)$



第二場演講是 kuku 投稿的「蟒蛇大戰,Bj4」
(最近可能由於 hychen 的關係,大家講話都很 Bj4)
講題涵蓋 psyco, Unladen-swallow, PyPy, Pymoyhoa, Pyston, Numba, Nitrous, Cython, Shed-skin ...
這種題目很明顯是資深愛好者才有辦法講的 ... Orz

相關資料:
  • hackpad 上的 筆記 (來自 bj4 聚會)
  • 投影片 (待補)




本次 聚 餐會的主角




由於日前台南黑客松的活動甫結束,索性邀請參加過的朋友過來一起分享心得
我分享了「用路人小幫手x回報大改造」目前這個專案的情況如下:
  • 台南路平、路證 API
    • 暫時為關掉狀態,有持續維護開發的打算
    • 需要找人一起運用「工人智慧」完善路平專案的資料
  • 回報 API
    • 開放中,也會持續開發
  • Android App
    • 由原開發者小宋作為個人興趣的專案邊學習邊開發
    • github repo
  • iOS App
    • 徵求有興趣的開發者與我們聯絡
    • (開發者 Awei Kuo 有與我們聯絡)



Kiang 則分享了自己做的「台南市議員觀測中心」
  • http://k.olc.tw/tncc/
  • 透過視覺化/整理過資料的介面,議員的所作所為更加能夠被民眾檢視
Kiang 亦表達想要參選台南市議員的意願
意圖透過「公開透明」化的方式來參政
有興趣的朋友可以到他的 個人網站 看看!



活動最後收到智程投稿推 MOOC 學習坑的閃電秀:

好多好棒的課程?不一起學習嗎? FB 互相推坑社團


不嘴砲,在台南累積待了八年的我,不猶豫地的捐了 2k 給 Kiang
希望 Kiang 能夠達到自己給自己設立的參選門檻:20萬的捐款
(他會將捐款結餘再捐給 開放文化基金會


2014年6月25日 星期三

台南黑客松:用路人小幫手 x 回報大改造

爆肝了幾天,py.Tainan 在 2014 台南黑客松拿到好成績!
(圖片來自 Punnode 的報導)



此次台南黑客松滿足了「台南」、「政府」、「Open Data」的元素
一直嘴砲說改天要跳 g0v 坑的我,只能責無旁貸的參戰下去了 XD

儘管已經硬拉映瑋幫忙設計 APP,評估起來團隊組成還是不夠全面
於是就在 FB 徵人,想不到馬上就找到阿男與小宋 <=熱血地搭高鐵來台南!


題目發想


檢視過台南市政府提供的開放資料後並沒有很大的共鳴
又考量到如果與他人選了同樣的主題,在有限的時間內並沒有做得比別人好的本錢
索性從自身經驗開始發想 ...

「台南有些路段,路面真他媽的不平 .... 」

由於遇到這種路段,發自內心會真的很生氣
就決定做此題目了!(Anger-Driven Development)

於是我進行以下 survey ,了解到市政府對路平專案、路證核發、交通事件回報 ... 的做法
並發現以下問題:

  • 政府有做事,但是民眾不知道
    • 因為不知道,所以無從監督政府的執行
      • 然後就做得很爛
  • 路平、路證、交通事故的資訊散佈在政府的各網站
  • (我)作為民眾不會想知道市政府底下各單位的權責業務範圍,只希望當下問題能被解決
    • 想要查詢的資訊希望能夠即時得知
    • 想要回報的問題,要有便捷的管道可以使用
  • 台南市的 線上即時服務系統 不好使用


Hack Hack Hack


為了解決上述問題,我決定採用以下方式來 Happy Hacking

  • 沒給路平、施工、交通相關的 API ? ... 那就自幹吧!
  • 回報頁面太難用? ... 那也幫政府自幹出 API 好了!
  • 全民通報 APP (民眾版)太難用? ... 乾脆也自幹一個!
    • 需要從民眾的「使用情境」出發
    • 此產品將應用自幹的 API ,讓大家知道 Open Data 後可以有什麼改變

構思至此為止,之後我除了帶團隊成員一起去吃琴牛肉湯以外
大概就沒什麼貢獻了 XDDDD


阿男是台南少數我知道有用 Python 寫 Web 的朋友(之前用 pylons !!)
他這次也毫無意外的使用 ...
呃 ... nodejs + phantomjs + notepad++ 實作出最重要的路平、路證 API
(證明了寫 python 的人也是很喜歡擁抱其他語言的 ... XD )
而且支援了很多我覺得非常重要的投影片


映瑋畢業於成大工設,擁有多年的 iOS 「使用」經驗
儘管沒有設計過 APP,被我凹了以後,短時間內也能幫忙設計出質量俱佳的 APP
重點是 ... 她不會被「架構」、「Open Data」... 等等的術語迷惑
設計能夠從使用者的情境出發!
例如:相簿樣板、標籤、分享到 Facebook 的概念都是由她提出


研替中的小宋本行不在 APP 開發,這次完全是熱血衝下來,邊學邊改 APP
這次黑客松開發壓力最大的人,鐵定就是他了! XD


我在架構跟目標出來以後,就把台南市線上即時服務系統解構成一系列的回報用 API
並做了一個返樸歸真版的回報 page,以此舉例說明可以這樣使用回報 API


成果


在極度缺乏睡眠的情況下,我們終於完成了第一版的 API 開發
50 % 左右的 APP  功能與完整的 APP 設計
週日早上團隊在一陣忙亂中製作完投影片,就一起抱著快掛的身體前往會場

我們在第四組就上場進行三分鐘的限時簡報
原本準備五分鐘的投影片很明顯講不完 ... Orz  



雖然沒講完頗沮喪,卻因為很早完成簡報,所以能夠放輕鬆地聽聽其他組的報告
以及與場內的熟人聊天、打嘴砲  XD

頒獎時原本是預期得獎機會不大(太早出場 + 沒有完成簡報)
最後卻意外地在 35 組中拿到 No.2 ... T___T

四人累到掛掉後 ... 終於得到了肯定!
我們之後也會買網域,並把 API 整理後再度釋出!

  • 本專案目前 focus 在台南,將來會與 g0v 的專案討論看看怎麼合作
  • 本專案屬性與黑客松同組的 Open311 很像
    • 可以透過 API 串接起來
  • 如果有朋友對於我們設計的 APP 有興趣,可與我們聯絡喔!




隨筆雜記


Day 1 恰巧與主持人穿同一件 T-Shirt .. XDDD

  • data.tainan.gov.tw beta 使用 ckan 架設!(python!!)
  • 比賽前我以為只有 40 人參賽 ... 
    • 怎麼算都很有機會得獎 XD
    • 結果第一天看到有 39 隊上百人參賽 ... 囧rz
      • 後來想通,在 kktix 上一隊只會顯示出一人 ...
  • 我最看好的百年地圖果然得到很高的評價!!
  • 映瑋被團隊一致選為:最適合當 PM 的人
  • 記得嗎?拍照時那張很大的「第二名」板子
    • 「沒有人」毫不猶豫把第一名的板子留給我們
    • 然後映瑋就把第一第二名的板子對切,當作材料回收走了... o.o"
  • 當初團隊取名 py.Tainan 其實就是 Tainan.py 的倒裝
  • 前同事的隊伍其實有做一個超有梗的拍照樣板 XDDDD
  • 主辦單位直接發現金,非常有誠意!
    • 小宋賺回了台北台南來回高鐵錢 : )




2014年6月14日 星期六

懶人包:TDD is Dead 戰文總整理


日前 Kent Beck, Martin Fowler, DHH 的三強視訊會談 Part V & VI 甫結束並釋出影片 ...
總算為軟體開發界的 TDD 大戰劃下了句點 ...

我恰好這一系列的討論都有空 follow
於是整理本文作為個人筆記,供有興趣的朋友一同討論

# 本文前半部參考 91 前輩先前整理過的 懶人包
# 文長慎入 ... 可能需要 15 分鐘至  1~2 天才能看完這些資料 ... 
# 有朋友要幫本文寫懶人包嗎? => 懶人包的懶人包?? XDDD


圖片引用自 這裡 ,該公司為了紀念 TDD is Dead
將旗下與 TDD 相關的 e-learning albums 組合成 box set
並且限時給予 50% 折扣進行販售 ...



觀戰前的背景知識

Martin Fowler (Refactoring: Improving The Design of Existing Code 的作者) 有寫過這些文章:

介紹 TDD 的文章:

毋庸置疑地, Kent Beck 的 Test-Driven Development by Example 是了解 TDD 起源的好書:

備註:
如果您對 Testing 毫無概念
可以先到 tutorialspoint 下載 testing 的 電子書 建立基本概念



緣起 ... 

(* 表示建議閱讀)

4/23

  • DHH (David Heinemeier Hansson) 在 RailsConf 2014 演講時,先借由減肥無祕方的例子來暗喻軟體開發不該迷信,之後進而開始抨擊若導入 TDD ,則會為了測 unit test 使得設計出來的架構變糟 ... 
  • DHH 發表 TDD is dead. Long live testing. 一文
該事件發生以來,引起軒然大波
因為他是 Rails 作者 + 知名軟體公司創辦人 + 暢銷作家 ( rework / remote )


事出必有因,若往前追究
我們可以知道至少從 2012 開始,就有人嘗試把六角架構 (Hexagonal) 帶入 Rails
以解放 application 對 Rails 的依賴
  • 2013
    • Jim Weirich on Decoupling from Rails
而 DHH 在 2013 年初亦發表過 Dependency Injection is not a virtue 一文
可以看出對於該怎麼使用 Rails ,身為作者是有一定的想法





Part I:  筆戰

4/24

  • Jim OKelly 發表 Why I can TDD and why DHH can't 一文
    • 認為 DHH breaks shit at the wrong boundaries
    • 推薦 Gary Bernhardt 的演講
    • 說明自己為什麼喜歡 TDD,是因為只寫小、目的單純、stateless 的 object,且搭配 FP style 進行 programming ...


4/25

  • Uncle Bob (敏捷開發、Clean Code ... 的作者) 發表 Monogamous TDD 一文
    • 針對 DHH 文章的開頭用詞「Test-First 基本教義」跟相關比喻進行回擊
    • 說明  TDD 的好處
    • 回應 DHH 使用 integration testing:
      • If you can meet my two predicates of trustworthiness and speed, go for it!
    • 最後又點出只做 integration test 的問題
      • 速度慢(DB, GUI)
      • Coverage 較不足

4/29

  • DHH 發表 Test-induced design damage 
    • 聲明 Jim Weirich Demo  的六角架構不適合使用在 Rails 上
      • Rails 有跑 persistent console process ,且對於 test case 有 transaction wrap ... ... 所以速度已經快很多
    • 說明 controller 就是要拿來跑 integration testing 用的,並且針對 Rails/MVC testing 該怎麼做進行指導


4/30

  • Kent Beck 發表 RIP TDD
    • 本文並沒有回應 DHH 的看法跟觀點,但用反串方式說明 TDD 的存在價值
    • 以下為全文截圖



  • Uncle Bob 發表 When TDD doesn't work 
    • 說明 TDD 不適用的情境:
      • The physical boundary, and the layer just in front of that boundary that requires human interaction to fiddle with the results.
      • The test code itself.
    • 說明將 logic 抽出並不會傷害 application:
      • 這是 good design
      • (有回應 TDD is Dead / Test-induced design damage 的意味)


  • Gary Bernhardt 發表 TDD, Straw Men, and Rhetoric 反擊 DHH 新發表的文章
    • 引用 DHH 的 Slow database test fallacy 的內容:The classical definition of a unit test in TDD lore is one that doesn't touch the database. 
      • 作者透過引用相關文獻以說明 TDD 的發展比 Mock 還早,所以早期的 TDD 定義並沒有要求使用 Mock 或是撰寫 isolated unit test ... 
    • 進而對 DHH 的其他不正確陳述進行一連串的反駁 ...
    • 提到自己不滿足於 integration testing 的速度,自己對測試 feedback 回來的需求是 300 ms
      • 說明在此情況下對生產力的提升(更專注、快速測試-> 短時間內得到更多 feedback)
    •  說明自己對 TDD / test isolation 的看法 


5/1  





Part II:  視訊戰



在筆戰的過程中,其實 DHH 已與 KB (Kent Beck) 及 MF (Martin Fowler) 用 skype 聊過天
最後在 ThoughtWorks 的協助下安排一系列的 google hangout 視訊並且釋出影片
MF 有對這一系列影片做整理並且放在他的 部落格

(以下懶人包部分摘錄自 MF 的部落格,強力推薦閱讀 MF 整理的重點)



5/9  

  • Is TDD dead? [Part I]: TDD and Confidence
    • 錄影 (約 30 分)
    • DHH 提出三個問題:
      • Unit test/TDD 的定義
      • 架構系統若使用 mock 會導致 test-induced damage
      • 自己並不 enjoy TDD flow 的流程
    • KB 點出要達到對自己的 code 有信心 (confidence) 是 programmer 的目標,若在此共識之下:
      • 對他自己來說 TDD 是其中一個能達到這個目的的方法
      • 舉出前幾天在 FaceBook hackathon 時混用 TDD 與一般測試開發方法來幫助自己開發的經驗 (目前 KB 在 Facebook 工作)
    • DHH 表示自己:
      • "...you're not done until you also have tests for a piece of functionality -- I'm completely on board with that."
      • 認為 TDD 適用某些地方,但是套用 TDD 並不會讓自己快樂,在某些領域 用 TDD 會是 bad tradeoff (特別是使用大量的 mock)
    • KB 回答:
      • 自己很少使用 mock、多層 mock 很糟
      • 取得 repeatable feedback loop 是重點
      • 當發現測試難以撰寫,會先 check 是否是架構上的 design 問題
    • MF 補充:
      • 是否要撰寫 isolated unit tests 是個人選擇問題 - 當年自己跟 KB 在推 TDD 的時候,還曾被批評沒有寫 isolated unit tests ...
      • 是否綁定 TDD 與 isolated unit tests 是派別問題 - 自己認為不該綁
      • TDD 是達成 self-testing code 的 approach 之一,如果有其他方式能夠達到,那也很好


  • 5/15 (迴響)
    • Gary Berhardt 發表 Test Isolation is About Avoiding Mocks
      • 引用 KB 在 Is TDD dead 的觀點 nested mock 是不好的,進一步以自己的經驗與例子,闡釋 test isolation 能夠帶來的好處
        • Structured programming clarifies control flow; isolated tests clarify coupling.

  • 5/19 (迴響)
    • Uncle Bob 發表 First
      • 引用 DHH 在 Is TDD dead 的觀點 "...you're not done until you also have tests for a piece of functionality -- I'm completely on board with that.",進一步闡述 testing 的重要性與好處,最後反問 .. 既然很重要為什麼不先做 (First)



5/16  

  • Is TDD dead? [Part II]: Test Induced design damage
    • 錄影 (約 30 分)
    • DHH 從 Jim Weirich 當初展示的六角架構範例,擷取出 gist ,指出架構上許多不必要的設計
      • 程式碼的數量會影響到是否易於改寫
      • 每一個中介層會帶來高成本
      • 就是因為使用 TDD 所以特別容易引誘人寫出這樣的架構
      • KB 指出
        • ascribing test-induced damage to TDD was like driving a car to a bad place and blaming the car for it,表示是否需要設計出這些中介層是要被評估的
      • MF 補充
        • DHH 指出的問題是由於想要 isolation 導致的,而不是 TDD
      • 摘錄自 MF 的部落格:
        • Kent clarified he wasn't talking about TDD, but about software design in general, it's not about TDD it's about how to get feedback. Thinking about software design is the thing, because it pays off so big when you get a good design insight. Getting these insights isn't about your workflow, it's about things like knowing when to work and when to rest, gathering influences from other places, collaborating with other people.



    5/20  

    • Is TDD dead? [Part III]: Feedback and QA
      • 錄影 (約 30 分)
      • KB 提出討論 (TDD 的) tradoff 時,有以下幾點要被考量:
        • Frequency - 要多快取得 feedback?
        • Fidelity - 對於 red/green 這些訊號的準確度要求為何?
        • Overhead - 我們願意付出多少代價
        • Lifespan - 產品的生命週期為何
      • MF 補充我們會希望透過得到 feedback 來得知:
        • Is the software doing something useful for the user of the software?
        • Have I broken anything?
        • Is my code-base healthy?
      • DHH 提到TDD 的成功使得:
        • 有些人會過度自信而忽略該有的 QA
        • 有些人會忽略 cost
          • 對於有些情境 (某些 web 應用) 不需要 high reliability
          • 99% -> 99.99% reliability 付出的代價很大,應注意臨界
      • KB 將討論主題拉回 QA
        • Compared to having an effective QA then no-QA is worse, but no-QA is better than the old dysfunctional relationship.
      •  DHH 提到就算透過 TDD 得到 100% coverage 還是可能有誤,KB 則分享對 Testing 的看法:
        • As soon as you think you don't make mistakes any more, that's a mistake, and you stop growing. 


    5/27  

    • Is TDD dead? [Part IV]: Costs of Testing
      • 錄影 (約 30 分)
      • DHH 提到 TDD 易於導致 over testing 的問題
      • KB 提到:
        • 用 test-first 開發 JUnit 時很順利,無 over testing 
        • 引用 Herd Derby 的 delta coverage,建議檢視 test 的重要性
        • 要勇於丟掉沒有用的 test 
        • (testing code / production code) 的 ratio 數據容易讓人混淆
          • 簡單的系統會有低的比例
          • 看情況比例有可能是 10:1 也有可能是 1:10
      • MF 補充:
        • "you don't have enough tests (or good enough tests) if you can't confidently change the code,"
        • "the sign of too much is whenever you change the code you think you expend more effort changing the tests than changing the code."
      • DHH 提到有許多人將測試視為文件,甚至重視 testing code 更甚 production code,而忽略了 TDD 中 Refactoring 的重要性,亦忽略追求 clean code 才是重點
      • KB 說他最近把部分 production code 丟掉,留下測試進行重寫,並提到:
        • would you rather throw away the code and keep the tests or vice-versa? In different situations you'd answer that question differently.
      • DHH 說人們無法正確量化 code quality 所以只能量化 testing 的數據,一味追求這些事情只是 honey trap:
        • Cucumber really gets his goat - glorification of a testing environment rather than production code
        • Only useful in the largely imaginary sweetspot of writing tests with non-technical stakeholders. 
      • 視訊結束前 DHH 提到 TDD 已經征服各領域,但 MF 不這麼認為



    6/4  

    • Is TDD dead? [Part V & VI]: Answering Questions 
      • 錄影 (約 60 分)
      • 本次會談由三人輪流挑選 google hangout 上的問題,並且回答
      • What is an example of an Open Source Project which has "test-induced design damage"? What is an example of a project which does "TDD right"? 
        • 由 Mike Harris 發問
        • DHH 指出 open source 的情境與真實商業專案的情境不一樣,而 TDD 在開發 open source library, framework ... 是有幫助的
        • KB 指出 JUnit 是完美的例子,但是是肇因於 java 上極度 clear interfaces 的關係(所以算是特例)
      • What could change about the way we write software to make TDD redundant or obsolete for Kent and Martin? What could change about the way that TDD is performed to make it useful or beneficial for David?
        • 由 Graham Lee 發問 
        • KB 引用自己寫的 RIP TDD 表示不會因為難以 TDD 而打算拋掉這項技術
        • MF 回答:"Some contexts are very suitable for TDD, some contexts less so". And people bring their personality into that context.
        • DHH 表示他剛開始使用 TDD 時很喜歡,而嘗試用在所有地方,但是在 MVC 的架構下卻遇到問題 ... 但儘管不用 TDD,達成 self-testing code 仍然是目標
        • MF 補充說每個人應該試著嘗試、overuse 以及找到 TDD 能夠運作的情境
      • How do you think a lack of (design) experience affects TDD and how do you think TDD affects an inexperienced developer?
        • 由 Udor Pavel 發問
        • ML 回答:
          • 不應比較:有經驗的人 vs 沒有經驗的人 用 TDD 的情況
          • 應比較沒經驗的人: 用 vs 不用 TDD 的情況
          • it does seem to be advantageous, and creates a self-testing code base which is easier to improve later through refactoring. So tdd gives you a good start point.
        •  DHH 認為 TDD 在被提出後這十年間,已經被許多人加上其他觀點,當他說 TDD is dead 是指這些改變讓 TDD 變質,所以應該找回初衷
      • KB 說:
        • TDD isn't dead, but is glad David set fire to it so it could come out like a phoenix.
      • DHH 在最後的對談提到:
        • 之所以發起 TDD is Dead 是因為人們沒辦法暢談 TDD 不 work 的地方,而被不斷地灌輸一定要 TDD 的觀念。
      • ML  做最後的結論:
        • 三人對於 self-testing code, TDD 在某些情境下 work 有共識
          • 但對 TDD 是否在其他情境下 work 則沒有共識
        • 在軟體開發過程,每個人應建立對自己及團隊有效的開發流程,不該盲目的套用技術
          • We're not in a codified science, so we have to work with our own experience.




    Part III:  不太相關的花絮

    5/13  

    • Tom Stuart 於 Scottish Ruby Conference 2014 投稿閃電秀:The DHH Problem
      • 演講錄影 (約 3~4 分)
      • 作者提出對於看待 DHH 言行的反思 

    5/17  

    • Joe 於 PyConAPAC 2014 投稿閃電秀:BoF is Dead. Long live eating. (PIZZA) 
      • 投影片
      • 內文對 TDD 的暗喻不太正確
        • 但演講內容其實是介紹當天的 BoF 活動





    Part IV:  戰文心得

    DHH 在發表 TDD is Dead .. 一文之後
    在各界的筆戰中大都處於劣勢
    追根究底,是因為他的主要論點只有:

    • TDD 使得開發者把重心放在寫 (isolated) unit tests 
    • 開發者會為了寫 (isolated) unit tests 導致產生不必要的中介層,破壞系統架構

    可以看得出來,他攻擊的點在於 (isolated) unit tests
    而對於 Test-First 這件事本身沒有提出更有力的批評
    更糟的是,當他論述時誤用了一些詞彙跟定義,例如:
    The classical definition of a unit test in TDD lore is one that doesn't touch the database. 
    他試圖表達「以前 TDD 導入 (isolated) unit tests 情有可原 ... 但現在已不適用 ...」這樣的論述
    但是卻被糾正:其實以前的 TDD 並沒有要求做 isolated unit tests(甚至還因此被人批評)
    使得 DHH 的主要論點變得薄弱許多

    而即便不聊 TDD 只聊 isolated unit tests
    其對系統架構的傷害與否也是未有定論
    DHH 認為 Jim Weirich 用六角架構重構 Rails App 是傷害系統架構
    但 Uncle Bob 認為這樣很好,因為做到 separate concerns 更能應付變化

    我記得 Jim Weirich 在 demo 六角架構時有提到
    一般來講他不會對這樣例子的 Application 做這些操作 ...
    亦即,對於開發小型的 Rails 應用極有可能 Jim/DHH 的用法是一致的

    事實上,若能不帶偏見仔細聽 DHH 發言
    他大多數提出的看法和反思對新手是有價值的

    這系列戰文/視訊看來,他是扮演黑臉的角色
    去把思考不夠透徹的人做 TDD/Testing/Design 時會遇到的潛在地雷挖出來
    並透過與 KB / MF 的討論告訴大家

    至於是否 TDD is Dead ?答案很明顯 : )
    我的結論前半與 KB 一樣,後半與 DHH 原本說的話一樣

    • TDD isn't dead, but is glad David set fire to it so it could come out like a phoenix.
    • Long live testing.


    Part V:  個人經驗

    一兩年前初探 TDD 時,最讓我有共鳴的是重視 context 這件事
    亦即,有了所謂的使用情境,production code「為何而寫」才會清楚 ...

    一陣子之後,我混用 TDD 的概念應用到開發 web API 的使用情境
    透過交替撰寫 testing code  與 production code (順序很隨性 XD)
    進而讓被釋出的 API 品質提高非常多

    但實作上我沒有撰寫所謂的 isolated unit tests 
    而是真槍假彈地跑 integration tests
    事後我才知道,對我負責的系統而言
    我的做法偏向 ATDD ...
    但實作上卻常遇到問題:上游根本沒有定義使用情境或是定義混亂 ... Orz

    藉由這次的 TDD is Dead 大戰
    我把看了好久都沒看完的 Test-Driven Development by Example  讀過
    並且盡可能把相關文章、影片看過,釐清各方思路進而整理出筆記

    雖然花了好幾天的時間,卻也得到海量的收獲
    這些所得對新手而言,絕不是學五分鐘 TDD 或是看一兩篇短文論述就能領悟!


    最後,附上許多問題 + 個人想法結束本懶人包:
    • TDD 會造成 over design 嗎?
      • 基本上不會。如果要說的話是造成 over implementation 
        • 亦即實作上比較費力,但是都還是緊咬著需求
      • Kent Beck 曾說過非常貼切的一句話來形容 TDD:
        •  "Code for tomorrow, design for today." Here's what happens in practice.
    • TDD 適合解未知的問題嗎?
      • 適合。但前提是 ... 
        • 在該領域本來就能透過寫 test 驗證答案
          • 而且越好寫 Test 越適合透過 TDD 解問題
      • 套用 TDD 的 workflow 很像在用數學歸納法解題
    • TDD 會導致系統缺乏全局設計嗎?
      • Kent Beck 曾舉例:
        • "What if I do a paper design for a week, then test-drive the code? Is that TDD?" Sure, it's TDD.
      • 我常舉例,只要把手邊的 ToDo list 轉成 ToTest list 就可以開始 TDD 了
        • 意指 TDD 的思維不會打壞原本的設計,只是透過思考 context 讓實作更加實用罷了!
    • 所以我該馬上導入 TDD 到我的專案?
      • 會問這個問題可能是因為
        • 還不夠了解 TDD
        • 還沒有想清楚自己專案情境
      • 建議衝動地想要全面擁抱 TDD 前,思考過 DHH 的論點以避免地雷
    • Jim Weirich 介紹的那種六角架構合不合用?
      • 懶惰點的回答是 - 看情境
        • Jim 有提到一般來講他不會對小程式做這樣的操作 ...
        • 我個人其實之前也是以 integration tests 為主,但是這個架構讓人能夠重新思考 procedure/OOP 的概念
      • 更深入想想則有很多有趣而值得反思的點:
        • Web MVC 是一個怎麼樣的設計?
          • 你撰寫的程式碼是 style 偏 procedure 還是 OOP?會怎麼混合?
        • 為什麼開發者在 Web MVC 的框架下開發,往往會在系統規模變大時讓 Controller 的部分會變得雜亂?
          • 這個時候是不是該抽取出 business logics 或是改變系統的設計?
        • 使用框架的初衷跟需求為何?
          • 想要全盤 or 部分接受 Rails?
          • 如果很不喜歡 Rails 的架構,而花費大多數心力在脫離他?那幹嘛還用它?
        • 會有更加友善且同時支持「開發」與「測試」的框架嗎?
    • 你對 DHH 看法如何?
      • 我買過他跟 Jason 合著的書且寫過 心得 ,你認為呢 XD
      • 附帶一提看完大戰後,我對於 Kent Beck, Martin Fowler 是感到佩服跟尊敬
        • 好在 Uncle Bob 只有寫文章沒有出來視訊(叔叔的文章比較戰 ...)
        • 我相信 Kent Beck, Martin Fowler 是本著想釐清問題跟推廣 TDD 的角度來進行視訊
    • 所以到底該如何開發 Rails App?
      • 呃 ... 我只寫 Python ... lol (魯蛇無誤)


    撰文緣由:

    我在 5/31 的 Tainan.py 投了一場演講
    演講內容從 testing 概念到 unit tests 到 TDD ...
    輪到 TDD is dead 系列文的開頭時就過了一個多小時 Orz
    最後在講得不清不楚的情況下結束演講

    痛定思痛,索性花幾天的時間整理系列文章
    希望對當天的朋友、有興趣的朋友有所幫助

    台灣各地 Python 社群列表:
    Taipei.py - 台北
    PyHUG - 新竹
    Taichung.py - 台中
    Tainan.py - 台南
    Kaosiung.py - 高雄
    花蓮.py - 花蓮



    2014年6月6日 星期五

    好書分享:Test-Driven Development by Example

    TDD by Example 是大師 Kent Beck 於 2002 年出版的書
    TDD 及其衍生的開發方法對近十年的軟體開發有著巨大的影響


    前言

    出來工作後偶爾都會聽到技術人提到「TDD」或是「*DD」等等關鍵字
    一兩年前便取得本書,有時候睡前會閱讀此書
    卻因為常常看到睡著導致每次看都要重看 Orz
    最後就把本書束之高閣

    趁著前陣子 TDD 大戰 上個月便一口氣把本書看完
    並且撰寫此文,讓對本書有興趣的朋友能夠評估是否需要閱讀


    如何取得此書?

    iBooks / Amazon 皆可取得原文電子書
    對岸似乎有中譯本 ...

    另外由於加拿大約克大學在 2004 年有開過一門「Software Design
    官網內恰巧有提供本書的第一章當作參考資料 點此下載

    點選左手邊的 Resources 分頁,可以看到參考資料還有 Design Pattern ...
    這大概就是「城鄉差距」... (看看台灣的課程 ... BJ4 ... Orz)


    誰適合閱讀此書?

    TDD 的概念可以說是在 2002 附近才被 Kent Beck 正式提出(不是發明)
    事實上此技術已在 199x 年就被少數人採用並且逐步發展
    提出後的這十多年間,該概念被不斷再解釋、延伸、補強 ...

    若要學習 TDD ,本書已經不是唯一的途徑(有前輩帶 + 自己動腦動手最快)
    但本書有以下優點:

    • 不會太大本,好讀
    • 舉例的內容著重在概念上,好理解
    • 是最早花這麼多篇幅討論 TDD 的著作,閱讀後能協助理解後來的延伸
    • TDD 的概念在此時已經算是成熟而完整

    本書適合給「想要了解 TDD 發展」、「英文閱讀能力中等」的朋友閱讀
    (像我只有中下,一直查單字讀得有點 zzZZ)


    而您若是想要學習 TDD
    本書的角色是幫您在概念上醍醐灌頂
    然而若要順暢實作,則有賴於動手動腦以及閱讀更多著作


    此書內容在說些什麼?

    本書分為三大章節:

    • The money example
    • The xUnit Example
    • Patterns for Test-Driven Development

    藉由第一個章節「The money example」導入貨幣的範例
    作者將 TDD 的基本流程跟執行時的思路告訴讀者
    這邊的範例程式碼使用 java ,且實作的步驟非常小而略瑣碎
    (這可能是我之前一直看到睡著的原因 ...)

    第二個章節「The xUnit Example」頗為有趣
    作者示範如何以 TDD 的方式開發 Testing Framework
    範例程式碼皆由 Python 實作
    此範例我個人覺得比第一章節的範例有趣且實用許多

    第三個章節共有以下子主題:

    • TDD patterns
    • Red Bar patterns
    • Testing patterns
    • Green Bar patterns
    • xUnit Patterns
    • Design Patterns
    • Refactoring
    • Mastering TDD

    簡言之,作者探討在執行 TDD 各個過程可能會遇到的情境與決策方式
    由於 TDD 是由許多程序組合而成的開發方式
    無可避免地會討論到 Design Patterns 與 Refactoring 等等技巧(都是點到為止)


    部分摘要

    TDD is an awareness of the gap between decision and feedback during programming, and techniques to control that gap. "What if I do a paper design for a week, then test-drive the code? Is that TDD?" Sure, it's TDD.


    TDD is not about taking teeny-tiny steps, it's about being able to take teeny-tiny steps.


    If you can make steps too small, you can certainly make steps the right size. If you only take larger steps, you'll never know if smaller steps are appropriate.


    Rather than apply minutes of suspect reasoning, we can just ask the computer by making the change and running the tests.


    TDD makes this work well by giving you running concrete examples from which to generalize, instead of having to generalize purely with reasoning.


    Exploration— When I'm faced with a new programming language, I implement xUnit. By the time I have the first eight to ten tests running, I have explored many of the facilities I will be using in daily programming.


    One convenient implication of isolated tests is that the tests are order independent.


    A second implication of isolated tests is that you have to work, sometimes work hard, to break your problem into little orthogonal dimensions, so setting up the environment for each test is easy and quick.


    What should you test? Before you begin, write a list of all the tests you know you will have to write. The first part of our approach to dealing with programming stress is never to take a step forward unless we know where our foot is going to land.


    TDD is a refinement of the Ungar Shower Methodology. If you know what to type, type the Obvious Implementation. If you don't know what to type, then Fake It. If the right design still isn't clear, then Triangulate. If you still don't know what to type, then you can take that shower.


    What don't you have to test?
    The simple answer, supplied by Phlip is, "Write tests until fear is transformed into boredom."


    I learned exactly the opposite from books: "Code for today, design for tomorrow." TDD appears to stand this advice on its head: "Code for tomorrow, design for today." Here's what happens in practice.


    Good engineering is maybe 20 percent of a project's success. Bad engineering will certainly sink projects, but modest engineering can enable project success as long as the other 80 percent lines up right. From this perspective, TDD is overkill. It lets you write code with far fewer defects and a much cleaner design than is common in the industry.


    Robert Martin and I did some research into this style of TDD. The problem is that the design keeps surprising you. Perfectly sensible design ideas turn out to be wrong. Better just to think about what you want the system to do, and let the design sort itself out later.



    心得

    初閱本書第一章時,「Test First」的做法讓我想通了不少事情
    包括重新重視每個 unit 的使用情境以及意識到小粒度 testing 的重要性
    進而放大粒度,從大組件的功能性 => 系統的功能性 => 產品的功能性 ...
    來思考「Test First」的可行性

    廣義 Test First 的背後觀念其實是「使用情境的提前模擬」與「驗證方式的提前確定」
    做事情前,本來不就應該訂定目標跟檢核辦法嗎?

    TDD 節奏的概念很簡單,大多數工程師都能夠在幾分鐘內了解
    看過本書的開頭內容後,我也一直以為我大概知道 TDD 是怎麼一回事
    但是這是不對的,我就跟看完 TDD 流程圖就覺得已經了解  TDD 的人一樣
    只是看到冰山一角而已 ... Orz

    TDD 是與 Design Patterns, Refactoring, xUnit, XP/Agile, Mocking ...
    等等觀念、技術、開發方法「同綑」在一起的
    一直到前陣子一口氣看完本書,並且買了很多雞排觀看 TDD 大戰
    我才意識到這件事

    我想,閱讀本書最大的好處
    大概就是能回到 2002 以前,去看看這門技術是怎麼一回事吧!



    隔一陣子來嘗試撰文整理 TDD 大戰懶人包
    TDD is Dead V & VI 的最終場 hangout 大戰都已結束
    應該算是戰完了吧 XD