擁抱改變，遠離Hard Code

September 19 08:37~09:12

▲圖片來源在此

寫死（Hard Code）

幾天前一位朋友在Facebook上發問：「如何對非資訊人員解釋寫死（hard code）？」

維基百科對於寫死的解釋如下：

寫死（英語：Hard Code或Hard Coding）是指在軟體實作上，將輸出或輸入的相關參數（例如：路徑、輸出的形式或格式）直接以常數的方式撰寫在原始碼中，而非在執行期間由外界指定的設定、資源、資料或格式做出適當回應。一般被認定是種反模式或不完美的實作，因為軟體受到輸入資料或輸出格式的改變就必須修改原始碼，對客戶而言，改變原始碼之外的小設定也許還比較容易。

***

以上解釋，清楚明白，資訊人員一定看得懂，但對非資訊人員可就不好說。昨天Teddy在讀《溫伯格的軟體管理學：第一級評量》看到一個例子：

一間荷蘭公司買了六台Apple Lisa電腦，想試看看能否推廣到整個實驗室使用。誰知Lisa的列印功能被寫死只支援美國標準規格的信紙，不支援歐洲標準規格的信紙，而且使用者也無法自行設定信紙大小（因為信紙大小寫死在程式中）。最後六台電腦全被退貨。

***

適合（Fitness）

在Lisa的故事中溫伯格提到：「一個系統換到新的環境，品質也會改變。……在某些美國人眼中Lisa是一種高品質的電腦。很少有歐洲人這麼認為。」。

以上這個觀念可以用建築師Alexander的pattern框架來解釋，如下圖所示：

▲同樣的Form（Lisa電腦），移到不同的Context（美國或歐洲），原本的好品質／好設計，就可能變成爛品質／爛設計。所以Alexander說：「好設計是Form與Context的適合關係。」

***

結論

寫死的程式碼降低軟體系統（Form）適應不同Context的能力，只要使用的情境改變，原本可以動的程式或功能可能就無法使用。

在大部分的情況下，開發人員請記住以下格言：

擁抱改變，遠離Hard Code。

***

友藏內心獨白：什麼是Lisa電腦？

報恩

September 18 08:58~10:39

▲窗外的浪浪吃飽就睡，何時會上演「貓的報恩」XD

故事一

好幾年前參與第一個Scrum團隊的產品開發，該軟體產品必須支援很多軟體與硬體平台，牽涉到韌體與驅動程式，還要與一些特殊的嵌入式系統溝通。這些軟、硬體平台數量眾多，不但經常改版，並且附贈不少bug。

當時Teddy遇到一個很頭痛的問題：「怎麼設計軟體架構？」因為跑Scrum，不能用傳統瀑布式開發那一套，先花個幾個月收集需求，再花個幾個月設計架構。當時關於在敏捷開發中如何設計軟體架構的資料非常少，能找到的資料也只是提個大方向：「敏捷開發中軟體架構是隨著每個迭代週期長出來的」。

在無計可施之下，Teddy想起念書時在物件導向分析與設計（OOAD）課程學到的RUP（Rational Unified Process；統一軟體開發流程）。RUP的三大支柱：Use Case Driven、Architecture Centric、Iterative and Incremental Development（IID），是不是能在Scrum中使用？

***

敏捷開發方法原本就是迭代與增量，把use case driven換成user story driven，如此一來套用architecture centric的作法似乎也是非常自然的一件事。

RUP把軟體開發分成四個phase：Inception、Elaboration、Construction、Transition。在elaboration結束時大約完成最重要的百分之二十use case，此時軟體架構雛形也大致成形。聽起來很簡單，實際上要在Scrum中套用此原則也不難，唯一需要注意的一點是：「你怎麼知道這最重要的百分之二十use case（user story）是什麼？」。

跑Scrum當然你會有Product Backlog，但這是一個內容隨時間異動的產品功能代辦清單。如果Product Backlog裡面只有接下來1~2個sprint所需要的詳細user story內容，有可能「看得不夠遠」，導致於軟體架構在每個迭代中不斷地（大幅度）修正。所以必須依據專案的特性，包含專案大小、上市時間、複雜度、不確定性等因素，自行判斷需針對這最重要的百分之二十的user story（百分之二十只是一個概念，不一定就是百分之二十，在敏捷開發中這個數字也許越低越好），需要做多少事前設計（up-front design），才能讓團隊的軟體架構成形。

***

故事二

N年前台灣政府砸錢推廣CMMI，當時Teddy還在念書，因故到校外上了介紹CMMI的課程。在學校也修了個人軟體流程（Personal Software Process），體驗了一學期「沒人性」的度量與改善之軟體開發方法XD。

Teddy所認識接觸過CMMI的台灣軟體工程師，幾乎每一個人對它的評價都是「罵聲連連」。CMMI本意良善，可惜在台灣的落實方式變成一種快速拿牌的「文件化流程」。為了長官的績效，為了亮點，原本的精神所剩無幾，徒留形式。

這一陣子Teddy花了一些時間閱讀溫柏格的《溫柏格的軟體管理學》這一套四本「老書」。溫柏格在書中提出「軟體工程文化模式」，包含以下幾個等級：

• 模式0：渾然不知型的文化（Oblivious）
• 模式1：變化無常型的文化（Variable）
• 模式2：照章行事型的文化（Routine）
• 模式3：把穩方向型的文化（Steering）
• 模式4：防範未然型的文化（Anticipating）
• 模式5：全面關照型的文化（Congruent）

模式1~模式5基本上就對應到CMMI Level 1~CMMI Level 5。針對處於不同軟體工程文化模式的公司或團隊，遇到問題時有不同的反應方式。溫柏格這四本書利用幾個簡單的模型（model）來介紹他的軟體管理學，包含：系統性思考、軟體工程文化模式、控制模型、薩提爾的人際溝通模式。

這四本書（中文版）加起來約2200頁，但因為以前 被迫 學過一點CMMI的皮毛，沒想到N年後居然出來報恩，讓Teddy比較讀得懂這一套書。

***

結論

有些人覺得從事軟體開發工作不須要念研究所，大學畢業就很足夠了。因為台灣的研究所教的內容與社會脫節，還不如早早出社會從實戰中學習。也有些人盲目念研究所，只因為鄉民都念了我沒念好像怪怪怪。

不論哪一種情況，大學或研究所教育，雖然求學的當下看起來很多都跟「社會脫節」，但世事難料，就看每個人對於所謂的「社會」的時空定義是什麼。

很多時候，基本功夫做好，才是伴隨自己一生的最佳夥伴。

***

友藏內心獨白：溫故知新。