昨天傍晚收到出版社編輯的通知信，告訴 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 會是一件相當有挑戰性的工作，但是如果想要有效率的開發出高品質的軟體，那麼請問有那一件軟體開發的活動不是這樣呢？有一些剛開始看起來好像很簡單或是很省事的做法，其實反而是造成後續軟體持續開發困難的原因。例如，因為「專案
***
友藏內心獨白：這一篇是在 MacBook Air 上用 Apple 的外接藍牙小鍵盤所完成的。Bye bye，Ubuntu...。
如果少數的 branches version control 如 git 是可以幫助的，如果太多甚或功能差太大，架構改寫及 Build system 的確是需要的。
回覆刪除