almost 10 years ago
前幾天 DHH 又補了一篇 Test-induced design damage 和一篇 Slow database test fallacy 。
這場世界大筆戰想追的人，可以看好心人整理放在 Evernote 上的 DHH：TDD is dead. Long live testing. 系列懶人包。
我個人再補充一些為什麼會有 Test-induced design damage 這篇文章的背景導讀。（很多人沒有追 Rails 生態圈追那麼緊不知道這篇的時空背景）。
所以這場世界大筆戰有時會看到張飛打岳飛的狀況(特別是根本一直狀況外在跳針的 Uncle Bob）。
張飛打岳飛？
DHH 其實很清楚的抓幾件重點：
- TDD 不能幫助你「創造」 Software
- TDD 有可能害你不小心沈迷於設計 unit 細節
- 過於設計 Unit 細節，接下來就會不小心執著於 Test 要跑得非常快
- 想要跑得非常快，所造成的 by pass 手法，會把系統搞得更複雜，傷害原始設計。到了該步田地，也無需再使用 Rails。
（我之所以講 Uncle Bob 張飛打岳飛的原因是，Rails 生態圈是演化非常快的 opensource comunnity。因為這個生態圈和工具太健全，所以軟工演化的速度和失控程度，不是其他社群可以想像的。）
DHH 會抱怨這一些事，是過去這一兩年來，他已經被捲入無數次的戰爭裡，現在爆發只是剛好而已。
Rails 社群對於 TDD 的著迷以及病態發展
Rails 在過去兩年，針對這個議題，比較著名的總共有三篇教學論述
- Object on Rails 主打你應該從 Object 設計起。把整個邏輯封裝在外，再掛進 Rails 。
- Rails is Not Your Application 主打你應該採用 DCI 設計手法，掛進 Rails。
- Implementing the Repository Pattern in Ruby 主張你應該將整個程式用 Repository 模式設計，再掛進 Rails。(本次 Railsconf 有開 Workshop，我剛好有去聽，但是這場 workshop 是一場災難...）
這三種方法主要目的都在解成幾件事：
- 更好的用 Ruby 、物件、Pattern 敘述業務
- 將主要邏輯層抽離 persistent 層，可以巨幅提升 test 運行的速度。
當然這幾種寫作方法，設計出來的 code 都非常優美，像藝術品一樣。一般開發者一見就會傾心，但實務上它們徹底不實用。
因為：
- 很多 application 在需求一開始開出時，是無法用這種模式開始設計的（需求不清不楚）。這就造成了困難一。
- 能夠適用這三種開發手法的 application 通常是中央 bussiness 已經接近固定，才好抽。果一直要變動，用這樣的手法設計再一直疊加邏輯上去，會反而造成太多不需要的抽象 layer 夾在中間，造成設計上的困擾。
- 太多不需要的抽象 layer 反而造成效能下降。
- 有把設計變簡單嗎？恐怕變得更複雜。
- 搞成這樣你還寫 Rails 幹嘛? Rails 的優勢（開發速度以及架構調整能力）都不見了
這是為什麼 DHH 後面補那兩篇文章的原因。因為 Rails 社群玩 TDD 和玩架構設計玩到失控了....