ISO 大戰乖乖

06/30 22:11~22:48

Teddy 今天從同事 A 先生那裡聽到一個真人真事的笑話。話說 A 先生在之前服務的公司有導入 ISO 的經驗，有一次某位來自香港的 ISO 稽核員到該公司的機房查核，看到裡面擺了一包『乖乖』。

稽核員：機房裡面不是不可以有飲料和食物嗎，怎麼會有『乖乖』？
A 先生：這不是拿來吃的。
稽核員：那這是？
A 先生：放『乖乖』可以保佑我們的 servers 不出問題。
稽核員：現在都科學時代了，還這麼迷信。
A 先生：這是我們的『信仰』，請尊重。而且賣我們機器的供應商也建議我們這麼做。
稽核員：遇到火星人（這一句沒說出口）。
稽核員：就算你們不吃，食物還是會引來老鼠，危害資訊設備。
A 先生：我們機房有防鼠設計，縫隙都用膠條密封起來，不會引來老鼠。
稽核員：如果有員工偷吃呢？
A 先生：我們機房有門禁和 24 小時錄影，不會有人在裡面偷吃東西。

就這樣一來一往過了 30 分鐘。

稽核員：好吧，我就不把這點記錄為主要缺失，只記為觀察項目。
A 先生：YES! (喊在心裡)

事後 A 先生把乖乖放在一個透明密封的盒子中，並在前方擺上一張『請勿食用』的告示牌，還有在文件中紀錄要定期更換乖乖等注意事項。

Teddy 問 A 先生，怎麼不把乖乖拿出來就好了，幹麼這個麻煩？基於兩個原因 A 先生說不行：

• 萬一拿出來之後真的出事，誰要負責？（那是銀行的機房，servers 如果當機事情很大條）。
• 如果拿出來就承認這是一個『主要缺失』，事後的矯正措施要寫一堆文件，加上後續改善追蹤，很麻煩，當然要硬ㄠ下去。

結論：一字曰之『猛』。

***

友藏內心獨白：原來 A 先生的 嘴砲功 幽默感是這樣訓練出來的，佩服，佩服。

拜託，這是 Scrum 耶

06/29 20:30~21:30

台灣人真的很厲害，在國外實施很好的制度，勇敢的台灣人總是能在極短的時間內移植到台灣來。當然台灣人不會吃飽沒事找事做，畢竟導入新制度還是需要付出『成本』。所以，這種導入通常都是有某種的好處，例如：

• 號稱可以提昇服務或是產品品質，例如 ISO，CMMI。
• 政府補助：既然政府錢太多沒地方花，大家來幫忙花也算是盡了點國民義務。
• 有牌：有了 XX 認證之後才可以標政府的案子，或是把牌當成『蛤蠣肉』來使用，拿來蓋住客戶的眼睛。

很可惜人們常常 Quality Without a Name 和 A Name Without Quality 傻傻分不清楚，Teddy 要提醒大家，不要被『認證』給騙了。很多認證都是錢換來的。

隨便講一個例子，Teddy 的母校在若干年前獲得了 ISO XXXX，號稱可以改善服務品質。屁啦（請原諒這次不消音還要放大），每次 Teddy 從行政大樓離開，都有一種急需吃素三天的感覺。因為心中的中指在洽公的過程中，已經不知緩緩舉起了多少回。

再談談 CMMI，利益 立意良好，但是 Teddy 斗膽想問一句，在台灣有那一個實施 CMMI 單位的程式設計師覺的 CMMI 真正改善了軟體開發？有那個程式設計師可以大聲喊出『我愛死了 CMMI 』。如果有，拜託介紹給 Teddy 認識一下。導入 CMMI 和評鑑 CMMI 的都是同一批人，這種導入焉能不過關，才真的有鬼。

ISO 和 CMMI 給玩爛了也不關  Teddy 的事，畢竟這已經是公開的秘密，絕不會動搖國本。但是，這一股『做表面功夫』的風氣好像有一點要蔓延到 Scrum 上面，這...也不關 Teddy 的事，但是吃飽閒閒沒事幹的 Teddy 還是要提醒一下幾個現象。

• Certified ScrumMaster 只要肯付錢去上課就可以拿到證書，所以，看到 Certified ScrumMaster 不要傻傻地以為這個人就真的懂 Scrum。要問對方有沒有真的帶過 Scrum 團隊，有多久的經驗，遇到什麼困難，如何解決。
• 最近有 XXX 公司要從國外找人來開 Certified ScrumMaster 課程，Teddy 強烈建議如果真的要花錢上，最好是去上 Bass Vodde 開設的課，畢竟 Bass Vodde 也寫了兩本 Scrum 的書，有真才實料。千萬不要 Scrum，PMP，傻傻分不清楚（這個梗最近用的有點氾濫...XD）。

Scrum 框架本身很簡單，Teddy 在這邊就不用再背誦一次了。Teddy 很怕 Scrum 變成另一個台灣版的 ISO 或是 CMMI，光是徒具形式而沒有實質。套句 Teddy 的指導教授曾經說過的話：『在台灣導入 CMMI 好像在學踢正步，軍容壯盛。至於能不能真的上戰場打仗，則是另外一回事。』


某些顧問公司為了賺錢如果連 Scrum 都可以搞得形式化，那 Teddy 只能說『福氣啦』。

***

書上看來的，要 『Being Agile』而不是『Doing Agile』。

*** 

友藏內心獨白：找顧問要『視其所以, 觀其所由, 察其所安』。 

台灣也有好吃拉麵

06/28 20:59~21:33

Teddy 自從2009年12月在京都吃了『寶屋』的拉麵（請參考『是的，日本的拉麵真的比較好吃』），回台灣之後一直擔心『以後再也吃不到這麼好吃的拉麵該怎麼辦！』。最近 Kay 幫忙在網路上 survey 了幾家頗有口碑的拉麵店，Teddy 上個禮拜和上上禮拜各去試了一家，在此跟鄉民們報告一下。

花月嵐 

Teddy 是去台北車站2F這一家用餐，裡面居然有禁止照相的規定，所以 Teddy 也就沒有幫拉麵拍照。如果京都『寶屋』拉麵算 100 分的話，花月嵐的拉麵 Teddy 給 80 分，算是還 OK。不過 Teddy 不會特別想再去吃。首先，拉麵裡面那半顆蛋就完全遜掉了，煮得太熟，失敗。湯頭算中等，麵還可以。你看，才隔了兩個禮拜，Teddy 就快說不出來這碗麵的特色了 。要說是有什麼讓 Teddy 記憶深深，應該就是『白開水』吧。沒錯，花月嵐 的白開水冰涼透心，在炎熱的夏日，吃碗熱熱拉麵在喝口冰涼白開水，真是棒透了。



樂麵屋

Teddy 是去永康街10巷7號這一家用餐，可照相，看實例先。

 Teddy 吃的

 Kay 吃的

服務生把麵端上來光是用看的就覺的賣相不錯，實際一吃，嗯，湯頭好，叉燒肉也很嫩，麵也不錯吃，得 90 分，這是 Teddy 到目前為止在台灣吃過最好吃的拉麵。不過樂麵屋的拉麵份量大概是寶屋的快一倍，吃完之後覺的有點撐，而寶屋的拉麵吃完之後則是有那種剛剛好又意猶未盡的感覺。要說是樂麵屋有什麼缺點，那就是沒有冰涼的白開水啦。樂麵屋有附類似麥茶的東西，不過一點都不冰，這一點從 Teddy 的角度來看算是一大敗筆。

結論：寶屋 > 樂麵屋 > 花月嵐  >> 佐野拉麵。

***

友藏內心獨白：你是去吃拉麵還是去喝冰開水？

元祖胡椒餅

06/27 15:57~17:18

Teddy 依稀記得很小的時候只要到萬華戲院看電影，都會在戲院旁的小巷子內買個胡椒餅邊看電影邊吃。那時候年紀太小，根本不記得電影的內容，印象中只記得胡椒餅很好吃。後來萬華戲院拆掉了，Teddy 也有 N + M 年沒再吃過萬華戲院旁的『元祖胡椒餅』。但是，這種『胡椒餅很好吃』的印象一直深值在 Teddy 的心中，每次在路上只要看到有人在賣胡椒餅，就會想去嘗一嘗，試圖找到幼時好吃的回味。很可惜，還不錯吃的胡椒餅倒也不是沒有，但是與印象中的 美味蟹堡 好吃胡椒餅相比總是少了點什麼。


前一陣子在電視上看到訪問元祖胡椒餅的節目，原本第一代的老師傅已經過世了（Teddy 小時候吃的應該是第一代老師傅親手做的胡椒餅），現在店面轉移到捷運龍山寺站附近。說真的，Teddy 完全不記得萬華戲院的位置了，也不知道現在的元祖胡椒餅與當初萬華戲院距離有多遠。上個禮拜天 Teddy 搭捷運去『視察』南港世貿展覽館，回程到龍山寺捷運站剛好下午五點多，想說順便去買個胡椒餅當晚餐好了。以下簡介一下如何找到元祖胡椒餅的攤位，地址在『和平西路三段109巷』，到了捷運龍山寺站後可由一號或三號出口出來（三號出口比較近）。

 就在這個小巷子內

出捷運站之後如果搞不清楚方向，往四周看一下會看到如下圖的『御花園足體養生會館』，往這個方向走就對了。

往『御花園足體養生會館』這個方向走就對了

在這個超小巷子內除了元祖胡椒餅之外還有另外一家在賣魷魚羹與大腸麵線的，有興趣可以參考一下。

兩種選擇

往巷內一看，都是在排隊買胡椒餅的，Teddy 一問之下，要等 35 分鐘下一梯次出爐。Teddy 買了四個，付錢拿了號碼牌，然後先到附近的龍山寺逛一下。

好多人排隊啊

話說 Teddy 小時候也經常到龍山寺，不過 Teddy 去的目的並不是拜拜，而是去看魚和烏龜。龍山寺的前庭有兩個放生池，Teddy  記得以前裡面有很多烏龜。現在去看，發現只剩下很大尾的鯉魚（應該是鯉魚吧？！），烏龜則不見蹤影。此時 Teddy 突然詩興大發：

兒時今日此池中，烏龜鯉魚相應紅
烏龜不知何處去，鯉魚依舊鬧哄哄

匆匆繞了龍山寺一圈，留了點時間到旁邊的『億萬里』買了兩袋衛生紙。時間也差不多了，回去等胡椒餅。

回去之後又等了好幾分鐘，終於拿到了期待已久的元祖胡椒餅。回家之後趕快拍幾張照片。

營業時間 9:30~19:00

露餡了

 

 Teddy 順便偷渡了一碗魷魚羹

Teddy 一口氣連吃了兩個，加上魷魚羹快撐死了。以下是幾點結論：

• 元祖胡椒餅是很好吃，不過怎麼還是覺得比不上心中兒時所吃過的？
• 據電視上報導，元祖胡椒餅早上和下午是兩批不同的人做出來的，也許下次要試試上午的。
• Teddy 拿到胡椒餅到回家這中間大概過了六分鐘左右，也許一拿到當場吃起來味道會不太一樣。
• 魷魚羹也很好吃，不過稍微鹹了一點。

古人有云，『得意不宜再往』。Teddy 小時候第一次去阿里山覺的這裡真是人間仙境，若干年前舊地重遊，只有不斷的靠北...邊走...怎麼到處都是『檳榔樹』啊。也許，這夢中元祖胡椒餅的味道已經隨著地球暖化一去不復返了。

***

路人甲：這整篇和軟工有何關係。

Teddy：拜託，哪有每天都在搞笑談軟工的，偶爾也讓 Teddy 過點地球人的生活吧。

***

友藏內心獨白：國家應該成立美食基因庫，這比花大錢去儲存幹細胞有用多了吧。

Design Patterns 分成三大類

06/24 22:47~23:55

今天 Teddy 有點累，談點簡單一點的主題：『Design Patterns 的分類』。

鄉民甲：我知道，就是 Creational, Structural, 和 Behavioral 這三類的啦。

全錯。如果是這三類，鄉民自己看 GoF 的書就好了，用不著 Teddy 出馬。Teddy 要介紹的這三類，是出自於 Wolfgang Pree 所撰寫的 Design Patterns for Object-Oriented Software Development 這本書中第 98 頁（沒看過吧，嘿嘿嘿）。

• Patterns relying on abstract coupling
• Patterns based on recursive structures
• Other patterns

GoF 的 Design Patterns 這本書中大多數 patterns 都是屬於第一類的，例如 State， Factory Method， Observer， Bridge， Builder， Command， Visitor， Interpreter， Mediator， Adapter， Prototype， Proxy，Strategy。手邊有書的人翻開看一下，或是看下圖，Observer pattern 中的 Subject 和 Observer 是有 coupling，也就是彼此相依。但是，軟體設計最基本的兩個法則其一就是要降低 coupling（另一個是要提高 cohesion），但是 coupling 又不可能降低到零，否則所有物件彼此都沒任何關係，玩不下去了。為了求得平衡點，這個關係就要想辦法搞成『有點黏，又不會太黏』，於是乎誕生了
『abstract coupling』。要 coupling，OK，但是只能有『抽象關係（精神外遇？）』，不能有 肉體耦合 實做耦合（implementation coupling）。

有準時收看 Teddy 部落格的鄉民們，有沒有發現，這就是『program to an interface,  not an implementation』的例子啦。

圖片來源：http://upload.wikimedia.org/wikipedia/commons/8/8d/Observer.svg

第二類，recursive structures 有 Composite， Chain of Responsibility， Decorator。應該不用再多做解釋了，這一類的 patterns 就是有遞迴結構。

圖片來源：http://upload.wikimedia.org/wikipedia/commons/5/5a/Composite_UML_class_diagram_%28fixed%29.svg

第三類，其他。ㄟ，通常分類到最後分不下去了都會跑出這一類。屬於這一類的有 Abstract Factory， Flyweight， Singleton， Template Method。

至於知道這些分類有什麼用？至少改天鄉民們想自創武功的時候，可以從『abstract coupling』和『recursive structures』作為出發點來思考，這總比 Creational, Structural, 和 Behavioral 分類要具體一點吧。

***

友藏內心獨白：還有另外一個用途就是可以拿來寫部落格啊。又混過一篇...safe。

軟體是長出來的

06/23 21:40～23:25

Teddy 在『老闆，軟體不是這樣開發滴』提到台灣的硬體代工製造太強，所以很自然的就會以硬體代工的模式來看待軟體開發。關於軟體開發本質的爭論相信鄉民們早已經聽到耳朵都長（消音）了，不管軟體開發到底是屬於『工程』，『藝術』，『技藝』還是其他亂七八糟的大雜燴，今天 Teddy 要談的觀念是『軟體是長出來的，不是組裝起來的』。

這幾天 Teddy 在讀 Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum 這本書（PS：好長的書名啊，一口氣還念不完！）看到書中談論的一個觀點：

Growing Software vs Building Software

Building software 是大家普遍比較熟知的軟體開發模式，Teddy 把它稱之為『組裝軟體』。意思是說，軟體可以和硬體生產一樣，『規格確定之後』尋找不同零件供應商，然後把這些零件全部兜起來組裝好，就變成產品了。這種製造模式，會造成目前常常在媒體上聽到的『iPad 概念股』或是『iPhone 概念股』。因為這些產品賣得好，所以台灣負責生產週邊零件的廠商也跟著『人家吃肉我喝湯』而賺了一筆。

代工代上癮的大，小老闆們，毛利 5 趴，3 趴 賺到都快要趴到地板上了，聽說軟體的『毛利』很高喔，很自然的想到把硬體代工這一套擴展到軟體代工，或是藉由軟體提高硬體的附加價值。但是，軟體規格偏偏比孫悟空的七十二變還要多變，又不像硬體有那麼成熟的協力廠商供應鍊，真的傻傻地想要『組裝軟體』，就算是請了 1000 個人來組成『軟體生產線』，到時候『生產』出來的東西組的起來還真是有鬼。

其實軟體開發就像『種菜』，『種花』，『種水果』一樣，軟體需要靠開發人員每日細心呵護，才能慢慢『成長茁壯（growing）』。翻土，插秧，施肥，灌溉，修剪，除草，抓蟲，防風，防曬，該做的功課不能少，才能種出好作物出來。今年如果颱風特別多，就要小心風害，如果有強烈寒流，就要小心作物凍傷。太陽太大要幫水果穿衣服，有時候缺水還要休耕改種耐旱作物。軟體開發就跟種田是一樣滴，無法靠『組裝』而產生產品。

看看前輩們如何說：

• Andy Hunt 與 Dave Thomas 說：『Rather than construction, programming is more like gardening』；『All programming is maintenance programming』。
• Christopher Alexander 認為設計是一種 『differentiating process』而非『synthesis, a process of putting together things, a process of combination』。所以，建造好的建築物是要靠『participation』（客戶的參與）以及『piecemeal growth』（逐步成長）。
• Steve Freeman 與 Nat Pryce 寫了一本『Growing Object-Oriented Software, Guided by Tests』的書。注意，是 growing 不是 building 喔。
• Agile methods 採用 iterative and incremental development。
• Martin Fowler 說 『Evolutionary Design 和 Refactoring』。

以上都是強調軟體跟人一樣，是從小 baby 長成大人，應該沒辦法『蓋』或『組裝』一個真人出來吧...機器人倒是有可能啦。

***

Teddy 扯了這麼一堆，鄉民們可能早就知道了這個概念了。很遺憾的，你老闆應該是屬於『侏儸紀 waterfall 時代』的靈長類，每天還在想著如何靠組裝模式賺大錢。怎麼辦？Teddy 也沒辦法啊，不然幹麼沒事寫部落格來抒發情緒...XD。

***

友藏內心獨白：不寫部落格，就只能回去多喊幾聲『皇上聖明』...實在是喊不出口。

Program to an interface

06/22 22:00～23:20

看過 Design Patterns 這本書的人，一定會記得第18頁的這一句至理名言：

Program to an interface, not an implementation.

讓我們看一下書中這一句的前後文：

There are two benefits to manipulating objects solely in terms of the interface defined by abstract classes:

1. Clients remain unaware of the specific types of objects they use, as long as the objects adhere to the interface that clients expect.
2. Clients remain unaware of the classes that implement these objects. Clients only know about the abstract class(es) defining the interface.

This so greatly reduces implementation dependencies between subsystems that it leads to the following principle of reusable object-oriented design:

Program to an interface, not an implementation.

Don't declare variables to be instances of particular concrete classes. Instead, commit only to an interface defined by an abstract class.

先用白話文解釋一下這句話，假設鄉民們要幫公司在資訊展上面找 show girls 站台，物件導向技術學得好的人就知道要符合『program to an interface』的精神來開出條件給公關公司找人。

有酷似『豆花妹』甜美的笑容，媲美『遙遙』殺很大的身材，外加『林志玲』的娃娃音。

這樣子應該很容易可以找到一票符合條件的 show girls。反之，如果是『program to an implementation』，就會變成：

 我要『豆花妹』，『遙遙』，外加『林志玲』。

都已經『指名購買』了，再怎麼找全台灣也就是這三個人。萬一當天有人臨時生病，可是連個替代人選都沒有（implementation dependencies）。

所以，program to an interface 的好處就很明顯了：

• 不管黑貓，白貓，只要能抓老鼠的（符合 interface）就是好貓。也就是說，可選擇性變多了，不會被綁死在某一個人或是品牌上面。
• 有一天發現世界上有一種比黑貓和白貓更厲害的『熊貓』，只要符合介面直接換掉程式都不用改。

結論：Thinking about what you can do rather than who you are.

***

友藏內心獨白：最難的就是定義 interfaces 啦。

對症下藥

06/20 20:59~22:20

Teddy 曾經在第四台看過一部電影，劇情有一段提到清朝 咸豐 同治皇帝很喜歡『尋花問柳』，有一次同治皇帝生病，被太醫診斷出是『花柳病』。這個病照理講應該不算是什麼不治之症，但是皇太后為了怕同治皇帝得花柳病的事情洩漏出去有損『朝廷顏面』，因此吩咐太醫對外就說皇上得了『天花』，按照醫治天花的方法來醫治皇上。結果如何看官們可想而知，不久後同治皇帝就一命嗚呼去見老祖宗了。

『不願面對的真相』自古就有，這種故意將『花柳』，『天花』，傻傻分不清楚的事可是多的很。萬一有人『白目』不小心戳破『國王新衣』的秘密，可是會死無葬身之地。識相一點還是乖乖的按照『天花』來醫治就好，反正死得是皇上，又不是太醫，更不是皇太后。不過，當太醫的也要小心，萬一皇太后耍賤招，太醫可是會因為醫治皇上不力而被『賜死』。

***

上述橋段在軟體開發裡面也是履見不鮮，軟體專案常見的病症與藥方有：

• 需求經常變動-->請客戶畫押。
• 專案時間到了系統還沒完成-->時程一再往後延直到功能做完或專案葛屁。
• 專案時間到了系統又還沒完成-->直接丟給客戶先結案收錢再說。
• 時程延誤-->開會。
• 時程嚴重延誤-->開更多的會。
• 時程又延誤-->加班。 
• 時程又嚴重延誤-->加更多的班。 
• 程式品質不良-->回家多喝開水就好了。 
• 程式品質很不良-->回家多喝開水 + 蓋棉被。
• 程式品質嚴重不良-->我的眼睛，只看得到我想看的東西，哪裡有 bugs？
• 團隊士氣低落-->訂定不合理的時程表。
• 團隊士氣嚴重低落-->訂定超級機車的時程表。
• 專案一塌糊塗-->報告老闆，一切都按造計畫中進行（我們原本就計畫要把案子搞的一團亂）。

當公司大到一定的程度，老闆通常沒有那個美國時間去關注太多的『細節』，所以這時候就有很大的『欺上瞞下』空間。清朝乾隆皇帝派兵去攻打緬甸，明明是『大敗』，前線將軍卻可以回報『大捷』，而乾隆皇帝倒也樂得開心。很荒謬，Teddy 原本也這麼認為，但是現在越來越能體會箇中奧妙之處。

會升官發財的人，心目中的第一優先，永遠是『把事情做對』，而非『做對事情』，兩者有何差別？

• 把事情做對：不管是偷，搶，矇，拐，騙，總之要做好可以討好『聖上』的事。打敗仗，要說成大捷；殺敵 100，要謊報殺敵 1 萬。龍心大悅之下，步步高升指日可待。
• 做對事情：效法『劉羅鍋』每日上朝奏三本，針貶時政，順便煩死皇上。

天縱英明的聖上，會喜歡哪一種人？恐怕是天天喊著『皇上聖明』的前者吧。

軟體專案會發生問題，也許有很多因素並不是軟體本身『有病』所引起的問題。軟體的病，只要願意對症下藥，大體都還有的救，只是『醫藥費多寡』與『痊癒時間長短』的問題。就怕是硬把『花柳』當『天花』，那就只能拖一天，算一天了。

***

友藏內心獨白：誰說民國沒有太監？

Teddy 的初衷

06/18 21:55~23:00

Teddy 在 2008 年秋天畢業前夕，在 104 上登錄了履歷，收到四家公司的面試通知。這個故事就發生在 Teddy 到其中某家本土『純軟體公司』面試的時候。該公司主要業務為開發自有品牌的軟體（搭配硬體），在國內還做的不錯，頗有知名度。面試 Teddy 的人是該公司技術總監還有董事長。在面試的過程中，技術總監突然說：『Teddy 你的自傳寫得太好了，我一定要把這幾句念一下』。

有人曾問我為何想念博士班，我總是回答：我希望改變人們在台灣開發軟體的方法。因為了解到許多台灣的公司還是用非常傳統的方式在開發軟體，對於教科書上所談的軟體工程方法，以及許多在國外早已被證實非常有用的軟體開發最佳實務作法 (best practices)，台灣的老闆、專案經理、或是軟體工程師總是能找出各種理由與藉口拒絕採用。我認為軟體開發應該是一件很愉快且有趣的工作與創作，因此在我求學與研究的這幾年，我試著將理論與實務加以結合。雖然我知道憑著一己之力是不可能改變台灣所有人們開發軟體的方法，但我相信我可以帶領一個軟體開發團隊或組織，有紀律且有效地開發高品質的軟體。

沒想到真的有人在看面試者的自傳...可是，搞到『當場朗讀』的地步，這位技術總監也算是古今天下第一人吧。當然 Teddy 當下有點小小的感動。什麼，你問面試結果如何，這...請參考古早某篇部落格文章。

***

Teddy 不是要炫耀自傳寫作，而是回想起 Teddy 唸博速班的這 N + 1 年，人也老了，體力也衰退了，胃潰瘍也得了，在即將變成『菜尾』之前，回想起原始的『初衷』（PS：幾個月前看了『孫大偉的菜尾與初衷』這本書，寫得不錯值得一看）到底是什麼？是否還存在？

10 幾年前 Teddy 剛出社會，也做了不少專案，有的成功，但是失敗的好像更多。明明每天做的累的跟狗一樣，有時候晚上還要煮稀飯，綠豆湯當宵夜跟同事一起分享，但是需求好像永遠都沒有『定下來』的一天，要把程式『寫完』好像是『煮沸海水』一樣的困難。

啊，是 Teddy 軟工的書讀得不夠多吧。Teddy 五專是念電子科，因為軟體太強以至於硬體爛得一塌糊塗...XD。但是當時在學校所學的軟體課程，也只有 Pascal, Fortran, C 這些程式設計課程（不要提組合語言和 8051...我恨你們...XD），以及系統程式，作業系統，演算法而已。所以，只好在工作中不斷的看書。但是畢竟是沒有受過『正統訓練』，經過幾年後，雖然累積了一些工作經驗，但是又經常會懷疑：『軟體真的是這樣開發的嗎』？Use Cases 拼命寫，UML diagrams 卯起來畫，好像挺沈重的。Developers 明明只有小貓五，六隻，真的要搞到 RUP （Rational Unified Process）？可是書上都這樣寫啊，人家國外大廠都在用了，一定沒錯的啦。

有經驗，自己也看了許多書，不過還是缺少『獨立判斷的能力』。後來因緣際會之下，不小心唸了博速班，在指導教授強力掃把助陣之下，勉強讓 Teddy 在 N + 1 年後爬出校門 。Teddy 要再強調，『博速』只不過是多唸了幾年書而已，真的沒什麼了不起的。Teddy 的指導教授曾經告訴 Teddy，要有工專的『黑手』精神，Teddy 一直奉行不渝。

***

Teddy 沒事就在部落格上跟瘋狗一樣亂罵台灣的軟體開發現況，光是罵當然很簡單，但是也不能完全像 Teddy 的學弟 Lililala2 所說的：

不過當你處於一個快散掉的團隊(A.K.A 快沉的船)時,只需要確定兩件事:

1.確定自己有脫離火箭
2.確定點燃了脫離火箭後有地方可以著陸

其他什麼搶救團隊(A.K.A 沉船)的事都是徒勞,多幹幾次之後就會想去賣雞排(或保險)  

雖然 Teddy 有時候真想學日本電視節目『自給自足過生活』一樣躲起來（誰可以賞 Teddy 一枚脫離火箭加一塊農地啊），但是回想起當年還是年輕小伙子的『初衷』：

我希望改變人們在台灣開發軟體的方法

當年不知道這個方法應該是什麼，隨著年紀增長，輪廓漸漸清晰。

Scrum + Lean + XP

Teddy 的指導教授常常告訴修軟工課程的學生，要『傻的願意相信書本裡所說的』，不要在尚未嘗試之前就先否定。嘿，Teddy 也曾經被那個號稱『軟工界超級整人遊戲之 PSP (Personal Software Process)』搞得神經快錯亂，也是挺過來了。

覺的當前的方式不好，想辦法從小處著手，慢慢改變，總是會看到成果的。

***

友藏內心獨白：眼睛快瞎了，這種『勵志小品』挺噁爛的，不符合搞笑宗旨。

木工，軟工，傻傻分不清楚

06/16 22:45~23:55

年紀大了，好像要講什麼故事都是發生在 10 幾年前。話說 Teddy 第一份工作，在開發『連鎖洗衣店門市進銷存系統』之前，Teddy 還開發過『連鎖 XX 門市進銷存系統』。這個 XX 代理美國知名『環保』品牌的『香精』，『洗髮精』，『口紅』，『茶』等等產品（奇怪，Teddy 怎麼淨做些湯湯水水的系統？）。故事發生在第  N + 1 次的會議中：

XX 總經理：Teddy 啊，我們請木工做一個衣櫥，木工會幫我們測量衣櫥大小。如果木工不小心把木版的尺寸裁切錯誤，是要自己吸收費用的，不可能讓業主來出這一筆錢。你們做系統經驗不足，都沒有給我們『專業』的建議，導致需求改來改去的。現在又要我們全部負擔需求修改的費用，這樣是不是不合理？你們也應該要吸收一部分的修改費用啊。

Teddy 當年只知道傻傻的寫程式，內心跟一張『尚未使用過的舒潔衛生紙』一樣純白，屬於標準的『年幼無知』加上嚴重『涉世未深』，所以完全不知如何反駁對方。

現在的 Teddy 會說：XX 總經理，你嘛幫幫忙，怎麼會『木工，軟工，傻傻分不清楚』。

Teddy 倒是要請問 XX 總經理：

• 妳家衣櫃四周的牆壁位置，地板與天花板的高度，會隨時變來變去的嗎？
• 衣櫃門板材質選好之後，木工也裁切好了，妳還可以改變材質嗎？
• 木工把衣櫃都做好之後，妳可以因為突然發現『衣服太多放不下』的這個理由，請對方拆掉重作嗎？
• 衣櫃作到一半妳可以請木工改成狗屋嗎？

XX 總經理，Teddy 知道妳是好野人，錢砸下去沒什麼不可以。不過，相信木工不可能免費幫妳做這些改變（除非他是妳老公...XD）。

可是，做軟體的卻應該免費隨便修改到客戶爽為止。軟體真是世界上最神奇的東西啊，既然軟體是『軟』的，老娘愛怎麼改，就怎麼改，但是休想從老娘的口袋多掏出一毛錢來。總之都是軟體廠商『經驗不足』的問題啦，老娘讓你們學經驗沒跟你們收錢就已經很不錯了。

***

『軟體需求』會一直改變，這一點應該算是『常識』了吧？！不過人類總是有『視而不見』的超能力，就好比某段相聲裡的台詞：『我的眼睛裡只看得到我想看的東西』，所以還是有很多人很自然地看不到『軟體需求會不斷改變』這個事實，而認為只要很有經驗就可以『第一次就做對』，因此客戶只要『不花腦筋』地付錢了事便可。

老闆，別再『木工，軟工，傻傻分不清楚了』：

• 首先，您要做的系統，雖然 95% 的內容可能在世界上某個角落曾經有人做過，但是除非你能剛好找到這個『有經驗的人（所謂 domain known-how 很強的人） 』來做需求分析，否則對於你目前找來的『包商』而言，這可是全新的體驗。
• 就算是你找到這個傳說中『domain known-how 很強的人 』，也不可能開發出『第一次就做對的需求書』，這個東西應該還沒有被發明出來。
• 幾乎大部分的軟體開發專案都可以被歸類為『新產品開發』（書上寫的，那一本書要再查一下），所以風險一定很高。能夠找到愈多『有經驗的人』當然可以降低風險，但是不可能降低到零，否則開發成本可能會變得無限高。  

結論就是：老闆，面對現實吧。你只願意付那麼一點點錢，能夠作到『第一次就堪用』就已經算是你祖上積德，上輩子燒好香了。除了靠祖先保佑之外，你還可以：

• 找到有良心的開發團隊（這...哪裡有啊！）。
• 自己要多做功課，畢竟軟體最後是自己要用的，現在偷懶以後更痛苦（如果是自己家裡要裝潢，不可能自己不做功課吧... IKEA 都不知道跑了幾趟，咖啡喝到胃潰瘍發作）。
• 與對方維持良性的互動。
• 要求對方採用 Scrum。

***

友藏內心獨白：一步到位聽起來很爽，但好系統跟好酒一樣，是需要時間醞釀滴。

加班，加班，我愛你

06/16 22:09~23:25

為了讓非軟體產業的鄉民們對於台灣軟體業有所了解，請容許 Teddy 簡述一下許多軟體專案進行的方式。

專案成員：

• 夢想與天一樣高或瘋狂想賺錢的老闆，或兩者皆是。
• 標準配備為十二英吋口徑加農嘴砲的業務（永遠搞不懂，也不需要懂他在賣什麼東西）。
• 只會畫甘特圖與 WBS 的專案經理（可能擁有 PMP 證照）。
• 該死的工程師（實際上應該要做事的人）。

專案進行方式：

• 老闆或是業務靠著『冥想』，『政商關係』，『人脈』，以及『眼睛被蛤蠣蓋住的客戶』加持之下，接到專案。至於專案內容是什麼，拜託，這不重要。
• 在老闆一聲令下，決定了專案的時程。訂定時程其實很簡單，依據 專案的大小 收錢的多寡，只要遵循 一，三，六，九，十二 這個原則就 OK 了。在這幾個數字中隨便挑幾個用來，一，三 和 六 可能是最常使用的，不管專案要做什麼，反正老闆都認為三個月就應該可以完成。
• 專案經理依照聖上（老闆）的聖旨，以緊迫釘人的方式，督促工程師趕上進度。
• 工程師在還沒搞清楚要做什麼之前，三個月的期限已經到了。

看到這邊鄉民們可能會以一個疑問：『啊，三個月到了案子沒做完，那誰負責』。

老闆：專案經理，案子進行的如何？

專案經理：進行的很順利，工程師每天都加班到很晚，功能都做的差不多了，只剩下測試還有『幾個』 小 bugs 要修。

老闆：測試就不用了，讓客戶自己測就好了。這樣還需要多久？

專案經理：大概.... 三個月吧！

老闆：給你一個月。

***

鄉民乙：那專案到底多久做完？

Teddy：這不是重點，結案才是重點。

鄉民乙：沒做完也可以結案？

Teddy：當然。

鄉民乙：那要如何結案？

Teddy：這是秘密，講出來會動搖國本。

鄉民乙：（消音）。

***

Teddy 今天想提的，其實是『加班』這件事。每個工程師都知道一件事，就是專案的『時程 (schedule)』就像台鐵的火車時刻表一樣，僅供參考之用。有的專案更誇張，居然膽敢訂出『反攻大陸』時程表。

老闆：給你一個班的兵力，兩年內把大陸給我打下來。

老闆要做夢鄉民們也犯不著吵醒他，但是又要保護自己在夢醒時分不會遭遇不測。因此，雙方發展出一套遊戲規則：『加班』。
 
老闆 ：我的員工好認真，每天加班到 12 點，假日也來上班，統一大業指日可待。

員工：我每天都加班，假日也來加班，東西做不出來也不能怪我。啊不然你是要怎樣。

有了『加班』這個方便法門，老闆不用去花腦筋去提昇管理績效，員工也不用花腦筋去改善做事方法。反正，『這是主流』啊，順著潮流走就對了。（PS：花腦筋是很違反人性的一件事，這也是為什麼周星星的電影那麼多人看，還看了不只一遍。）

***

Agile methods 提倡『每週工作 40 小時』，就像 TPS (Toyota Production System) 提倡『零庫存』是一樣的，目的就是要『把問題暴露出來』。每天加班事情還是做不完，大家已經習以為常，不用花腦筋去想，多方便。那，如果不加班要把事情做完呢，這就難了：

• 我們專案時程根本亂訂，業務搶到一堆案子，做一個賠兩個。
• 我們的 bugs 太多了，所以事情做不完。要準時下班，就要想辦法減少 bugs。
• 程式亂寫，後續根本無法維護，也找不到願意維護的人。
• 工程師看不到未來，無法成長，人員流動太快。
• 沒有自動化測試，改一行程式錯 100 個地方也沒人發現。

這個 list 要再加上個 100 條也是輕而易舉的事，這些問題平常都被掃到地毯下，沒人願意去管。反正有『加班』這個萬用武器，何必花時間與力氣去做些吃力不討好的事。

要拯救一個快散掉的軟體開發團隊，首先想想，要如何可以讓團隊成員不再加班也可以達成進度。不管這個團隊有多少問題，這都是一個不錯的出發點。

***

友藏內心獨白：Teddy 年輕的時候也加了不少班，案子還是做的一團亂。

地表上居然有這種神奇的東西

06/15 22:41~23:04

Teddy 剛剛閒著無聊在中時電子報上看到一則 廣告 『科技新聞』，標題是『資策會推軟體專案管理最佳實務』。這麼好的課程，人客啊，瞧一瞧裡面有什麼。以下節錄自該篇報導：


軟體開發最佳實務必須在不斷地實戰演練過程中產生。不論是PMP認證或是CMMI、ISO等軟體開發標準，都只能提供你明確的標準作業程序，但卻未能提供你 第一次就做對的最佳實務方法。課程提供學員完整的軟體專案問題失誤樹，找出造成軟體開發重工與變更問題的前因與後果，並提供在計劃階段「第一次就做對」 的規劃技巧與執行階段「第一次就做對」的控制技巧。

***

哇靠...過來一點，Teddy 真是太孤陋寡聞了，這世界上居然有這麼強的東西叫做『第一次就做對的最佳實務方法』，那 Teddy 每天做的要死不活的還搞個（消音） 啊。Teddy 就是沒有去上這門課啦，所以從來沒有過『第一次就做對』的經驗，真是遜到爆了。這 廣告內容 課程說明真是太美了，令人忍不住把重點再看一次：

• 提供在計劃階段「第一次就做對」 的規劃技巧。
• 與執行階段「第一次就做對」的控制技巧。

鄉民們，還等什麼，趕快報名先。很可惜 Teddy 是一位『口袋不深』的軟體從業人員，沒錢上課。有報到名的鄉民們，上完課之後請好心的來教教 Teddy 要怎麼才能『第一次就做對』。

ㄟ，對了，電視新聞不是有報導，買東西拿到傳單上面對於產品的說明，如果和真正買到的產品內容不符，是可以要求退費的。這...如果商品是教育訓練，也可以一體適用嗎？

***

友藏內心獨白：教的人沒問題，達不到目標是執行的人（就是咱們這一票該死的工程師）能力不足。

這不是整人遊戲之 time log 紀錄方式

6/14 22:35~22:57
6/14 23:07~ 6/15 00:20

Teddy 在 2005 年春天修了一門 PSP -- Personal Software Process 的研究所課程（個人軟體程序，聽起來就是無聊到爆的一門課。如果是 Sony 的 PSP 那該多好），沒記錯的話 PSP 這玩意兒（請捲舌）是 Watts S. Humphery 教授加博士 所發明的，目的就是要利用『工程』的方法，來提昇軟體開發的品質。基本精神就是，『任何東西只要無法測量，就無法改善』。因此，為了要改善軟體開發的品質，出發點就要從『單兵作戰守則』開始，要求單兵（programmers）卯起來紀錄（測量）在開發過程中一些你從來也沒有想到需要去紀錄的資料，包含：

• Time log: 詳細紀錄不同開發階段，例如 Plan，High-Level Design, High-Level Design Review, Design，Design Review, Compile, Code，Test, Project Manage 各花費多少『分鐘』。
• Size: BASE PROGRAM LOC (基本的程式行數，就是說開發一個新的功能之前程式有幾行), LOC DELETED (此次開發刪除了幾行), LOC MODIFIED (此次開發修改了幾行)。
• Defect: 紀錄 defect 的 date (哪一天被發現的), number (第幾個 defect), type (哪一種類型的，邏輯錯誤，打字錯誤，資料結構錯誤等等), inject (在哪一個階段所產生的，例如計畫階段，設計階段，寫程式階段等等), remove (在哪一個階段被修正，例如 Design Review 階段或是測試階段), fix time (花了多少時間來修正)。

剛剛去『批衣服』現在繼續。

除了這些以外，還要寫一堆資料，一個學期搞下來，雖然只寫了 10 支（1A~10A） 總行數加起來可能不到 2000 行的小程式，整個人卻是累到走路必須要靠北邊走，有一種被掏空的感覺。今天要談的主題是 time log，因此看一下 Teddy 當初修課作業所紀錄的 time log 範例：

修完課之後，只有一個感想：『這是整人遊戲嗎？』Teddy 這一輩子應該不可能去寫戰鬥機，核電廠，或是太空梭所使用的程式，真實世界中的普羅大眾誰跟你紀錄這些。鄉民們信不信把這一套拿給你們老闆瞧一瞧，如果沒有被痛貶一頓的話，請注意你一下老闆的精神狀態是否正常。

但是，Humphery 教授加博士 也不是省油的燈，PSP 或是進階版的 TSP (Team Software Process) 或是宇宙無敵世界無雙的 CMMI (Teddy 知道，CMMI 不是 process...不要太挑剔) 裡面提到的許多『觀念』（再次強調，觀念）出發點都十分正確，但是『落實』的方法卻『沒人性』。經過這麼多年，Teddy 已經了解到，反是『違反人性』的制度或是作法，最終大多以失敗收場（上有政策，下有對策。生命會自己找到出路滴）。紀錄 Time log 的想法，就像是減肥的人每天紀錄吃掉多少『卡路里』，或是想存錢的人每天紀錄『花了多少錢』是一樣的。立意良好，做到的沒幾個。但是一旦能夠作到，的確有其效果。因此，後來 Teddy 就自創（ㄟ，任何人都可以想到啦）一套簡化的紀錄 time log 格式，在唸書的這幾年當中，持續紀錄。請參考 Teddy 某幾天的 time log：

2006/11/21
1.    研究 Eclipse editor
    * 研究 syntax highlighting
    (09:30~12:10, 160 mins)
2.    研究 Eclipse editor
    * 研究 syntax highlighting
    (12:40~15:10, 150 mins)
3.    MAUT meeting
    (15:10~15:40, 30 mins)
4.    回答 鄭老師  中央演講投影片 的一些問題
    (15:40~16:20, 40 mins)
5.    MAUT meeting
    (16:20~16:40, 20 mins)
6.    研究 Eclipse editor 
    * 研究 syntax highlighting (完成雛型)
    (16:40~18:00, 80 mins)

2006/11/22
1.    研究 Eclipse editor
    * 研究 outline view
    (10:30~13:20, 170 mins)
2.    研究 Eclipse editor
    * 研究 outline view (完成雛型)
    (13:50~17:50, 240 mins)

2006/11/23
1.    研究 Eclipse editor
    * 將 nodes 改成支援 visitor pattern (未完)
    (10:30~13:10, 160 mins)
2.    和謝老師去吃飯
    (13:30~16:40, 190 mins)
3.    研究 Eclipse editor
    * 將 nodes 改成支援 visitor pattern (大致OK)
    (16:50~19:10, 140 mins)

2006/11/27
1.    Study Group
    (13:10~13:30, 20 mins)
2.    研究 Eclipse editor
    * 測試 visitor
    * 完成在 outline 顯示每天總時數的功能 (尚未處裡四捨五入的問題)
    (13:40~15:30, 110 mins)
3.    研究 Eclipse editor
    * 修改產生 DLTree 的方法
    * 產生檢查 delta 的 marker (大致 ok)
    (15:30~19:50, 260 mins)

2006/11/28
1.    寫 Internet Computing review 結果
    (09:50~11:20, 90 mins)
2.    研究 Eclipse editor
    * 產生檢查 delta 的 marker 的 resolution (未完, 無法顯示)
    * 修改當讀取空白文件時, 文件 parser 程式無法結束 (無限迴圈) 的問題
    (12:20~14:10, 110 mins)
3.    和鄭老師討論 Internet Computing review
    (14:20~14:50, 30 mins)
4.    MAUT meeting
    (15:10~16:10, 60 mins)
5.    研究 Eclipse editor
    * 修改 (12:20~14:10, 20 mins) 若是在 end time 之後少一個 , (逗號) 程式的 bug
    (17:00~17:20, 20 mins)
6.    研究 Eclipse editor
    * 撰寫檢查日期是否重複的 visitor
    (17:20~17:40, 20 mins)
7.    Reading, Professional Java Interfaces with SWT/JFACE
    * chapter 8: Text Controls
    (17:40~18:10, 30 mins)
8.    Reading, Professional Java Interfaces with SWT/JFACE
    * chapter 20: Creating a Text Editor with JFace (未完)
    (18:10~18:40, 30 mins)
9.    研究 Eclipse editor
    * marker resolution (可在 problem view 按右鍵選 quick fix 來啟動)
    (23:00~24:00, 60 mins)

就這樣，格式很簡單，基本上實際紀錄都最小是以 5 分鐘（為了偷懶，Teddy 實際上通常最小是 10 分鐘為一個單位）來紀錄，只紀錄『有意義』的事情。太瑣碎與沒有意義的時間片段就忽略，例如，尿尿花了三分鐘，泡咖啡花了七分鐘這種就可以不用紀錄。

用紀錄流水帳的方式來紀錄 time log 的好處是『為了紀錄所額外花費的成本很低』。記得物理領域有一個叫做『測不準原理』的嗎，為了測量，觀測者其實已經改變了被觀測對象的行為。所以，越是輕量級的紀錄方式，看起來好像『不太精確』，但是卻是實際可行又具備參考意義的方法。

***

看到這邊，還沒閃人的鄉民們，可能會以為只有 Teddy 吃飽沒事幹才寫 time log。錯，Teddy 所屬的『X北科技大學 資工系 軟體系統實驗室 』的所有博，碩士生，都在寫 time log，而且連續實施這個作法至少應該超過 6 年以上（Teddy 畢業之後不知道他們還有沒有繼續寫下去）。有什麼好處？主要的好處是協助時間的分配。例如，參考學長，學姊的 time log，可以知道修一門課，像是 OOP，平均需要花多少個小時。當有新生修課投入時間太少，老師馬上就可以看出來並提醒他要投入足夠的時間。如果投入時間太多也是問題，可能是其他課投入時間太少，或是遇到問題無法解決。這麼多年 run 下來，真的幫助了不少學生。

對於做研究也有幫助。例如，經過統計，出一篇好的  journal paper 從頭到尾大概需要 500 小時，寫一本碩士論文可能需要 200~250 小時。如果有研究生要求畢業，指導教授只要稍微看一下研究生投入的時間和產出物，就有一個比較客觀的基礎可以來決定能不能讓他畢業，研究生也不會不服氣覺的被教授ㄠ。Teddy 也利用 time log 來預估寫一份 proposal 需要多少時間（大概要 40 ~ 80 小時）。

最後要注意幾點，(1) 紀錄 time log 是『良心事業』，灌水是沒有意義的。(2) 所紀錄的時間是『實際工作時間』，例如 Teddy 紀錄寫一份  proposal 需要 40 小時，這是『實實在在』的 40 的小時，而不是說一個工作天算 8 小時，做了五天因此得出 40 小時。有什麼差別？如果是後者，雖然做了五個工作天，可是實際每天有效工作實數可能只有三小時，其他時間都在打B，聊天，噗浪。因此實際只有 3 * 5 = 15 小時。只要看了 proposal 內容，40 小時和 15 小時所做出來的東西是差很多的，很容易露出馬腳。(3) 每個人的能力與經驗不同，在參考別人的 time log 時必須考慮進去。例如，Teddy 寫一份 proposal 需要 40 小時，如果是找研二的學弟來寫出類似品質的  proposal，時間可能至少需要乘上 2 或 3。（PS：學弟，不要傻傻的直接參考學長的數據）。

***

友藏內心獨白：劉老師，PSP 的訓練還是滿有用的，要繼續開課喔。

老闆，軟體不是這樣開發滴

6/13 08:45~10:50

N 年前台北捷運藍線 (板南線) 通車之後，有一天 Teddy 和第一份工作的老闆一起搭捷運（忘了去做什麼好事）。上車之後我們聊到捷運的方便性：

Teddy ：捷運通車之後節省了很多通勤時間。

老闆：我認為節省時間還不是最重要的，因為捷運使得通勤時間變的『可預測』，會因此改變人們的行為模式。

PS：當時捷運木柵線還沒有遇到強烈月光而變身為『詐胡線』，否則老闆就不會這麼說了...XD。

重點來了，速度快當然很重要，但是捷運的『可預測性』卻是改變人們生活習慣的主要因素。Teddy 第一份工作的公司剛好在捷運忠孝敦化站附近，沒有捷運之前，Teddy 搭公車可能要 40~50 分鐘才能到公司（還不包括等公車時間）。有時候趕時間搭計程車也不一定比較快，因為雖然平常覺的台北的計程車多的跟螞蟻一樣，但是上班時間經常等了很久也攔不到一輛空的計程車。所以為了不想上班或是約會遲到，就必須要提早出門以『容忍』這些『不可預測性』。有了捷運之後，從甲地到乙地（假設都在捷運沿線）的通勤時間就變得比較可預測，因此無論是人們買房子，找工作，開店，約會見面，就經常會挑選捷運沿線。這就是所謂的『改變人們生活習慣』。

『可預測性』相當大的程度是立基於『可靠性（reliability）』之上。以路上交通而言高鐵速度夠快了吧，時速 300 公里，台北到高雄 90 分鐘，好貴 好方便啊。如果今天有人發明時速 9000 公里的『超級高鐵』，台北到高雄縮短到只要 3 分鐘 ，但是有 1% 的出事率（就是平均搭 100 次有一次可能會出事），鄉民們除非是想要賺保險費，不然應該沒人敢搭。

現在『詐胡線』被罵到臭頭也是相同的原因，『詐胡線』通車之後的確變得很方便，但是它的『不可靠性』卻總是讓乘客們『心裡毛毛的』。搭完『詐胡線』沒出事內心的感受有點像是不小心中了 200 塊發票一樣湧起一絲小小的安慰。大眾運輸能蓋成這樣子，也算是『台北奇蹟』了。

***

但是，做軟體就不一樣喔，反正一般的軟體出包又不會『死人』，因此這種『先研究不傷身體，再講求藥效』的理論就不適用。所以，做軟體有自己一套的公式：

(交貨速度 = 收錢速度) >>>>> 軟體品質

備註：(交貨速度 等於 收錢速度) 大大大大大於 軟體品質 。

所以，你的老闆便可以理歪氣壯的大聲說出以下名言：

• 做專案的不需要自動化測試，做產品才要。
• 解 600 多個 bugs 要靠找『domain know-how』很強的人來幫忙。（Teddy 內心獨白：老闆，啊你嘛『幫幫忙』）
• 沒有測試人員沒關係，工程師自己測這樣就很好了。
• 這個軟體可以準備 release 了，先找幾個客戶試用。（小工程師內心獨白：報告老闆，軟體連 alpha test 都還沒開始耶）
• 軟體現在不能 release ？！我已經等了  Ν 年了，我不想再等另一個 N 年。
• 我最多給你三天，在三天之內把這個 bug/功能 給我改/做好。

***

台灣的硬體代工產業實在是太強了，強到把所有的養分都吸光以至於軟體變得很弱（這就好比 Teddy 因為中文太好以至於英文很爛是一樣的道理...XD）。雖然口頭上喊著『軟體』很重要，但這些大老闆與高階主管們絕大多數還是以代工硬體的思維來看軟體開發。

老闆：我一個工程師3～4個月就可以獨立設計一塊電路板，你們六~七個人做個『小』軟體搞了兩年還做不出來。

大老闆與好不容易熬出頭的各級主管們，Teddy 知道你們每天都有開不完的會，加不完的班，都很忙，忙到沒時間去了解軟體要怎麼開發。但請用你的『膝蓋』想一下，設計一塊電路版的背後，有多少的協力廠商已經提供好 solutions 了，而且主動的跟公司推銷這些既有的 solutions。硬體分工很細，遇到問題，背後各有不同的協力廠商會出面協助解決。有很多在硬體公司開發軟體的人，名義上號稱是設計與開發軟體，但實際上可能是只有負責把公司從其他廠商（通常是國外廠商）買來的軟體或是韌體修修補補，調整成自己公司所需要的，比較少真正有自己的軟體產品。就算是有心想要做自己的軟體產品，老闆卻天真的認為軟體開發沒什麼學問，什麼都『自己來』就可以了。 

老闆：什麼，要花錢買 components（當然是 software components），15 萬，這麼貴，自己寫比較省。要導入 Scrum，10 萬，這麼貴，自己試就好了 。要導入自動化測試，8 萬，這麼貴，人工測一測就好了。要.......『賣夠共阿啦』（別再講了），要什麼一律免談。

***  

Teddy 的第一份工作曾經開發過『連鎖洗衣店門市進銷存系統』。大家一聽到『洗衣店』一定覺的這是一個很 LO 的產業，除了當兵的時候集體送洗過衣服的超噁爛經驗以外，Teddy 從來沒有過到乾洗店送洗衣服的經驗。當時 Teddy 的直覺反應也是：『洗衣店，欬，沒什麼了不起，沒什麼了不起』。

等到 Teddy 接觸到洗衣店老闆（是一位女士）之後，嚇了一大跳，人家可是『哈佛 MBA』。在訪談需求的過程中，更是發現老闆的經營策略與台灣傳統的洗衣店大大不同，不論從『門市人員聘用』，『教育訓練』，到『定價策略』，背後都有一套科學的作法，讓 Teddy 大開眼界（真的是人外有人，天外有天。人家洗衣店老闆很低調也很客氣，並沒有一天到晚把自己是哈佛 MBA 放在嘴上）。

人客啊，人家經營洗衣店這種『傳統產業』都這麼用心了，開發軟體難道不應該也『科學化』一點？清朝末年有一段時期，中國人覺的『火車』會破壞風水，極力反對蓋鐵路，現在中國土地上高鐵滿地跑。老闆啊，軟體工程不是洪水猛獸，更不是『髒話』，經營管理的書老闆們看的夠多了，抽空看看軟體開發的『閒書』吧。再沒時間看看 Teddy 的『搞笑談軟工』也是 C/P 值頗高的一項投資。

***

友藏內心獨白：等一下又要去『天瓏』逛逛。

Quality Without A Name vs A Name Without Quality

6/12 20:27~21:12

不知道鄉民們有沒有搭過台北市的 307 公車，該公車行經台北縣市黃金路段，向來以『班次多，車速快，司機狠』等等特質聞名於世。307 公車現有『台北客運』與『大有巴士』兩家公司 獨占 共同服務，『大有巴士』的服務品質不用多說，一句話：『罄竹難書』。相較起來，『台北客運』就好很多，至少它們在轉彎的時候，都會禮讓行人。對於每天都要搭 307 上下班的 Teddy 來講，深深了解到 307 公車的『Quality』。不過，也不能一竿子打翻一船人，在『大有巴士』307 路線中，偶而也會讓 Teddy 遇到那 1% 左右的好司機，而在『台北客運』307 中，也有 30% 左右的司機會讓 Teddy 以為他們是從『大有巴士』借調而來的。總而言之，雖然司機有好有壞，整體而言307 公車具有的『Quality Without A Name (QWAN)』只要搭過幾次的人永生難忘。

有一次，Teddy 和  Kay 到台北車站搭某一路公車要到臺北市立美術館，上車之後沒過多久，Teddy 和 Kay 互看了一眼，發出會心的一笑：『這路公司具有 307 的 QWAN』。

QWAN 雖然無法被精確的命名，但是一旦鄉民們在某處經歷過，而在另一處又重新出現之後，必定能夠很快的感受到。

***

在社會上也經常能夠發覺到 QWAN 的正面與反面例子。從 10 幾年前至今，Teddy 陸陸續續也認識到不少『博士』，在名片上要印上『博士』，在 e-mail 結尾要加上『博士』，在投影上要加上『博士』，在嘴上更是三不五時要表明自己是名校正港『博士』的身份。這些人也都具有相同的『Quality』，包括『目空一切，自視甚高，舌燦蘭花，說謊不打草稿，眼高手低，號稱經驗與人脈豐富，喜歡拉關係，包打聽，etc』。實際接觸後，真是『好一個博士啊』。看過『海綿寶寶』嗎？在某一集的劇情中『派大星』也告訴別人『請叫我派大星教授加博士』，此時笑一笑就好，千萬別太認真。這種現象有另外一個名稱，叫做『A Name Without Quality 』。

各位看官們，要注意區分好的和壞的『Quality Without A Name』，以及那些『 A Name Without Quality』，才不會輕易被唬住了。

***

友藏內心獨白：老佛爺是要放在心裏尊重的，像你這樣整天掛在嘴邊講，毫無敬意，你是何居心？

從 The Timeless Way of Building 學設計 (4)

6/10 21:47~22:22

最近幾天 Teddy 真的是忙到靠北...邊走，但是為了窄小的鄉民們（說文解字，Teddy 篇：窄小，廣大的反義詞。不是說鄉民們又窄又小，是指收看 Teddy 部落格的人數很稀少），Teddy 還是拼著睡不著也要寫這一篇，這也是 The Timeless Way of Building 的核心精神。各位觀眾，掌聲歡迎：『The Quality Without A Name (QWAN)』。

翻開課本第二章

There is a central quality which is the root criterion of life and sprint in a man, a town, a building, or a wilderness. This quality is objective and precise, but it cannot be named.

這一張照片是 Teddy 在 2007 年到法國 旅遊 參加研討會，途經日內瓦，在列馬湖畔所拍攝的。要如何幫這張照片命名，才可以表達出列馬湖的『quality』呢？說『寬廣』，列馬湖是滿大的，但是又沒有大到那種非......常.........大...的大。說『漂亮』，是很漂亮，可是又沒有那種美到極致的感覺。說『高』，嗯，列馬湖的噴水柱是很高，可是又沒有 101 來的高。說『平靜』，列馬湖是會讓人整個心情放鬆，可是湖邊人來人往，又不是真的那麼『平靜』。

路人乙：（路人甲出場太多次了，今天換人）啊....哇哩勒，Teddy 你是來亂的嗎？吃這個也癢，吃那個也癢。 說這樣也不行，說那樣又不對。你到底是想怎樣？

Teddy：你說對了，quality without a name 就是說這樣也不行，說那樣又不對。也可以說『說這樣也行，說那樣也行』因為列馬湖同時都具有上述特質（quality）的某些部份，但是又沒有任何一個特質可以完全表達它。就是說『言語無法形容，只能用心體會』。如果鄉民們去過列馬湖（沒去過也沒關係，在腦袋中想像一下你曾經去過最美的地方，可能是太魯閣，龜山島，新山夢湖，etc）你就能感受到那種特質。這個特質的本身十分精確，但是卻無法用言語完整形容（無法命名）。但是，一旦你去到另外一個地方，如果這個地方也具有與列馬湖（或是你心目中所想像的那個地方）相同的特質，你卻能夠立刻辨識出來。下面的內容應該就容易了解了。

It is never twice the same, because it always takes its shape from the particular place in which it occurs.

The fact that this quality cannot be named does not mean that is is vague or imprecise. It is impossible to name because it is unerringly precise. Words fail to capture it because it is much more precise than any word. The quality itself is sharp, exact, with no looseness in it whatsoever. But each word you choose to capture it has fuzzy edges and extensions which blur the central meaning of the quality.

再舉個例子，以『whole (完整)』這個字來看，完整是什麼意思？

路人乙：完整就是完整啊，這有什麼好講的。

Teddy：一整顆蘋果被咬一口，算不算完整。

路人乙：廢話，當然不算。

Teddy：可是人家 Apple 的蘋果就是被咬一口啊，它卻是很『完整』的傳達了『人人看了 Apple 的產品都想咬一口的意念』。所以，這樣算不算『完整』。讀一下下面這句。

Imagine the quality without a name as a point, and each of the words which we have tried as an ellipse. Each elipse includes this point. But each ellipse also covers many other meanings, which are distant from this point.

***

講到這邊，那這一堆有的沒的和軟體設計有何關係。這.....快想一個說法.....。當一個建築物，城鎮，都市，具有 QWAN，那生活在裡面的人就是很自然，幸福，舒服，有活力，有朝氣，頭好壯壯，長命百歲...。問題來了，既然這個建築物，城鎮，都市具有 QWAN，那就是說『言語無法形容，只能用心體會』，那怎麼可以重複蓋出（建造出）具有 QWAN 的其他建築呢？總要有一個辦法吧！這就是本書作者 Alexander 在後續章節所要提出方法，就是用 pattern languages 來表達。

這...還是沒講到和軟體設計有何關係。...ㄟ， 鄉民們，如果有機會看到別人的軟體設計（軟體架構，一堆沒三小路用的 UML diagrams，或 source code 等等），不知道是否曾經有那種『ㄟ，這個設計怎麼那麼好』或是『靠，這程式是誰寫的』這種感覺，可是有時候又說不清楚到底好在那裡，差在哪裡？如果鄉民們學過了很多 patterns （不局限於 design patterns，也可以是 architecture patterns， coding patterns，exception handling patterns，etc）那麼，就可能『嘗試』（學過一堆 patterns 也不一定代表馬上就有能力把 patterns 串成 pattern languages，這兩者還是有所不同）從 pattern languages 的角度來解讀這個軟體設計。具有 QWAN 的軟體設計，不管它是哪個領域的軟體，用什麼語言開發的，你會覺得這個設計好棒，容易修改，擴充，測試，維護等等。沒有這種特質的，ㄟ...覺的好像住在『鐵皮屋』，『頂樓加蓋』，或是『違章建築』裡面，總是覺的『鳥鳥的』。

***

友藏內心獨白：QWAN，我真是搞不懂你啊。

再論 Problem Domain vs. Solution Domain

6/6 21:08～22:50

前一篇『這不是髒話』還沒寫完，本集繼續。M小姐後來又提到：

[13:24:49] ­而且說那找一位好一點的分析師來有沒有幫助，還說沒幫助
[13:25:03] ­因為不了解 Domain Knowhow 太好的分析師來也沒用
­ [13:25:50] ­他們說要找懂 Domain Knowhow 深的系統分析師而不是只是很會系統分析的系統分析師

M小姐轉述她主管的看法，這就軟體開發或是做專案的人很典型的一種心態，認為只要找到所謂『domain know-how 』很強的人來分析需求，做出來的系統就沒問題。錯，錯，錯，連三錯。Teddy 的意思不是說 domain Know-how 不重要，相反地，domain know-how 真的很重要，但是實做的能力也同樣重要。用講的太慢，乾脆用唱的...不對，是用看的。請看下面這張圖：

Teddy 之前寫過一篇『Problem Domain vs. Solution Domain』，M小姐主管遇到的問題便是沒有弄清楚這個概念。先看看 problem domain（就是需求），所謂『domain know-how 』很強的人的就很懂問題領域，因此可以整理出很好的需求出來（寫出很符合各客戶所需的需求，甚至是客戶沒想到的都幫他考慮到了）。再看看 solution domain，以軟體開發而言，solution domain 就是軟體設計，實做，測試這些技術（姑且先把分析歸類為 problem domain 的活動）。

看看上圖的，一共可以分成四個象限：

• A：需求和實做都做對了，這也是我們開發軟體或廣義的說開發任何系統所要追求的。
• B：需求做對，但是實做一團糟。這比較接近 M小姐主管所希望的『找到 domain know-how 很強的人來分析需求』，但是卻不在乎如何改善 solution domain (如何改善軟體開發實做面的問題，例如自動化測試)。
• C：需求錯了，但是實做正確；結果還是白忙一場。人家要吃『素食』，結果你去買個『麥當勞』牛肉漢堡回來。
• D：需求錯，實做也錯。也許M小姐所負責的專案比較接近這個情況，所以才會（1）累積了600多的 bugs（實做錯）；（2）她的主管希望找到 domain know-how 很強的人來分析需求（需求錯）。 

經過 Teddy 一番分析，鄉民們應該就很清楚了，這個 Problem Domain 和 Solution Domain 的觀念真的是簡單到不行，可惜有些大官卻不是很了，或是有意輕忽 solution domain 的重要性。畢竟有許多雖然身處軟體業的主管們依舊把『開發軟體』簡化為只有『coding』，而他們又很瞧不起 coding。說實話，就算是把開發軟體簡化為只有 coding，也不可輕忽 coding。畢竟，軟體最後還是一堆程式，要對程式碼心懷敬意啊。

***

寫到這邊 Teddy 再附贈一個故事，話說當年（又是 10 幾年前的陳年舊事） Teddy 還是青澀少年時，曾參與一個用 Java 開發的『Intranet 進銷存系統』。當時參與的三個 programmers 都是沒有進銷存 domain know-how 的人，於是公司第一任總經理就找了他的一個朋友，就是所謂 domain know-how 很強的人來做分析。光是分析就搞了一年左右，寫了一本幾十頁的分析書之後就下落不明，剩下這三隻誤入叢林的小白兔，獨自與這份破綻百出的分析書以及無辜的客戶奮鬥。

經過 N 年之後，Teddy 已非當年的年幼無知的小白兔，也了解到這種『把文件丟過門』的方式是行不通的。很遺憾，講句不要臉的話，並不是所有人都和 Teddy 一樣有一直在看書與思考。很多公司的主管，還是抱持著 N 年前做案子的模式。要『慈禧太后』相信『洋槍洋砲』比『義和團』還要厲害真的不是那麼容易的一件事，就算是現在都快民國 100 年了還是一樣。

鄉民們想想『醫生』這個行業。醫生要看病，所以一定要懂 domain know-how，否則無法找出病因。接著，醫生還要提 solution，可能是做檢查，吃藥，開刀，或是其他治療方式。所以，醫生是 domain know-how 很強，而 solution 也很強的人（不過請注意，醫生的專業分工很細，每一科的領域很窄。但是軟體卻是包山包海，什麼領域都有。）。試想一下，如果醫生只有 domain know-how，他可能會告訴病人：『恭喜，您被診斷出得了胃潰瘍，至於如何治療不關我的事』。相反地，如果醫生只有 solution 很強（很會開刀好了），那麼醫生會告訴病人：『麻煩告訴我你想被切那一塊』... 這像話嗎。

軟體開發，需求是一直改變的，就好像是病人的病情隨時在變化，不可能看一次醫生（需求分析）吃固定的藥（solution）就 OK（這是傳統 waterfall 的作法）。在病人的病情隨時會變化的情況下，醫生與病人一定要隨時互動，才有可能掌握病情。想想 Scrum 的 sprint planning meeting，daily scrum，sprint，sprint review meeting，retrospective meeting... 精神都是一樣滴。丟掉傳統那一套分析師（架構師）做完需求分析就沒事的思維吧。

結論，講了那麼多了，再不懂這個觀念 Teddy 也沒沒轍了。

***

友藏內心獨白：M小姐的公司 F 1.0 版都做了 10 年了，domain know-how 還不強，真的是太超過了。

這不是髒話

6/5 23:45~ 6/5 00:28

有點晚了，本來不該寫這一篇，以免睡不著，先講短一點的版本好了。『600 多個 bugs 要怎麼修？』的主角 M小姐昨天在 MSN 中告訴 Teddy：

[13:14:41] ­我今天才一開口說要從軟體工程著手，應該要寫Testing Code 就被打回票應說
[13:14:50] ­客製化和產品是不同的
[13:15:04] ­客製化無法從軟體工程做起，應該是要怎樣提升程式品質
[13:15:05] ­@@
[13:15:14] ­所以我就沒繼續說了。
[13:15:46] ­他們覺得我過去做產品與作客製化專案是不同的
[13:16:05] ­產品才需要不斷的作automactic test 確保品質
[13:16:14] ­無言

Teddy 看了差點沒被氣到吐血，真是他 X 的 XX。

奇怪，有些人只要一聽到『軟體工程』這幾個字，就好像聽到『三字經』（髒話）一樣，立刻從椅子上跳起來，好像想找人打架似的。

『客製化無法從軟體工程做起，應該是要怎樣提升程式品質。他們覺得我過去做產品與作客製化專案是不同的，產品才需要不斷的作automactic test 確保品質』。這幾句話比較像是火星人講的話吧，這是什麼邏輯，Teddy 真的無法理解。軟體工程不就是要『改善品質』，『提昇效率』嗎？做軟體的，不管是『產品』還是『專案』，最後給客戶的還不都是『軟體』。做產品的軟體才需要自動化測試，做專案的不用？這.........？？？？所以，這是說做專案的客戶拿到爛軟體算他『衰小...朋友』（活該倒楣），誰叫這是一個『專案』，不是『產品』。

M小姐的公司還通過 CMMI Level 3 認證勒，哇哩勒。靠...左邊走。Teddy 想該公司通過 CMMI 認證的應該是其他部門，不過這不是重點。重點是，一個通過 CMMI Level 3 的公司，居然有高層主管認為『客製化無法從軟體工程做起，應該是要怎樣提升程式品質』（前後兩句加起來 Teddy 真的看不懂，中文程度太差）。光看第一句就好：『客製化無法從軟體工程做起』，那敢問要從何做起？難不成從『偷，搶，拐，騙 + 綁標 + 送水果禮盒』做起？

基於道義無法說出該公司名稱，不過這家公司 Teddy 以前也有接觸，從 10 幾年前軟體就做的很爛，沒想到過了那麼久一直沒長進。不過，M小姐說：『人家公司都有賺錢啊』。之前  Teddy 公司第二任總經理曾經告訴 Teddy 一句話：『公司不賺錢是一種罪惡』。的確，Teddy 完全認同（薪水發不出來的時候真的很痛苦）。不過，現在要再加上，『公司賺錢也要賺的讓人尊敬』才行。有公司靠污染環境賺錢，靠壓榨勞工賺錢，靠炒地皮賺錢，靠官商勾結賺錢，靠違法亂紀賺錢，靠逃漏稅賺錢，靠發國難財賺錢，靠跳樓........大拍賣賺錢。還有 M小姐的公司，靠客戶不滿意賺錢，XX 公司，真有你的（與 M小姐無關，她才剛報到沒多久）。

友藏內心獨白：人家做的爛關你屁事。

還少一本書：Release It! Design and Deploy Production-Ready Software

06/02 20:45~22:11

Teddy 寫了 『600 多個 bugs 要怎麼修？ 』之後，突然想到之前看過的一本書：『Release It! Design and Deploy Production-Ready Software』，看書名就知道這本書的目的，的確，作者 Michael T. Nygard 也沒有唬爛讀者，這的的確確是一本值得掏錢出來買的好書。

想當年 Teddy 退伍後投入軟體業，也是很努力的開發了幾個系統，但是說實話一路上跌跌撞撞，總是有 de 不完的 bugs。為什麼開發出來的軟體就是無法有很好的品質？當然原因很多，資源不足是主要的原因，開發時程訂的很 敢 趕，也沒有專屬的測試人員，因此軟體普遍缺少完整的測試。不知道如何寫出穩定的軟體則是另外一個原因，其中包含 coding 功力不夠，exception handling 處理不良（有在處理嗎？），軟體工程的 practices 做的不夠紮實等等。

正所謂『滿天全金條，麥殺 (要抓) 沒半條』，就算是 買 看了一堆軟體開發的書還是不知道怎樣才能做出 Production-Ready Software，此時這本書便可派上用場。

這本書介紹了許多關於 stability 與 capacity 的 patterns 與 anti-patterns。看到 patterns 這個字不要被嚇一跳，本書 patterns 寫作的方式以文字說明為主，簡單易懂有又深度（深入淺出）。在這邊舉幾段書中的敘述給鄉民們參考一下：

Chapter 5: Stability Patterns

5.1 Use Timeouts

The Timeouts and Fail Fast patterns both address latency problems. The Timeouts pattern is useful when you need to protect your system from someone else's failure. Fail Fast is useful when you need to report why you won't be able to process some transaction. Fail Fast applies to incoming requests, whereas the Timeouts pattern applies primarily to outbound requests. They're two sides of the same coin.

這兩個 patterns Teddy 在開發系統的時候經常用到。先講 Fail Fast，這個 pattern 其實就是 Teddy 之前介紹過的 Exception Handling Robustness Level 裡面的 RL1 (robustness level 1)。意思是說，發生任何的 exceptions 都要立即回報，不可暗槓例外（do not ignore exceptions）。所以 Fail Fast 是有良心的 callee 要保護 caller ，確保當 callee 有問題時會告知 caller，不會像有些人偷偷打一發魚雷然後又說不是自己幹的（發生 exception 又不承認，要找 bug 就很難了）。Timeouts 則是 caller 要保護自己，不會因為 callee 沒有回應而把自己給搞掛了。Timeouts 這個機制日常生活中人人都會用到，例如，鄉民們打電話給別人，如果對方沒接，總不可能讓電話一直響下去吧。一般正常人可能響個七~八聲沒人接就會把電話掛掉了。這個『電話響多久沒接就掛掉』就是 Timeouts，保護打電話的人不會一直空等。

鄉民甲：那我寫程式都沒有用到 Timeouts 耶。

Teddy：如果是寫單機版的程式，可能比較少用到 Timeouts。但是，只要寫網路應用程式或是資料庫程式就會經常遇到。例如，建立網路或資料庫連線可能會失敗，如果不設 Timeouts 那麼程式可能會一直等下去，讓 users 以為系統當機。執行外部程式則是另外一個例子，這些外部程式可能會『卡住』，如果不設 Timeouts 整個系統也會跟著卡住。但是設 Timeouts 也是有學問的，要長到可以讓大部分的工作都來的及完成，又不能長到讓 user 覺的等太久而產生系統當機的錯覺。

***

5.2 Circuit Breaker

... It is a component designed to fail first, thereby controlling the overall failure mode.

... More abstractly, the circuit breaker exists to allow one subsystem (an electrical circuit) to fail (excessive current draw, possibly from a short-circuit) without destroying the entire system (the house). Furthermore, once the danger has passed, the circuit breaker can be reset to restore full function to the system.

You can apply the same technique to software by wrapping dangerous operations with a component that can circumvent calls when the system is not healthy. This differs from retries, in that circuit breakers exist to prevent operations rather than reexecute them.

Circuit breakers are a way to automatically degrade functionality when the system is under stress.

上面的說明應該很清楚了，直接舉個例子。假設鄉民們寫了一隻網路程式，可以接受 client 透過 TCP/IP 連線。如果同時間有大量的 requests 連過來（生意太好或是被駭客攻擊）而你的程式沒有做任何保護，那麼可能會因為建了太多連線導致資源不足而讓程式當掉或是反應緩慢到接近當掉，總之就是無法提供任何服務。如果套用 Circuit Breaker pattern，那麼當同時連線數目到達某一個數量之後，就暫時把接受新連線的功能關閉，等系統的負載降到某種程度之後再重新開啟接受新連線的功能。這樣做當然會導致系統服務水準降低，但是至少可以讓系統提供某種程度的服務，至少不會接近死當。正所謂『好死不如賴活著』，就是這個道理。

其他更多更精彩的內容就請鄉民們自己去發掘了。

***

友藏內心獨白：有時候要看了好幾本爛書，才會看到一本真正的好書。