l

2012年1月20日 星期五

Single Code Base

January 20 10:11~11:51


昨天傍晚收到出版社編輯的通知信,告訴 Teddy 出版社已經通過編輯小姐所提的出書提案。雖然書本的內容還是需要加以增修,不過 Teddy 預估如果沒什麼意外的話今年內出版應該是沒問題了。想捧場買一本的鄉民們可以把小豬撲滿拿出來開始存錢了...大概一天存個3-5塊新臺幣也就夠了。或是考慮把年終獎金尾牙抽到的獎金、過年領到的紅包留個幾百塊下來,不要全部都「梭哈」在牌桌上...XD


***


話說 Teddy 昨天還在擔心無料可寫,想來想去還是回頭找「老朋友」,從以前看過的書中擠一些東西出來。今天來談一下 Kent Beck 所寫的 Extreme Programming Explained, 2nd 這本書第 67 頁所提到的 Single Code Base 這個做法。還記得當年第一次看到 Single Code Base 這個做法其實沒什麼特別的感覺,但是剛剛拿出來又看了一次之後,突然聯想到這個做法回答了一個軟體開團隊發經常會遇到的問題:


不同的客戶,對於公司所開發的產品有不同的客制化需求


對於這個問題基本上有兩個解法:

  • One code base for one customer: 只要有一個新客戶的客制化需求,就把 source code 從原本的開發主幹中複製一份(或是產生一個分支)出來。
  • Single code base: 不論有多少個客戶,多少種客制化需求,全部都放在一個單一的開發主幹中。

第一種作法看起來比較簡單,在剛開始客戶還不多的時候問題也不大,反正就是把原本的 source code 複製一份,然後在加上客制化的功能,最後打包給客戶驗收過後就沒事了。就算事後出包也是交給所謂的「維護合約」以及倒霉的「維護人員」去處理。


但是當客戶數量變多的時候,第一種作法就很有可能會產生很嚴重的「維護問題」。假設這個產品有 30 個客制化的版本,開發團隊某一天解決了一個在最原始那個版本中的 bug,請問這個 bug fix 要不要套用到其他 30 個客制化版本上?


感覺起來好像也許可能應該似乎要套用,但是,這 30 個客制化的版本已經各自「演化」一段時日了,要確定這個 bug fix 可以安全的套用到這 30 個客制化版本而不會產生新的 bugs 會是一件很花時間的工作。聰明的鄉民們可能會說:「不是有自動化測試案例可以用來驗證新的 bug fix 嗎?」套句賭神電影裡面的對白:「年輕人終究是年輕人」,果然是涉世未深。這裡是哪裡?台灣耶,就算是只有單一個軟體版本都少有人在寫自動化測試案例了,誰在跟你寫 30 個客制化的版本的自動化測試案例啊。想要知道血淋淋的慘案,請參考「600 多個 bugs 要怎麼修?」。

***

在課本第 68 頁,Kent Beck 叔叔告訴我們:


Rather than add more code bases, fix the underlying design problem that is preventing you from running from a single code base.


鄉民們可以把不同客戶功能差異的部分移到設定檔中,設計軟體系統使其可以經由讀取設定檔的方式來產生不一樣的行為。接著修改建構系統(build system)讓它可以從 single code base 裡面生出不同客戶所需要的客制化產品(安裝程式)。


要達到 single code base 會是一件相當有挑戰性的工作,但是如果想要有效率的開發出高品質的軟體,那麼請問有那一件軟體開發的活動不是這樣呢?有一些剛開始看起來好像很簡單或是很省事的做法,其實反而是造成後續軟體持續開發困難的原因。例如,因為「專案太敢 太趕」沒時間而省略不寫自動化測試,因為客制化要求而捨棄 single code base,因為沒人懂而不做持續整合,因為有人不爽而不做 pair programming 等等。


***


友藏內心獨白:這一篇是在 MacBook Air 上用 Apple  的外接藍牙小鍵盤所完成的。Bye bye,Ubuntu...

1 則留言:

  1. 如果少數的 branches version control 如 git 是可以幫助的,如果太多甚或功能差太大,架構改寫及 Build system 的確是需要的。

    回覆刪除