擁抱改變，遠離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比較讀得懂這一套書。

***

結論

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

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

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

***

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

我沒有被盜帳號之Scrum新詩

August 24 18:09~18:41

好詩、好詩

前幾天在搞笑談軟工Facebook社團貼了一首詩：

我的目標

我想要愛你，而不控制你；
欣賞你，而非評斷你；
與你一起，而不侵犯你；
邀請你，而非強求你；
離開你，無須多言歉疚；
批評你，而非責備你；
並且，幫助你，但不看輕你。
如果，我也能從你那裡得到相同的，
那麼，我們的相會就是真誠的，
並且，會豐盈彼此。

朋友看到嚇了一跳，以為Teddy被盜帳號。這首詩的作者是已故家庭治療大師Virginia Satir（維琴尼亞 薩提爾），出版於《Making Contact》。上面的翻譯是取自於簡中版《與人聯結》，以下為繁中版的翻譯，與簡中版稍微有點差異：

我的目標

我想要愛你，而不抓住你
感激你，而不評斷；
參與你，而不侵犯
邀請你，而不要求；
離開你，而不歉疚
批評你，而不責備；
並且，幫助你，而不是侮辱。
如果我也能從你那裡得到相同的
那麼，我們就會真誠地相會
而且，豐潤了我們彼此。

***

與人接觸

讀到這首詩的第一個反應：「耶，這不是理想ScrumMaster的內心獨白！應該列為ScrumMaster必背新詩。」但後來想一想，不只是ScrumMaster，每個人都可以把薩提爾的「我的目標」當成自己的目標。

如同《薩提爾的家族治療模式》中所提到：生存的姿態，不需要討好、指責、超理智和打岔；只需要一致。

提高自己的價值感，保持一致性，你也可以達到薩提爾的目標。

***

友藏內心獨白：所有的問題都是人的問題XD。

好的理論就是最好的實踐

August 23 23:28~24:00；August 24 00:~00:28

▲貼上封印的實務做法將使電腦無法洩露資料… （黑人問號？？？）

施展不開的苦惱

Teddy有一個很認真學習的朋友，有機會就到外面上課進修。最近這位朋友告訴Teddy他在學習上的一個困擾…

朋友：我上了很多課程，尤其是實戰班，我都有好好的練習。只要我回公司之後，在工作上遇到的問題跟上課時所教的問題一樣，我就能夠處理。但是，只要稍微有點不同，我就不知道要怎麼處理。

聽完朋友的敘述，Teddy的第一個反應就是—「你只是照著人家教你的特定招式練習，你根本沒有真的學會啊。」這種學習模式，只要情境稍微改變，原本罐頭式的解決方案很可能就派不上用場了，而你又不知該如何調整原本的罐頭，讓它在新的情境中派上用場。

***

理論和實務

理論和實務，經常被視為學習天平上的兩端。理論給人的感覺就是抽象、嘴砲、和社會脫節、無法實戰等。實務給人的感覺就是具體、立即可上手，就好像武俠小說中吃了天山雪蓮一樣，立刻增加一甲子的功力。

實務就好像例子（example or instance），非常具體、容易理解且容易照做。如果實務所描敘的情境（context），與問題（problem）和你工作上所遭遇的相同，便可立即套用。但通常越具體、越實戰的實務，其適用的情境也越特定（越窄）。所以，同一種「類型」的問題，可能衍生出數種甚至數十、數百種例子。如果沒有理論基礎的支援，沒有建立分析問題的框架或模型，需要靠自己慢慢地累積各種實戰經驗，然後再抽象化成為自己腦中的解題模型。這是一個冗長的過程，很多人還沒走完這個過程就放棄了，永遠都在「學例子」，而沒有學到例子背後的共通理論基礎。

***

建立收納知識框架

這幾天在某本書（這幾天看的書比較多，忘了哪一本。應該是溫柏格的某本書中引用另外一個人的話，要再找一下）讀到一句類似的話：

好的理論就是最好的實踐，因為它放諸四海皆準。

真是太有道理了。如果你的學習過程，發現自己都在忙碌的收集流行術語，以及參加各種經驗分享，搞到最後自己越學愈心慌。此時就應該停下來思考一下，你有看到人家背後的理論基礎、框架或模型嗎？

舉個Teddy自身的例子，Teddy博士論文的題目是「Java例外處理設計與重構」。一開始Teddy並不是研究這個題目，而是先研究pattern language，幾年後改研究design by contract裡面的contract specification。design by contract其實包含了contract specification與exception handling，但當時Teddy覺得exception handling太難，雖然有很多程式範例與所謂的best practices，但就是缺少一個理論框架，所以這一大堆例子與best practices在實際應用的時候經常互相衝突或不足夠完整解決問題。柿子挑軟的吃，所以Teddy一開始只研究contract specification。

後來陰錯陽差，花了許多時間研究exception handling，也建立了一個理論框架（很簡單的理論XD）來解釋例外處理設計的問題。有了這個框架，分析與設計應用系統的例外處理就變得很有系統化。

***

要怎麼從別人的教學中建立知識框架？最重要，也是最簡單的一點，就試看看教學者有沒有給你源頭參考資料。有些人強調自己的內容就是「原創」，但事實上這個世界真的「原創」的知識非常少，絕大部分都是建立在前人的知識體系上增加價值。好的實例，應該要建立在某些理論基礎之上。上課時可以不談這些理論基礎，但必須要提供參考資料，讓學習者課後有機會可以藉由進一步學習理論基礎來建立收納知識的框架以及培養自我解決問題的能力。

小心「斷水流式」的第二手 （第或N手）知識傳遞，無法追源溯流的知識只能在非常特定的情況下使用，跟「呼名大法」（請參考〈自我感覺良好神功（１）：呼名大法〉）相去不遠矣。

***

友藏內心獨白：巨人知道你站在他的肩膀上嗎？

自我感覺良好神功（１）：呼名大法

August 21 09:14~10:16

▲前天在Facebook發了上面這則短文，有朋友跟Teddy反應，這文pH值太低，讓人看了「不蘇胡」，是不是又在暗中酸人？

呼名大法

▼前天讀了《溫伯格的軟體管理學:第一卷》，p.73這段話，才知道「呼名大法（name magic）」這種說法。當下有感而發，改寫書中的句子才在Facebook貼了那段文。

呼名大法讓Teddy想起很多往事。其一，多年前有一陣子design thinking很流行，有一次Teddy跟一位朋友開會，會議中對方不斷 呼叫 提到design thinking，好像它是一種解決任何問題的萬靈丹。因為Teddy才疏學淺，完全不知道design thinking是什麼，於是弱弱問了一聲：「什麼是design thinking啊？」

沒想到對方突然停了三秒，然後笑笑地說：「其實我的專長也不是design thinking，而是service design」，就這樣結束這回合。

類似例子不勝枚舉，有一次在會議中聽取簡報，報告者不斷強調：「我跟XXX和YYY（兩個中央政府單位）的關係非常好，我已經跟他們都談過了，把產品推到全國幾百個ZZZ單位絕對沒問題」。

此時Teddy弱弱問了一聲：「請問你已經談好幾個單位了？」此時對方才說：「談過一個，但A、B還有C也都非常有興趣。」就這樣結束這回合。

其他舉凡像是：買書不看書，然後告訴別人「啊，這本書我也有」；開口閉口必稱某某大神是你的老師或朋友；自稱年薪幾百萬的矽谷工程師；Google/Apple/Microsoft的員工（或前員工），大概也都有點呼名大法的味道。

一言以蔽之，呼名大法就是A Name Without Quality（有名無實）。

***

人人都會呼名大法

雖然Teddy看似在批評呼名大法，但其實這個招式Teddy自己也常用（遮臉），相信大家也都用過。

呼名大法的用途其實很多，包括：

• 讓學習者自己心安，形成短時間增加大量能力的表象
• 抬高身價，意圖使人覺得自己好棒棒
• 跟上潮流，潮到出水
• 增加聊天話題
• 因為弄假成真而促成一些事情發生（可能是好事，也可能是壞事）

成本低、效益大的好招式，不用嗎？

***

破解呼名大法

有一個很簡單的方式可以知道對方是真的懂，還是在施展呼名大法：請對方解釋「名字」的意義。大部分施展呼名大法的人這一關就過不了，但還是有些功力高強的人可以跟你扯上幾句。這時候只要再補上「為什麼」，就可以讓呼名大法現出原形。

***

結論

社會在走，「名詞」要有。技術日新月異，怎麼可能把所有的東西都學會？偶而施展呼名大法，可以讓對話順暢，而不糾結在一些非重點項目。但認真討論事情時，切記勿把別人的力量當成自己的力量，否則說得難聽一點，呼名大法就變成唬爛的一種形式。

***

友藏內心獨白：先嚇嚇他。

薩提爾變革模型

August 20 21:29~22:28

▲薩提爾變革模型，節錄自《溫伯格的軟體管理學:第四卷》 p.67

薩提爾變革模型

這兩年台灣談敏捷（Agile）的人與組織越來越多，嘴砲派、實務派、反對派、隕石派、佛系派等紛紛崛起。從狹義的軟體開發，到廣義的食、衣、住、行、育、樂，似乎萬事皆可敏捷。

談敏捷，就不能不談改變。敏捷談的是靈活性，如何在不斷改變的環境中獲得成功。無論是個人還是組織，要增強對改變的適應性，就不得不回應改變，也就是自己也要持續改變。

改變所帶來的成長總是伴隨著痛苦，因此變革失敗的例子不勝枚舉。在《溫伯格的軟體管理學:第四卷》中，介紹「薩提爾變革模型」，可以運用這個模型來分析變革應採取的行動。

「薩提爾變革模型」指出發生變革的四個階段：

• 近期現狀階段（舊有現狀）：個人或組織的現況，通常表示某種穩定與平衡的成功狀態，大家都熟悉現有的做法。

組織會一直停留在這個階段，一直到「有人」攪亂一池春水，才會打破現有的平衡。這個「有人」，通常是外來事件或外部人員，並不在系統控制者的控制範圍內。例如，外部顧問的加入、重要成員離職、競爭對手發布比我們更好的產品。

• 混亂階段：既使組織想要推遲改變，但最終因為無法逃避的外部因素，導致只好承認現況無法應付未來的挑戰。之後系統進入混亂階段，原本熟悉的工作模式與方法不再適用，但新的做法卻還未被確定。在此階段人們嘗試各種可能性，甚至走回頭路尋找更早期的成功模式。
• 整合與實踐階段：經過一段兵荒馬亂的時期，有些新的構想與方法存活下來，似乎可以應付新的挑戰。但組織還不確定，需要更多的實踐與改造，才能讓組織有效適應新的方法，提高組織的績效。
• 新現狀階段：整合與實踐階段成功便進入新現狀階段，組織重新獲得平衡，不熟悉的工作模式變得熟悉。

***

有什麼用

這個模型告訴我們幾件有趣的事：

• 牛頓運動定律說：「靜者恆靜，動者恆動」。組織停留在近期現狀階段的力量往往非常強大，由組織內部自發性所引發的變革往往十分困難。因為組織與個人會不斷地否定問題，迴避改變的必要性，這也就是薩提爾所說的熟悉總是比舒適更有力量。畢竟，待在舒適圈的力量真的太強，只要舒適圈依然存在，又何必做出改變呢。所以，要讓組織脫離舊有現狀，經常需要藉由外部力量來推動。
• 當外部力量介入，組織正在嘗試找出新的工作模式時，此時的混亂階段不宜帶入更進一步的改變，否則組織將會因為無法接受過多的改變，因而放棄走回原本的老路子。例如，組織想要導入Scrum，在團隊剛開始接觸Scrum的前3~6個月內，已經被敏捷精神與Scrum框架搞得一個頭兩個大，此時若持續導入新的工程技術，例如TDD，可能使得團隊無法負擔，最後決定還是用原本的開發方式比較「有效率」。
• 在整合與實踐後期導入新的變革會比在新現狀才導入要來得好，因為到了新現狀之後，不久新現狀就會變成組織的舊有現狀，此時引入變革的阻力又多了起來。
  

***

結論

鄉民們可以試著幫自己學習新事物或組織引入新方法的過程對應到薩提爾變革模型，看看目前處在什麼階段。如果一直處在舊有現況，是不是需要帶來一些外部衝擊，就算目前組織現況是「一攤死水」，好歹也可以引起一些漣漪。

有些人很喜歡到處上課，有活動就參加，不吝惜投資自己。但會不會讓自己一直處在混亂階段，而沒有時間去沉澱與實踐所學的技能？

這些都是值得思考的議題。

***

友藏內心獨白：變革需要時間，就跟自己開發瀏覽器一樣。

為了快，你損失了什麼？

August 15 14:33~16:14

問題

三不五時會聽到來自不同公司的朋友提起他們sprint planning meeting的進行方式…

在會議進行的時候，我們分別請UX/UI設計師與程式設計師分組估算他們各自擅長的工作，以便減少會議的時間。反正雙方人馬都不懂對方的工作性質與內容，一起討論實在是很沒效率。

這樣子做，好嗎？

***

緬懷大師

2018年8月7日，也就是一個禮拜前，軟體工程界大師Gerald M. Weinberg（傑拉爾德‧溫伯格）以85歲高齡過世。溫伯格一生寫了很多書，以生活化、輕鬆且風趣的筆法說明艱澀無趣的軟體工程觀念與方法。他的過世，著實是軟體工程界的一大損失。

在溫伯格與Donald C. Gause合寫的《Exploring Requirements: Quality Before Design》（中文版《從需求到設計：如何設計出客戶想要的產品》）書中提到：

發現什麼不重要，重要的是發現（探索）的過程…探索需求的工作事實上就是建立一個團隊。

沒錯，探索需求的工作事實上就是建立一個團隊。只為了「快」就將Scrum團隊依據「專長」畫分成小組，讓小組各自討論得出估算值。這種做法只比讓專案經理或團隊主管一人制定時程要來得好一點，但卻失去了Scrum建議組成跨職能團隊（cross-functional team）的目的，變成「跨職能團隊中的元件小組（component group）」。

***

大師開示

在溫伯格的書中接著提到，若以下任一條件不符合，專案就很可能失敗：

1. 了解需求要件
2. （大多數都）貫徹始終參與專案
3. 知道如何使團隊有效運作

《Exploring Requirements: Quality Before Design》這本書是1989年出版，距今29年前，相信那時候Scrum應該還沒有正式誕生。有跑過Scrum經驗的朋友請回顧一下，這三點是否也都包含在Scrum之中呢？

***

友藏內心獨白：不需要做的事情，就不需要把它做好。