over 3 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 其實很清楚的抓幾件重點:

  1. TDD 不能幫助你「創造」 Software
  2. TDD 有可能害你不小心沈迷於設計 unit 細節
  3. 過於設計 Unit 細節,接下來就會不小心執著於 Test 要跑得非常快
  4. 想要跑得非常快,所造成的 by pass 手法,會把系統搞得更複雜,傷害原始設計。到了該步田地,也無需再使用 Rails。

(我之所以講 Uncle Bob 張飛打岳飛的原因是,Rails 生態圈是演化非常快的 opensource comunnity。因為這個生態圈和工具太健全,所以軟工演化的速度和失控程度,不是其他社群可以想像的。)

DHH 會抱怨這一些事,是過去這一兩年來,他已經被捲入無數次的戰爭裡,現在爆發只是剛好而已。

Rails 社群對於 TDD 的著迷以及病態發展

Rails 在過去兩年,針對這個議題,比較著名的總共有三篇教學論述

  1. Object On Rails
  2. Rails is Not Your Application
  3. Implementing the Repository Pattern in Ruby
  • 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 都非常優美,像藝術品一樣。一般開發者一見就會傾心,但實務上它們徹底不實用。

因為:

  1. 很多 application 在需求一開始開出時,是無法用這種模式開始設計的(需求不清不楚)。這就造成了困難一。
  2. 能夠適用這三種開發手法的 application 通常是中央 bussiness 已經接近固定,才好抽。果一直要變動,用這樣的手法設計再一直疊加邏輯上去,會反而造成太多不需要的抽象 layer 夾在中間,造成設計上的困擾。
  3. 太多不需要的抽象 layer 反而造成效能下降。
  4. 有把設計變簡單嗎?恐怕變得更複雜。
  5. 搞成這樣你還寫 Rails 幹嘛? Rails 的優勢(開發速度以及架構調整能力)都不見了

這是為什麼 DHH 後面補那兩篇文章的原因。因為 Rails 社群玩 TDD 和玩架構設計玩到失控了....

← Rails Outreach Workshop @ Taipei / Tainan RailsConf 2014 - 十週年紀念版 (下) →
 
comments powered by Disqus