總算是把 TDD 的戰文看完了,看完後我對 DHH 的評估仍是沒變。

DHH 在 Rework 中自述到,他偏好帶領一個三十人的團隊自在的工作,而不要把組織擴大到上百上千人把自己搞的焦頭濫額。 DHH 在組織架構跟應用範圍的偏好偏食,讓我在讀 DHH 文章時都會先考慮過他的出發點跟局限性。

以程式設計師的角色來說, DHH 的精兵政策當然看起來很爽,我自己也做過類似的選擇,捨棄 Java 而就 Scala ,追求更高的個人產值。

然而若是以一個架構師的角度來說,我的目標是成為像 Martin Fowler 的角色,相較於只有 36 個員工的 37 signals ,ThoughtWorks 是個有超過 2500 個員工的專業代工廠,在 ThoughtWorks 掛頭牌的 Martin Fowler 在技術的選用上,自然的考量要更全面,顧慮到不同應用領域的開發需求、以及不同程度的程式設計師該怎麼管理。

DHH 對 TDD 的批評我多數同意,尤其是 Testing / DI 對 Design 的入侵也是一直困擾我的問題,但是我是把 Testing 當成一個需求來看,所以是多一個需求造成的額外成本在困擾我,而不是降低可讀性等問題在困擾我。 在目前看不到較好的替代品之前,我還是會繼續用 TDD (w/o test first) 來做設計上的工法。

我目前對程式的想法是從資料做起,我做的系統,多數就是把輸入的資料,透過一串串的轉換,Map, Filter, Count, Sum, Aggregation 後,變成最後要的樣子,在A -> B -> C -> D 中間,可能會有一些中介型態的出現。

在我的設計中就會變成,在每一次的轉換的過程中,讓輸入輸出是可以被測試的,在設計階段就預先考量到要怎麼測試這些轉換。

至於會不會做 Unit Test, Test First, 我是看有多少時間做多少事的,但至少模組內的一串流程的測試是會去做的。

另外我會把 DAO & Data Transformer(Service) 分開來,資料轉換的運算,是可以不用靠 DB 來的資料直接做測試,這樣跑起來才會快。

許多的商業邏輯,我會在 DAO -> Service 上再多架一層 Controller ,這個 Controller 就會很醜,因為只有三(四)層,所以一個 Controller 可能換串個十來個 Service ,但是醜的就是在這裡面而以。

測試的時候,至少是可以分層把底層容易測的都測好是穩定不容易出錯的,到時後上線有問題時,就可以知道是在 Controller 把東西串起來時出錯了。

沒有 Test First 沒有 Unit Test ,但是會做 regression test, integration test 會在設計時預先留下容易稽核的點。這是不是 TDD??