almost 3 years ago

DHH 在 RailsConf 上面對到底要不要 TDD 開了第一槍。雖然引來很多爭議,我認為這是一個非常好的開始。

因為以 DHH 的地位,我認為他是說「我不 TDD」受到的砲火(大家會認為不TDD=不會寫程式)最小的人。當然,他說這句話,引到的其他砲火更猛裂。

但這真的是很好的出發點,讓其他人開始敢說真話以及思考其他可能性。

設計軟體的重點:好讀、易維護、以全局觀點思考。

很多人都是被以「我不 TDD」的爭議點吸來看這篇文章的的。但要繼續讀下去之前,我希望你先做兩件事:

  1. 上 Justin TV 把 DHH 整場 Talk 看完,在看的時候請把「這場 Talk 是講 TDD」預設觀點拿掉(我們聽現場的人,在進行到一半之前是完全不知道他會扯到這件事的)。
  2. 看完 DHH 對於 TDD 的論述。(有人翻譯了這篇文章

DHH 的這場 Talk 要傳達是「設計軟體的重點:好讀、易維護、以全局觀點思考」。

而不是「我不 TDD」。

而之所以他會選擇「我不 TDD」為出發點,是因為開發者被許多開發上衍生出來的技巧和觀念所綁架了。而且衍生出很多似是而非的偏見。

在軟體界你應該聽過很多指控,如:

  • 「不 TDD」 = 「寫 Code 很遜」
  • 「不會寫 Test」= 「寫 Code 很遜」
  • 「不使用 Design Pattern」 = 「寫 Code 很遜」
  • 「不 TDD」 = 「假 Agile」
  • 「不想用 Scrum」 = 「不 Agile」
  • 「覺得 Scrum 沒有用」 = 「你一定沒有受過 Scrum 完整教育,沒被好的 mentor 帶過」

當然,最大條的當然是「不TDD」,只要哪個 Developer 說他開發時不 TDD,別人一定會質疑他根本不會寫 code,功力是假的。

所以這樣的 false claim 由神人 DHH 出來坦強力反對,當然是最好的。

Developer 的聖杯:功力完霸所有名詞

上面寫的這麼多條指控是真的嗎?

在某些人某些狀況是真的,但是「絕大多數時候」 *不成立*。

這樣講,大多數人可能很難接受。

我想以這樣的角度去切入,一個 Developer 從入門到資深,由產品實作到產品架構設計必須要學習的技能以及標準:

***
(以用 Rails 開發產品為例)

  • (前)入門者:學習必備的工具,如 Git, Command Line, CSS / HTML 。
  • 入門者:學習 Rails 基本的 API、工具、第三方套件,設計出「可以動的程式」。
  • 入門者(後):學會 Ruby 比較進階的議題,學習寫出改得動的程式碼,以及如何寫出佈 Abusing Ruby / Rauls 的 code。能夠自己獨立做完一個小型 project。
  • 一般 Developer:學會封裝(method/Class),ORM 優化,效能優化,前端優化,基礎 Testing 技巧,基本 Security。
  • 進階 Developer:TDD,基本 Design Pattern 技巧,Gem 封裝,Rails advanced API 使用。能夠自己獨立做完一個中型 project。
  • 資深 Developer:TDD with Testing Pattern、PORO Design with Rails、SOA、大型站台 Scaling、大型 Gem 設計。

(完成所有的課題大概需要 5 年以上時間,因為很多東西是需要「大量」「實作」才能得到經驗值。)

其他還需要學習的有:如何跟其他人協作(設計 API 以及最不阻擾大家的工作 Pattern 與 Pattern),專案管理(如何控管進度,學會切票以及抓大放小),基本 Agile 技巧,溝通技巧(如何以有效的方式說服同事、老闆、Stackholder 採取方案)。

***

所以「不 TDD」 = 「寫 Code 很遜」。「不使用 Design Pattern」 = 「寫 Code 很遜」。在對資歷淺的 Developer 是成立的。因為這跟 Developer 程度與開發技巧層面有關係。

而 Developer 的終極浪漫往往是練完這些名詞,並且在一個 Project 裡全部用上這些字。誰擋在自己面前,就一定幹掉對方。

到達終點才知道夢破碎

但是最殘酷的現實是,當爬到最終點時,Developer 才會意識到一件事,這件事情是不可能辦到的。

因為學完所有名詞時,幾乎也會站到 Architect 這個角色去。才會發現幾件事:

  1. 除非專案有無窮的預算,否則你不可能無止盡的砸時間在軟體工程上。
  2. 如果專案有無窮的預算,你的產品也不可能成功。太多的官僚 PM 會湧入,太多的「想做到更好的念頭」「太多的產品決策樹」,會把上線的時間無窮往後延。無法上線的產品遠比沒有好 code 的產品糟糕太多。
  3. 身為一個 Senior / Architect 更重要的事情是「在有限的時間做出『相對好』的決策」,這些決策可能意外著可能要逼著自己或手下寫出 work-around、no-test、not-tdd、ugly code、slow-query,許多會被 developer 鄙視的 anti-pattern。

這就是所謂的抓大放小。

Architect 的兩難

而抓大放小,還會造成更多的麻煩。因為 Senior 平常會逼著 junior developer 學他們應該要的技術。但是你卻無法跟他解釋為何你「現在」要用這些 anti-pattern。因為他們無法連什麼是大,什麼是小都不知道。如何理解什麼是「抓大放小」?

Senior 希望 Junior 不要用 anti-pattern,但必要時又必須自己用 anti-pattern 解決這些問題。用久了這些 junior 還會以為自己老闆根本不會寫 code。一天到晚互相矛盾在打自己臉。

這就是 DHH 所說的「被名詞綁架」。你要做事和討論,雖然用正確的手段。但卻完全無法被放入場景,而且整個氣氛氛圍還會變成:一講出這些話,還會變瞬間貶低為「Amature」(完完全全的政治不正確)。之後相關議題完全無法展開。

所以他選擇開這個第一槍。

Testing / Design Pattern / TDD

Testing

回到 Testing,為何我們要學 Testing,是因為 Testing 可以帶給我們更 Solid 的程式。這在需要長久維護、或者是需要多人協作、牽扯外部第三方元件的程式中至關重要。

可以有效降低開發及維護成本。

Design Pattern

為何我們要學 Design Pattern,是因為使用 Design Pattern 技巧,可以讓我們的程式在某些情況下,相對的更好維護。只要修改小部分的程式碼,就能利用界面擴充出出更大型的程式。

TDD

為何我們要學 TDD,是因為 TDD 可以逼一個 Developer 以開端解 Fail Test 的方式,去「設計」出一支不容易 Fail 的程式(多數情況下,不容易 Fail 等於設計出正確的功能,也正常作用)。

同時,採取 TDD 的方式,且想要寫出品質好且「好測」的 Test,會逼一個 Developer 去思考如何做出好的物件、界面、封裝的設計。可以更深層的了解 Design Pattern、PORO 技巧的美。

所以 TDD 是一個非常好「學習寫進階程式技巧」的方式。

But why not TDD / Design Pattern ?

但為什麼很多 Senior 開發者 TDD 到最後卻選擇性放棄 TDD。是因為 TDD 會造成過於注重 unit 形式的設計,而忽略整體系統架構的設計。(這也是 DHH 所談到的主要 issue,每次他回去認真 TDD,寫一寫又覺得不對勁。但 TDD 不對勁這個議題又幾乎被氣氛綁架到幾乎形同禁止討論)

而且 Senior 對於 TDD 的看法多半是:TDD 適合用來作為「已知解決手法,但有可能過程複雜容易出包」的程式。使用 TDD 可以有效降低爆炸機率,提升開發效率。

但對於「未知解決手法」的程式,使用 TDD 反而會造成效率下降。因為反而會花太多時間在處理 unit 本身,而不是專注於 system 本身的設計。

***

Design Pattern 其實也面臨到相同的狀況。太早 Design Pattern 開下去,當系統要快速迭代變更設計時,原先的 Pattern 甚至或當場「絕對不適用」。

結論 : 好讀、易維護、以全局觀點思考

既然這些高階技巧不適用。那麼我們又該何去何從?

我個人的觀點是,這又掉進了同一個思考誤區。把所有人的所有狀況,看成一種人一種情況:

  • DHH 說不是每次都要 TDD。不代表你應該不 TDD。
  • DHH 說希望更專注 System Design Test。不代表你應該以後只做 System Design Test。
  • Kent Back 說不是每次都需要寫 Test,因為人家付錢給我們是要買程式。而不是買 Test。如果你怕你程式容易爆的話,應該下班偷偷補 Test。

(因為你不是 DHH,你也不是 Kent Back,你現在不是面對他們所面對的問題。更見鬼的是,你也不是他們那層神級開發者的程度。)

他不希望大家聽他講一講,又跳進只專注 system design 的另一個聖杯去。

DHH 整個演講穿插的幾張綠色主題投影片,我想就是一個非常好的 Geneanal 準則(適用各種 Level)。其實你不應該被任何名詞綁架,而應該以這三點:「好讀、易維護、以全局觀點思考,為基準點」去設計你的程式。

(RailsConf 另一個講者的 Sandi Matz 的 Talk 也很精彩,他也提到了用錯誤的抽象封裝比正確的複製貼上 code 還要來的糟。)

不學 TDD 不知道要放棄 TDD

另外就是別因為誰講什麼不用做。就放棄去學什麼。

每一個 Level 都有自己應該要學的課題。

不學 TDD,也不可能一直領悟進化到(可以)放棄 TDD 這件事。

他也鼓勵大家「多寫 Software」,只抱著 Pattern 的書是無法幫助你成為一個厲害的 Developer 的。

***

這真是近年來罕見的一個精彩 Talk (雖然看不懂的可能就是看不懂..還會覺得是垃圾)。

我真的推薦大家「多看幾遍」。

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