分類
Agile Programming Ruby

物件導向程式的九個體操練習

最近在翻 The ThoughtWorks Anthology(知名軟體顧問公司 Thoughtworks 出的文集),裡面有篇 Object Calisthenics 蠻有意思的。

好的物件導向設計很難,我們都很同意何謂好的設計原則:高內聚力(cohesion)、低耦合(loose coupling)、不重複程式(Don’t Repeat Yourselp)、封裝(encapsulation)、可測試性、易閱讀性等等,但是實際寫的時候卻不容易化身為一行行的程式碼。這篇作者列了九條規則,並建議你練習寫個千行程式嚴格遵守看看,用以改善你的OO實作能力。

初次看到這九條時覺得有點誇張,但其實濃縮了不少OO想法在裡面,如果有閱讀過重構或物件導向設計原則等概念,應該能夠聯想到很多東西,挺有趣的。

1. 每個函式裡面只能有一層縮排,如果需要多一層,請多寫一個 method 去呼叫。

這個規則其實就是要求嚴格遵守 Compose Method:將邏輯操作轉換為細目等級相同的步驟,避免過深的邏輯而無法迅速了解,相信大家應該都有看(寫)過M型程式吧 :p

2. 不要使用到 else 這個關鍵字。

避免寫出複雜的 nested conditional 程式。不論是”重構“或是”重構-向範式前進“這兩本書,都有很多篇幅花在討論如何簡化條件邏輯,作法包括

a. 重構一書提到的 Replace Nested Conditional with Guard Clauses 方式,直接使用 return 返回,不要再 else 了。

b. 請愛用 Ternary Operator:也就是 boolean-expression ? expr1 : expr2。很多簡單的 if else 都可以用 Ternary Operator 簡化到一行一目了然。舉個 Ruby code 例子:


if ( is_something )
"foo"
else
"bar"
end

如果改成三重操作子就俐落多了:

( is_something )? "foo" : "bar"

另外初心者也常寫出根本不需要 if else 的情況:

def is_foobar
if ( a > 0 )
return true
else
return false
end
end

其實只需要這樣就可以了:

def is_foobar
( a > 0 )
end

c. 第三招要先念點書,請善用物件導向的多型(polymorphism)能力,請參考設計模式的 Strategy pattern 或重構的 Replace Conditional with Polymorphism

分類
Agile Books

實戰敏捷開發 Practices of an Agile Developer (3) 測試篇

上一章談了來自客戶的 Feedback,這一章作者談另一種回饋機制:透過程式測試得知目前開發的情形(Coding Feedback!)。

Put Angels on Your Shoulders (讓測試當你的天使)

Code 一直在變,我們需要一種持續又快速的 feedback 告訴我們這些程式碼建不健康:是我想要的程式嗎? 最後的 commit 有沒有弄壞任何東西? 這時你需要的一種機制可以一直幫你確保這些,也就是自動化的單元測試(unit tests)。

因為測試的流程總是 1.Setup(設定初始資料) 2.Exercise(執行某些操作) 3. Verify(驗證輸出結果與預期相同) 4.Teardown(清空資料),所以目前每套程式語言一定都會有一套 xUnit framework 的測試框架可供使用。

另外還可以加裝一套 continuous build 工具(例如 CruiseControl),它可以自動 checkout 最新的程式碼並測試,一旦有人送交了有錯的程式碼,馬上就可以通知並修正(這時候fix bug最簡單且成本最低)。

當你的 unit tests 達到 Regression tests 程度時,這時候做重構(refactoring)時就有更大的自由(自信),因為不需要擔心改爛了什麼你不知道的東西。

另外搭配 test coverage 工具可以幫助你有個大概的鳥瞰。寫 test 像是一個聰明的投資,因此報酬效率也很重要,trivial method 不需要寫,把火力放在你最擔心出錯的地方。

Use It Before You Build It (用之前先測試怎麼用)

這節進一步談測試驅動開發(TDD),在寫程式前先寫好測試程式。透過先寫測試程式,可以從使用API的觀點來思考怎麼寫程式、怎麼設計API,因而寫出更好用、一致及簡潔的程式介面。

Different Makes a Difference (差一點差很多)

在我這台沒問題啊,為什麼換一台電腦就不對了? 只要換一個平台(即使是不同版本的作業系統),不同就是不同,而太晚發現這樣的問題要修理是非常麻煩的,尤其是正要 release 的時候才發現它沒辦法在某某你想要的平台上執行。

我們當然可以要求 QA team 要在不同平台上測試,但是如果他們只是手動測試,就不如自動測試來的及早發現。我們已經會在 commit 程式前在自己電腦上執行一次 unit testing,現在要做的事情是要在你所要支援的不同平台、不同版本上再測試一次。不過好累啊,這時候就必須靠 continuous integration 工具來幫忙,每當有人 commit 時,這個工具就會自動 checkout 出來執行測試,我們分別在不同平台(例如可以使用 VMware 或 Virtual PC)上設定好這個工具來做自動化測試。

Automate Acceptance Testing (自動化驗收測試)

重要的商業邏輯除了 unit testing,還需要驗收測試獨立於所有程式之外,而且客戶必須親自驗證這個結果。也因為因此,我們需要一個工具讓客戶也可以新增編輯跟修改驗收測試(without coding),

這本書介紹的工具是 fit.c2.com/,它使用 HTML table 當作定義的介面,客戶可以直接編輯加入新的功能,接著加入可能的輸入與正確的預期值。然後 developer 再根據這個 table 產生 fixtures 資料,並比對測試結果是否成功。

感覺像是協力式的 unit testing,你還是必須自己寫測試,只是必須有別人提供你什麼是正確答案。

Measure Real Progress (測量真正的進度)

紀錄花了多久做事提供了很好的 feedback,可以幫助專案計畫、估計跟效率測量。但是一般常用的 timesheet 多半用於薪水用途而非真正花費的時間,這點要特別注意。另外常用的紀錄完成百分比,作者也認為很沒用。一個比較好的方式是紀錄 1.估計多少時間 2.已經花了多少時間 3.估計還需要多少時間來完成。根據真正花了多少時間的經驗,加以比對一開始的估計值,可以獲得很好的經驗用於估計下一個類似的任務。

紀錄真正的時數對於使用 backlog(要完成的任務清單)和 Iteration 也非常重要,如果剩餘的時間超過這次 Iteration 了,就知道必須移動某些任務到下一個 Iteration,反之則有時間多加工作。

最後是注意紀錄的時間單位,以分鐘太細了,以週就太粗囉。我們的經驗是超過一天的 Ticket(Issue) 應該都可以想辦法拆小,1hr、2hr、4hr、8hr 應該是不錯的範圍。

Listen to Users (聆聽使用者)

作者在這章最後特別提了使用者的回饋。即使有寫測試程式,我們還是很容易忽略來自真正使用者的聲音。每一個使用者的抱怨都有其道理,盡量試著找出真正的問題,而不是怪罪使用者不懂、不了解系統如何操作。
程式Bug、文件Bug、使用者會認知錯誤也要算是Bug。而不是讓客服人員回答說:喔,那不是Bug, 你犯了一個大家都會犯的錯誤。即使聽起來很笨,也應該去試著聆聽。

分類
Agile Books

實戰敏捷開發 Practices of an Agile Developer (2) 需求篇

這一章是 Delivering What Users Want。我們總是幻想客戶一開始就確切告訴我們需要什麼,然後做完收工拿錢即可。不過事實總是中途加入一開始沒有提到的功能跟規格變更。敏捷開發不去試圖”擊敗”這些變更,而是把重點放在如何快速辨認及適應這些改變,並在時程及預算內做出真正符合用戶需求的軟體。

分類
Agile Books

實戰敏捷開發 Practices of an Agile Developer (1) 專業態度篇

敏捷軟體開發一直是我們內部開發的核心概念,強調個人、合作、回應和使用工作軟體(wiki, version control, unit testing, build automaion),2001年由一群軟體開發者發表宣言如下:

  1. 個人及互動勝於流程與工具
  2. 可用的軟體勝於詳盡的文件
  3. 與客戶合作勝於合約談判
  4. 回應變化勝於墨守計畫

軟體開發是連續(continuous)的,不是最後才測試,也不是最後才佈署,更不會停止收集需求跟feedback。正是因為開發軟體是如此複雜的活動,任何種類的錯誤如果不儘快修正,往往最後就會無法控制的失敗,因此唯有每天不斷的一點一滴的去修正,每天解決一些比較小的問題而不是最後脫韁野馬的大問題,這才是解決的辦法。

何謂 Agility 的定義,作者給了:
“Agile development uses feedback to make constant adjustments in a highly collaborative environment.” (敏捷開發是一種在高度合作的環境中不斷根據回應來做修正的開發方式)

透過經常性地建構出可以實際使用的軟體,我們持續得到 feedback。程式碼會因為需求擴充而不斷地被修改重構演進。工作的流程被拆成一至四周的短 iterations,每次透過 demo 得到 feedback,確保方向正確。

敏捷開發最大的不同到底是什麼呢? 這本書不談方法論流程(XP、Scurm等),而是談人本身,談團隊本身,談如何成為一個敏捷的開發人員。書的每一章由數個 Tips 組成,整本書共45個 Tips 來敘述什麼是敏捷的做法。這本書也得到2007年的 Jolts Productivity Award

前兩章 Beginning Agility 跟 Feeding Agility 講的是基本的專業態度: