l

2018年9月19日 星期三

擁抱改變,遠離Hard Code

September 19 08:37~09:12

Steve Jobs and the Apple Lisa

▲圖片來源在此


寫死(Hard Code)

幾天前一位朋友在Facebook上發問:「如何對非資訊人員解釋寫死(hard code)?」

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

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

***

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

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

***

適合(Fitness)

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

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

螢幕截圖 2018-09-19 08.58.47


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

***

結論

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

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

擁抱改變,遠離Hard Code

***

友藏內心獨白:什麼是Lisa電腦?

2018年9月18日 星期二

報恩

September 18 08:58~10:39

螢幕截圖 2018-09-18 10.38.19

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


故事一

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

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

在無計可施之下,Teddy想起念書時在物件導向分析與設計(OOAD)課程學到的RUP(Rational Unified Process;統一軟體開發流程)。RUP的三大支柱:Use Case DrivenArchitecture CentricIterative and Incremental Development(IID),是不是能在Scrum中使用?

***

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

RUP把軟體開發分成四個phase:InceptionElaborationConstructionTransition。在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比較讀得懂這一套書。

***

結論

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

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

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

***

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