over 4 years ago

眼尖的朋友看到,最近我開的兩堂課: Deliver Project on Time 敏捷專案管理實務 - 六月班Intermediate Rails - Rails 實戰就業班(六月),都加入了 User Story 撰寫的教學部分。紛紛偷問我為什麼要加這個東西進去?

Rails Meetup 三年多來,在輔導培訓過非常多 Rails Developer 之後,我開始發現當今的網站開發教育中漏掉了很重要的一環,就是「規劃 Application 開發的技術」。

線上教育什麼技術都有教:基本的 Ruby on Rails,基本的 jQuery,基本的 CSS。看起來好像你上了這些基礎班,就可以開始寫一個網站,找到一份工作。但這卻跟現實有一段相當大的差距。我訪問過很多徵才廠商和初級開發者,開始了解到問題出在哪裡。

具備網站簡單的開發能力只是必備的基礎,僱主最看重且會決定錄取的能力,卻是「把 Idea 變成實際 Application 的能力」。就是今天老闆開一個需求,員工要能做出規劃,並且在時間內執行完畢。

很多成長為 Senior Developer 的前輩沒有意識到這也是一門技術,所以面對「如何培養規劃實做能力」的問題,因此往往會覺得,你多寫習題就可以練成了,或找到一份工作被多操一下就會了。但這又回到雞生蛋、蛋生雞的問題,沒有能力寫出中小型 Application,又怎麼容易找到可以成長的工作。

打破雞生蛋、蛋生雞的循環:User Story as Architecure

我後來一直思考如何解決這個問題。才發現其實很久以前我已經解決了這個問題,只是我一直沒有意識到..,就是:「透過撰寫 User Story 的訓練,練習出如何設計架構的能力。」(這個技術四年來也一直在我部門/公司中施行訓練)

什麼是 User Story

User Story,是 Scrum 這個敏捷框架會用到的一個開發方法。具體解釋可以看ihower 曾經寫個的這份整理,寫的很棒。

傳統開發流程是 PM 花上很多的時間進行訪談寫成規格,RD 再轉成 Application。不過往往這個轉換過程中,卻容易出現相當大的風險。

當中的問題出在於 PM 的「規格」有很大的機會天馬行空,即使不天馬行空,也有可能不貼近使用情境,或者是根本脫離真實使用情境。RD 自然拿到規格和畫面 Workflow 進行「轉換」時,萬分痛苦。

當然,更多時候, RD 根本不知道要怎麼「轉換」。這就是為什麼每個專案都花了很多時間進行了需求訪談,也可能寫了詳細的規格,專案卻始終容易出包,都是在「轉換過程」中出現了問題。

User Story 強調透過一份簡單的情境規格,具體的描述出軟體在「使用者」的手上,是怎麼樣被「操作」的。能夠讓 RD 在開發時,能夠盡可能地貼近真實被需要的 Application。而不需要的功能,或者無法被實作的功能,將在一個一個循環之中,被捨棄。

初學的範本是:作為一個 (某個角色) 使用者,我可以做 (某個功能) 事情,如此可以有 (某個商業價值) 的好處。

幾個 User Stories 的範例如下:

  • 使用者可以在網站上張貼履歷
  • 使用者可以搜尋有哪些工作
  • 公司可以張貼新工作
  • 使用者可以限制誰可以看到他的履歷

為什麼 User Story 可以幫助培養開發能力

透過把冰冷的規格轉成具體的小情境,RD 可以更知道要怎麼將架構切分成較小且可以單次就開發完畢的小元件。利用一個一個小的故事,開發出一個一個的小功能,再堆疊成一個完成的網站。同時透過 User Story 的內容對比,RD 能夠開始有辦法排出輕重緩急,甚至估算出正確時程。

我發現很多入門的 Rails 開發者,在學完基礎的 Rails( 比如說學完 Intro to RailsRails turtorial。這些從 CRUD run 到 deploy 到 Heroku 的簡單一日課程之後。就無法再進行下去了....

根本原因是初學者不知道下一步如何進行自己點子的實作。

許多的書籍都有具體給定步驟與架構,因此在自行練習的時候沒有問題,但在自己自由設計題目時,卻不知道如何開展。或者是自己有了一點基礎想法,拍了某些網站的 screenshot & workflow。拿回家時卻不知道怎麼 breakdown。

這就是為什麼我在

都加入了 User Story 的教學部分。因為 breakdown to application, simple project management 就是新手進階成職業的一大瓶頸門檻。

為什麼非程式設計師也需要學習撰寫 User Story

在 Deliver Project on Time 敏捷專案管理實務 的五月班,有一位很有意思的報名者,他報名是因為長期參與 NGO 的活動,但卻覺得 NGO 的專案規劃以及執行專案能力不佳。因此想要透過上這個班,實際學習專案管理能力。

其實不只是 NGO,通常非程式設計師出寫出的規格通常都較脫離現實,是因為誤以為了軟體開發只要提供了「欄位」「畫面」「流程」「仿照知名網站的 Workflow),這樣就是完成專案的規劃。

事實不然,程式設計師往往希望你提供的是軟體使用「需求」,以及軟體「使用情境」,這樣他們才容易設計出好的軟體。很多規格書滿滿的 screenshot,或者是標注模仿某知名網站 Workflow。其實都不是程式設計師想要且需要的東西,他們希望你有辦法簡單敘述你要什麼,你想要的流程是什麼,你背後的生意邏輯是什麼。(a.k.a. 你真的知道自己在幹什麼)

好方便「程式設計師」後續「規劃」「軟體架構」。

User Story 可以很容易的協助雙方達成一致性的目標,因為User Story的書寫語言並不是什麼技術文字,而是一個又一個的情境。可以作為一個相當好,雙方又容易接受的橋樑。同時透過撰寫 User Story,自己也可以越來越釐清這個網站真正需要的東西是什麼,不需要真的實際寫程式,不懂程式也可以設計出合理的網站架構。

這就是我建議為什麼非程式設計師也需要學習撰寫 User Story 的原因。

學習資源

要學習撰寫 User Story 以及學習進行簡單的小專案管理。你可以購買 Scrum 系列的書,或者是以下幾本我覺得不錯的書:

當然,如果你想偷懶,最快的方式,還是報名我以下的這兩個講座 / Workshop。我有直接整理好的講義以及結合 Project Management 的實戰技巧。

希望以上這些學習資源能夠幫助到你。

( 如果你有相關的疑問,歡迎透過這個表單 聯絡我)

 
over 4 years ago

新課公告:這個班是為了想快速進階 Rails 實戰並且有意轉職 Rails 網站開發的的開發者所開設的。

上課時間/ 報名網址:

課程網址:http://learn-rails.today/workshops/intermediate
報名網址:http://rocodev.kktix.cc/events/intermediate-rails-2014-06

共四次 12 小時,另加回家大量實作。

  • 6/9 (一)19:00 - 22:00
  • 6/16 (一)19:00 - 22:00
  • 6/23 (一)19:00 - 22:00
  • 6/30 (一)19:00 - 22:00
Read on →
 
over 4 years ago

Railsconf 2014,跟我一起參加的還有 T 客邦的工程師 Bruce Li。大會的第二天他參加 Novice 的 Theme Track,我則是跑去 Growing Talent 的 Track。

晚上在飯店我們交流心得時,他提到大會有一個 Talk 不錯。叫 Reading Code Good

Talk 大意是這個講者才學 Ruby on Rails 一兩年而已,他當初為了成長,所以在當地號召了一些朋友,一起組一個 CodeClub。這場 Talk 是他分享他辦 CodeClub 的經驗。

Reading Code Good from saronyitbarek

為什麼讀書會容易失敗?

這個 CodeClub 不是一個讀「書」會。

傳統 CodeClub 多半是「讀書會」,像拿一本經典的書再念,學習裡面的技巧。但這種會超容易失敗,因為書上多半不是真實的案例,而且離實際應用都還有點距離,Junior 硬要跟上每章進度會非常痛苦。

How CodeClub works?

他們的 CodeClub 玩法是上網找一段長度適中的 code ( 100 行)的 code。大家一起來讀 code,從中學習:

  • 這一段 code 值得學習的地方
  • 這一段 code 哪裡寫的爛
  • 我們可以如何改進這一段 code

講者從這樣的過程中吸收到很多知識。

***

聽完這個 Talk,Bruce 很羨慕,很希望在台灣有一個。不過要籌辦這種 CodeClub,找人不是問題,找題目比較是問題。比較大的麻煩就是找到可以拿來讀的 Code,然後有人可以帶解答。我們後來想起 RailsConf 有開一個 Refactoring Workshop

這個 Workshop 裡面有四題:

  1. extract method 的使用時機
  2. NullObject 的使用
  3. 結合上述兩招的綜合應用
  4. ServiceObject 的抽取

相當適合拿來辦 CodeClub。預計 CodeClub 會雙週辦一次。第一次解 (1) (2)。第二次解 (3) 第三次解 (4)。第四次以後解新的題目。

這個活動會在 5/20 辦第一場。6/3 辦第二場。6/17 辦第三場。歡迎大家共襄盛舉。

報名連結在:http://www.meetup.com/taipei-rails-meetup/events/182794352/ 5/20 (二)晚 Deroot休閒空間

(BTW,這個活動主辦人是 Bruce Li。他的部落格是 Bruce的玩具間

 
over 4 years ago

在 Rails 2014 裡面,有幾個精彩的 Talk,Advanced Arel: When ActiveRecord Just Isn't Enough 就是其一。

這個 Talk 的內容是在講如何使用 Arel 搭配 ActiveRecord 產生更複雜的 SQL Query。

Arel : Relational Algebra

背景介紹:

  • ActiveRecord 是 Ruby on Rails 的 ORM。是世界上最強最智能的 ORM。
  • Arel 是 ActiveRecord 的底層。

四年前 Ruby on Rails 突破了所有 ORM 只能用排列組合設計的盲點:

  • 各種 SQL statement 排列組合
  • 各種 RDMBS query 排列組合

試圖去突破:發明了一套強大的 SQL AST 引擎,用 Relational Algebra 去組 SQL Query。而這套引擎就是 Arel。

智能產生優化過的 SQL statement

有了 Arel,開發者可以輕易的用 ActiveRecord 組出 Query,而且是經過優化的 Query。

(比如說以前有一些條件是開發者必須要先撈資料先塞進記憶體,再塞進 ORM 的,在 Arel 時代只要下正確的 ActiveRecord 語法,ActiveRecord 會自動知道要用 subqury 去解決這件事 )。

讓 SQL statement 回到 Business Logic 層次

用 ActiveRecord 產生 SQL query,不僅可以讓原先的邏輯回到 Ruby 層次,容易維護之外。多數時候 ActiveRecord 甚至生出來的 query 比開發者自己想出來的還要高效許多。

( Arel 跟著 Rails 3.0 釋出,2010/8 )

但是,雖然有了智能的 ActiveRecord ,在許多的實戰領域裡面,開發者還是被逼著要用許多 handwriting 的 SQL statement。因為我們認為這些東西無法用 ActiveRecord 下出來。例如複雜的 join 或 Group。甚至以前的許多 NOT case。

ActiveRecord with Arel

這篇 Talk 就是要打破開發者原先的思維,許多人以為下 SQL Query 必須只能透過 ActiveRecord,事實上 ActiveRecord 「可以」吃 Arel 本身的語法 combine 在一起用。這場 Talk 就是教大家怎麼這樣用。展示了非常多寫法。

不過,雖然看了這麼多炫技,開發者可能還是會覺得哪裡不對勁!

多數的複雜 SQL statement 是從 Stackoverflow 上抄來的

如果我知道 SQL query 要怎下,毋庸置疑我就會用這些技巧去組啊。但很多時候問題是我根本不知道怎麼下出這些條件。都是到 Stackoverflow 神出來的,然後只會拿到一組 "it works" 的 SQL syntax。這些神解法我連邏輯都不知道怎組出來的,要怎麼 reverse 回來。

Scuttle.io

Well,這個 Talk 的作者說,他知道這件事,所以這場 Talk 其實只是為了要展示了他最近寫的一個工具 http://scuttle.io

Scuttle.io 只有一個功能,「你貼 SQL statment,它幫你還原成 Arel 語法」。

當作者 Live Demo 展示完這個工具,全場幾百個 Developer 起立鼓掌了十幾秒。

 
over 4 years ago

先貼解法:

  1. 在 Gemfile 裡加上 ransack
  2. lib/search.rb 的內容換成 https://github.com/xdite/discourse/blob/ransack/lib/search.rb

解釋

這是在上週我為 g0v 架設論壇 時,遇到的問題。discourse 上的搜尋基本上碰到中文和日文漢字不會動。(這裡有 討論串)

https://github.com/xdite/discourse/blob/ransack/lib/search.rb

( 具體 commit 請看 https://github.com/xdite/discourse/commits/ransack 可見所有我的詳細解法)

簡單來講是 CJK 以及非 latin 文雖然在 postgre SQL 上搜尋不好,但還沒到 unsearchable 這麼差。discourse 會搜不到中文,是因為他不用 gem ,自幹 full-text search,結果把切字系統整個搞爛了。我把他拆開,然後適度的導入 ransack 就修好了。

雖然是這樣也花了我 3hr,然後這三個小時我的 FB 牆上寫了滿滿的髒話....

我每次修 Discourse 程式碼或改他們的架構都會覺得他們腦袋是裝屎。

(很抱歉,貢獻程式碼的人都很偉大,照理說我不應批評貢獻者,甚至不應批評人家腦袋裝屎,但實在是大多數的 Rails Developer 去改他們程式碼,半個小時候就會想罵這句話....)

什麼都自幹,login 也自幹,權限系統也自幹,deploy 架構也自幹,search backend 也自幹。自幹就算了,全部都是用錯的想法在想解法,連帶解法也是大便。然後就蓋起一座大便之塔 -_-

 
over 4 years ago

Discourse 是目前 Opensource 界相當受歡迎的一套論壇軟體。通常用來架設技術社群專屬討論區。

Discourse 官方目前的推薦部署模式目前是採 Docker,直接在 Digital Ocean 部署。這個方案可以少去很多不熟 Rails 的人安裝上的求助需求。

但也大大限制了社群未來想 patch 功能的自由性。(社群貢獻代碼和功能的方式,通常是透過 Github Fork 原始碼,拉 pull request 回去,而用 Docker deploy 的架構,很難讓想幫忙的人直接插手)。

而 Discourse 的設計與架構,也與傳統在設計 Rails Application 的做法大大不同(其 Anti-Pattern 真是多到令人髮指)。一般的 Rails Application 都是會設計成使用 capistrano deploy,然後 config 拆開另外放。這樣的好處是 source code 可公開,可讓人自由 fork,config 的敏感資訊又不會被泄露。

這篇文章就是一個引子,讓有心想使用 Capistrano 架設 Discourse 的人可以找到線索架設。

Read on →
 
over 4 years ago

10. 大會其他細節

售票

大會這次在會議前舉辦前四個月前 CFP,還是使用 Eventbrite 這個售票網站。

不過值得一提的是 2012 是使用 Eventbrite App 進行報到,今年則是用紙本。顯然紙本反而速度快太多。

CFP

這次的 CFP 選拔過程極度的的專業,關於 CFP 方法,我前一兩個月寫了另外一篇文章記載方法與過程:由 RailsConf CFP 2014 談客觀的海選辦法

大會網站 / 議程表 / 大會 App

這次大會網站比較沒有什麼亮點,就是蠻精緻的官方頁面。但是值得一提的是大會這次採用了 Guidebook 作為大會指南 App。找議程排自己喜歡的議程非常方便,而且整合了 Twitter,方便追大會公告以及場上動態。

Guidebook 介紹請見我另一篇文章:GuideBook - 製作大會電子手冊的利器

贊助廠商和食物

今年食物區和贊助廠商 (Exhibit Hall)是分開的區域。不過大會用了領 T-shirt 和 HappyHour 這兩個招數逼大家一定要進到 Exhibit Hall 才能領。所以也是會被逼迫逛一下。

不過贊助廠商區還蠻好逛的。因為今年擺攤的都不是無聊的攤位。Code ClimateCode School 都有來。大會也有開放 NGO 擺攤,如 Woman Who Code

不過這裡要小小抱怨的是,贊助商的最小 package 竟然是 15000 美金。真是有錢的公司才玩得起。

11. 贊助廠商觀察

廠商分佈

今年與贊助商的互動與 2012 年就顯得相當薄弱。

(1) 贊助商比較像是義氣來挺的,其實都是社群人創業公司比較多。所以擺攤位來聊天的比較多。連 EngineYard 有擺攤但就沒像之前一樣送東西。

(2) Hosting 贊助出奇多,這次贊助廠商有 RackSpaceEngineYardHerokuDigital OceanLinodeNinefold,而且而且竟然有 Godaddy !!!(BTW,他們竟然也徵 Rails Developer)

(3) 做量測工具的公司顯然很賺錢:New RelicTildeCode Climate。(我會這麼說是因為能夠擺攤的最低門檻的贊助金額是 15,000 美金啊...)

(4) 最有錢的是一艱新的獵頭公司:Hired。他們包下整個展場最中心一大塊,搬來四台 60 吋電視讓大家打電動...。Hired 是做人才競標的。

之前這種展覽都是招人比較多,今年就是聊天比較多而已。

12. 大會工作人員

這麼強的大會工作人員幾個人呢?讓人驚訝的是...六個

(你要想想這是1500人的世界級 event,所以真的超屌的。而且專業程度要求很高,要知道會來這種大會的幾乎都是世界各地 Ruby Group 領導人,社群大神,等等....)

組成成員據說都是大神們的老婆團XD。RubyCentral 主席的老婆,Yehudaz Katz 的老婆.....

老婆團真的很強悍。我去過幾個外國 Conf,幫忙弄住宿和回問題的都是主辦人老婆 XDDD

綜合感想

我實在覺得 RubyCentral 實在太強了。2012 年是 RubyCentral 接回來自己辦的第一屆,這次是第三屆。第三屆的充實程度和豐富程度,遠遠在第一屆之上。

像我最在意的「大會議程內容」方面,就完完全全沒有讓我失望。少了許多社群大拜拜味道,地雷 track 少非常非常多(就算有也容易避開,起碼大 room 的沒有一次是雷),場場都是十分前沿和紮實的 Talk。

再來是 workshop,我也翹了一些議程跑去 workshop,之所以會做這樣的決定是因為大會有僱用 Confreaks 團隊對每場 Talk 進行錄製(每場 Talk 都有三台錄影機在錄以防出包)。但是 Workshop 只有一台,而且多半也不會會後釋出,在幾經考慮下就決定去參加 Workshop 了。

2012 年我不去 Workshop 的原因是因為 Workshop 拜拜性質居多,都是給新手去的場。比如說 CodeSchool 教 Rails 基礎,一些講師教非常基礎的 Rspec 語法和 TDD 入門。

這次的 WorkShop 內容的等級至少都是要有 Rails 2-3 年以上從業經驗的人才適合參加。

而且這些 Workshop,外面自費參加一場(講師多半有自己辦工作坊),價格大概就不止大會票價 750 USD。所以非常非常的值得。

2014 Rails Conf 要說這是我進社群以來參加過最棒的 Conf 也不為過了。

我在這個大會實在學到非常非常多東西。這三篇系列文只是一個綜述,我會再開幾篇寫 Keynote 的心得綜述和 Workshop 的筆記。可能要寫十篇都不為過。


RailsConf 2014 - 十週年紀念版系列文目錄

 
over 4 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 和玩架構設計玩到失控了....

 
over 4 years ago

因為國內學習 Rails 始終有很高的需求。最近我決定跟幾個台灣 Rails 的社群朋友,近日開始舉辦一系列的新手推廣 Workshop。

  • 課本教材:新手教學 Workshop 將會採用 RailsBridge 的官方教材 Intro to Rails
  • 助教:多數助教皆是國內資深 Rails Developer

時間場次:

5/17(六)台北場:http://tw-rails.kktix.cc/events/rails-outreach-taipei-01
5/31(六)台南場:http://tw-rails.kktix.cc/events/rails-outreach-tainan-01

歡迎報名。高雄場正在研擬細節中,也將於近日開設。

若有社群同好想應徵台北場助教,請透過此連結報名:http://tw-rails.kktix.cc/events/rails-outreach-taipei-01-coach

FAQ

  • Q1 : 這個活動要收費嗎?
    • A1 : 此活動免費。但開放「晚報名的人」購買個人贊助票,贊助活動開銷(一人2000)。
  • Q2 : 你們多久會辦下一次?
    • A2 : 我們希望每 2-3 個月可以循環辦一次,視人力與當地助教時間而定。(下一次台北場時間為 7/19 ) 。如果你真的等不了那麼久的話,可以自己先嘗試 Railsbridge 教材,再到 Taipie Rails Meetup 找前輩請教,我相信他們都會很樂意回答問題。
  • Q3 : 你們未來會推出付費的課程嗎?
    • A3: 我個人會開始籌備一系列付費的課程(程度可至獨立開發網站以及求職水準),請密切注意本 blog。
 
over 4 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 (雖然看不懂的可能就是看不懂..還會覺得是垃圾)。

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