總算是把 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??