多工，並不一定好

01/29 23:48 ~ 01/30 00:26

今天看到蘋果 iPad 上市的新聞，其中有一則提到，iPad 只有『單工』的能力，當你看書的時候，就不能聽音樂。此時 Teddy 心裡一想，都什麼時代了，怎麼還只有單工啊。光衝著這一點，就買不下手。

從電腦的角度來看，CPU 速度那麼快，一定要『多工』才划算。但是，如果處理事情的是『人腦』呢？單工是不是註定比較差？

***

最近這幾個 sprints 滿累的，因為最近 Teddy 主要的時間都在寫程式，而有 點（好大的一點）荒廢了 product owner （PO） 和 scrum master (SM) 的職務 。

這種一人分飾三角的情況犯了許多 Scrum 的禁忌，遇到的問題簡單的來說，PO 和 SM 都是 full-time job, 若是把大部分的時間都花在產品需求上面，就很可能忽略了 SM 要做的事。Daily Scrum 結束之後，也可能會比較少關注 team members 開發可能遭遇的問題，或是留意需要改善的 practices。當專注於 SM 角色時，產品需求就被冷落在一旁。只有一顆 CPU 要處裡兩個 jobs，只能做 time-sharing，沒分配到時間的工作只能挨餓了，相信有修過作業系統的鄉民們都了解。

更進一步，就是大家都知道的角色衝突。身為 PO 應該優先考慮客戶最希望獲得的功能，但身為 (SM + Developer) 常常會不經意從技術的角度來思考，因此有意無意之間，以 PO 角色挑選 stories 時，心中的 SM 或 Developer 分身就會挑出來幫忙一起亂挑，這就是一種衝突。

PO 和 SM 能不能是同一個人，就好像總統能不能身兼黨主席是一樣的。答案當然是只要是我喜歡，有什麼不可以。但是，當總統身兼黨主席，輔選時搭空軍一號趴趴走或是在高速公路上驅趕民眾，就要承受『濫用行政資源』的批評。這就是角色衝突。這種衝突的成本，團隊就要自行決定是否概括承受。當然正港的 Scrum 是告訴我們『絕對不行』。以 Teddy 的例子，明知絕對不行卻也只能『明知不可為而為之』，因為案子還是要做下去。Teddy 在『逆練九陰真經』的情況下，武功還是有所長進，但是為了避免像『歐陽峰』最後練到走火入魔的地步，要常常提醒自己不要讓某個角色餓太久。飢餓30小時可以，飢餓30天可是會死人的。

麥甲我蓋布袋, Part 3

01/23 16:06~18:00

Teddy 身上好像有種特殊的磁場，以至於『麥甲我蓋布袋』系列文章一直有寫不完的題材。這次是發生在學校圖書館事件。話說 Teddy 在學校研究所唸了那麼多年的書（因為一直無法畢業...沒什麼好驕傲的），從來都沒有在圖書館印過資料（難道這就是沒辦法早早畢業的原因？）。幾個月前才在圖書館買了兩張影印卡，第一次影印就碰了一鼻子灰。此事細節暫且不表，但不好的經驗卻成為今天的導火線。

由於 Kay 推薦的書籍已經購入，今天中午和 Kay 從家裡出發到學校借書。Teddy 在二樓圖書館看『電腦王』和『爛 Run PC』雜誌，Kay 借完書之後就在一樓看不可外借的展示新書。這期的電腦王和 Run PC 剛好各有一篇文章是 Teddy 有興趣的，於是看完雜誌之後就準備把這兩篇文章印下來。走到二樓的影印機，耶，怎麼卡片插不進去。由於第一次 Teddy 也遇到同樣的問題，該不會又壞了吧。再仔細一看，影印機的燈都沒有亮，難道是進入休眠模式（電腦用太多...）。隨便按了幾個按鍵，還是沒反應。難道是...傳說中的...電源沒開？影印機面板上有一個類似 on/off 的按鍵，用力給他按下去，還是沒反應。嗯...很多安裝『暈倒死』作業系統的電腦，進入休眠模式之後就睡死了，一覺不醒，難道影印機也有同樣的問題？還是圖書館的影印機和 7-11 一樣，要用之前要先跟店員講一下，請他們開電？還是不要隨便亂按，問一下館員好了。

就在離影印機不到五公尺的地方，圖書館的『自學中心』前方有一個櫃台，裡面有一顆在桌上趴著不能再低的人頭，應該是位工讀生，問一下他好了：

Teddy：請問影印機好像有問題不能用。

此時工讀生甲，緩緩地抬起頭來，在他那極為福相的臉龐，左右各有一顆紅紅的小太陽。工讀生甲用他那迷濛的眼神，含糊地說著...

工讀生甲：啊，什麼影印機，我不知道... 這不是我管的...要找一樓的人...

這句台詞怎麼那麼熟悉，噯呀，都是 Teddy 忘性太好，第一次使用影印機發生問題的時候，Teddy 也來問過坐在相同位置的另一位工讀生。沒想到圖書館教育訓練做的那麼成功，不同的人，居然講出一樣的話... 這不是我管的。上次 Teddy 乖乖的在一樓和三樓之間跑來跑去，好不容易才把要印的幾張資料印好。這次 Teddy 故意考考這位工讀生。

Teddy：那可以請你幫我打電話給一樓負責的人嗎？

工讀生甲：打電話...阿...阿.... (顯然還沒從和周公的會議中回過神來)...打電話我也是要走下去啊？

這句『打電話我也是要走下去啊』Teddy 就很難了解他的明白。不管了...工讀生甲老大不願意的走出他的『城堡』。走了兩，三步之後，忽然好像是挖到寶似的，對 Teddy 說..

工讀生甲：ㄟ，三樓也有影印機，你要不要去三樓印。

Teddy 一時不察，就被他呼弄過去了。三樓的影印機和二樓一樣不爭氣，Teddy 只好還是乖乖到一樓。一樓有兩位工讀生，一位是在大門口，負責還書的，另一位是 L 型櫃台的另一端，負責借書的。Teddy 前面有一位借書的讀者，等了一會輪到 Teddy...

Teddy：二樓和三樓的影印機好像不能用了。

工讀生乙：等一下我幫你看。

此時來了四，五個借書的人，等他們都把書借完，工讀生乙和門口的工讀生丙說了幾句話，就和 Teddy 到了二樓。從 Teddy 要印資料到現在，大概已經過了快 10 分鐘（沒計時，不過覺的等了有點久）。

工讀生乙：摸摸影印機，對 Teddy 說...嗯，我們一樓有影印機，不然到一樓印。

Teddy：好像是影印機的電源沒開吧？

工讀生乙：...摸摸影印機，找到電源開關，打開... 可以用了...

Teddy：（原來電源開關就在影印機左方）你們影印機好像是一早開館的時候就沒有打開啊！

工讀生乙：無言...

Teddy：我剛剛跟2樓的工讀生反應，他說這不是他管的。

工讀生乙：對啊，他只負責自學中心。

Teddy：(靠...過來一點，這句放在心中沒講) 難道要讀者上上下下跑來跑去。如果 Teddy 告訴他，影印機失火了，他也要說『這不是我管的，請找一樓』。

工讀生乙：你跟我講也沒用啊，我只是工讀生。如果你要反應，可以上網填寫讀者意見。

聽到這邊 Teddy 越聽越不爽，難道工讀生只負責領錢？這一句當然也沒講出來。索性資料也不印了，跟著工讀生乙到一樓櫃台。

Teddy：請找你們值班的職員出來，我直接向他反應。

此時工讀生乙有點嚇到的感覺，(難道遇到了包龍星，怎麼會有這麼刁的刁民... 設計口白...)，不過還是撥打了一下電話....
 
工讀生乙 ：沒人接耶...

Teddy：沒人接，難道是翹班？

工讀生乙 ：不能這麼說。
 
Teddy：可以打他手機嗎？

工讀生乙 ：我們只有分機號碼，不知道手機。
 
Teddy： 你在『騙肖耶』，怎麼可能連通訊錄都沒有，那發生緊急狀況怎麼聯絡... 這句話當然也沒說出口...

Teddy：不可能，你們一定有聯絡方式。

工讀生乙 ：抱持寧死不屈的精神... 不然你等一下再來...

Teddy 眼看工讀生乙想敷衍我，直接走到職員辦公室外面往裡看，燈是亮著不過沒看到人。算了，先去把資料印好再說。

幾分鐘後 Teddy 下來一樓，借書的人還是很多。索性找門口的工讀生丙...

Teddy：麻煩幫我找一下值班的職員。

工讀生丙 ：（撥打電話...） XXX，門口有人要找你。

工讀生丙 ：XXX 請你直接進去。

Teddy 不屈不饒的往裡走，繼續奮戰下去... 打得有點累了... 看的人想必也累了。別走開，下面的更精彩。

**************************************

到了職員辦公室，說明了來意，這位職員倒也客氣，說會改進。不過，Teddy 都還沒抱怨夠本，反倒是他跟 Teddy 抱怨了一堆。

• 我們的影印機是舊型的，沒有省電功能。因為節能減碳，所以沒有打開。（這句 Teddy 覺的有點唬爛的嫌疑，就算是真的好了，那也應該貼張紙條告訴要用的人自行開電源吧，然後用完再把電源關掉）
  
• 這些工讀生也不是我管的，不過我會跟他們主管反應。
• 我們也很難做事啊，像以前有個例子，有位校友說他忘了帶校友證，我們請他換證進入圖書館，他就不高興，大吵大鬧，最後還鬧到陳水扁那裡（對，鄉民們沒聽錯，就是暫時住在土城的那位陳先生，當年應該是總統）。結果學校上面就發公文下來... 噯呀，這種事看多了，遇到事情你說要管還是不管。（等一下，這關 Teddy 什麼事？關影印機什麼事？）
• 現在的工讀生跟以前都不一樣了....
• 我們這種作服務的很難作，尤其又是免費的... (暗示 Teddy 不要要求太多？)
  
• 你也可以跟讀者服務組（類似這樣的單位，詳細名稱記不得）的組長反應，不過他二月一號就退休了。我看你二月一號之後再跟新的組長反應。（切，抱怨還要挑黃道吉日？）

還有一些有的沒的，實在講太多了，Teddy 也記不起來。

事後 Kay 說，看到 Teddy 走進職員辦公室，就知道 Teddy 又要和人家吵架啦。

難道下次要帶數位相機，用拍的就好，不要用影印機了？

友藏內心獨白：花兩小時寫這個鳥事，還不如去寫 paper...

有 test cases 改遍天下，無 test cases 寸步難行

01/23 02:24~03:28

如果要列舉 agile methods 對於軟體開發行為模式的影響，除了 iterative and incremental (IID) 之外，最重要且影響最深遠的應該首推自動化測試了（感謝 JUnit）。幾個很重要的 agile practices，包含 refactoring 和 continuous integration，如果沒有自動化測試就『破功了』。

Teddy 本身對於自動化測試的進化路徑如下：

1. 沒寫過（不會寫也不願意寫）自動化測試。有沒有搞錯，程式都寫不完了，哪有時間寫測試。
2. 開始用 JUnit 寫單元測試。
3. 用 JUnit 寫很多單元測試。
4. 用 JUnit 寫一些整合測試。
5. 用 JUnit 寫一些功能測試。
   
6. 嘗試在 JUnit 中用 mock object framework。
7. 很少在 JUnit 中用 mock object framework。不是不好，而是不合 Teddy 的胃口。
8. 用 JUnit 寫很多功能測試。 
9. 當發現 bug 時，想辦法用寫一個測試來還原這個 bug（test-driven debugging）。
10. 三不五時想到的時候，在開發新功能時，先寫 test code 再寫 production code (玩票性質的 test-driven development)。

最近 Teddy 與同事修改專案中某個模組，增加新的功能也同時重整 (refactor) 該模組許多類別的介面。還好該模組有相當多的測試案例，所以這麼大幅度的修改，『只』產生大概 10 個左右無法立即發現的 bugs。這些 bugs 都是現有測試案例沒有涵蓋到的（廢話...），所以當 Teddy 與同事一起 pair debugging 時，我們第一步就是寫一個測試案例來暴露出這個 bug。講白話文就是寫一個一定會失敗的測試案例，當這個 bug 修正之後，這個測試案例就會成功。

這次 refactoring 主要反應了某些軟體架構上的改變，算是所謂的 big refactoring。雖然前前後後一共花了三～四天才把全部的 bugs 改完（包含寫新的測試案例），整個過程還算順利。如果沒有這些測試案例，修改的過程應該早就失控了。這種『越補越大洞』的經驗，對於廣大的鄉民們而言應該不陌生吧。

很多有心想要導入 agile methods 的人會說：『要 programmers 寫測試案例好難』，『不知道要如何開始作 test-driven development』。Teddy 的經驗是，雖然 test-driven development 是一種透過寫測試案例來達到設計程式的目的（就是 TDD 應該算 design 而不是 testing），但是除非 programmers 已經將寫測試案例當作開發系統不可分割的一部分，否則並不容易推行 TDD。如果 programmers 寫測試案例就跟『喝開水』一樣簡單與自然，那麼一不小心他們就會慢慢演化成 TDD 動物。

結論就是：不能沒有你，test cases。


友藏內心獨白：這麼晚了還不睡，寫什麼部落格，小心明天被罵！

end-to-end stories：切蛋糕篇

01/20 22:56~23:45

蛋糕這種食物，在物質條件如此富裕的寶島台灣，相信沒吃過的人應該很少。就算沒吃過，也應該看過，如果沒看過，請到 8X度C 的櫥窗看一下。

假設鄉民們買了一個生日蛋糕，除非你是買來砸人的，否則吃之前應該都要先切一下蛋糕。蛋糕有兩種切法，水平切法與垂直切法。一般正常人類，採用的是垂直切法，所以切出來的每塊蛋糕，包含了整個蛋糕的每一層，一口咬下去，可以吃到最上層的鮮奶油，第二層的香草或巧克力夾層，第三層的布丁，第四層的水果...依此類推，真是太好吃了。

至於打從火星來的鄉民們，則是採用水平切法，切出來每塊蛋糕，就只包含某一層的餡料。一口咬下去，噁...吃到滿口的鮮奶油，或是布丁，水果...。這算是在吃蛋糕嗎，還是在吃 N 種不同的食物？

******************************************

軟體開發活動中的需求撰寫，無論是寫成 use cases，scenarios，或是 stories，認真一點的鄉民們，應該還記得教科書上一定會提到，要寫成 end-to-end [use cases, scenarios, stories]。想當年 Teddy 在當 OOAD 助教的時候，也不時提醒學生們：『你這個 use case 不是 end-to-end』不過說真的，在當下聽進去的人可能不多。

寫出非 end-to-end [use cases, scenarios, stories]，就好像切蛋糕沒切好，吃的人（你的客戶）可能吃到整片的鮮奶油。你告訴他，這就是蛋糕...不可分割的一部分，先把這個啃掉，下次給你蛋糕的另外一層....N 個月後你就可以獲得一塊完整的蛋糕了。

所以，為了讓客戶在你切下每塊蛋糕的同時，就可以立即享用，你應該把一大塊蛋糕（某個需求），垂直切成很多塊的小蛋糕（很多較小的 stories）。每切完一塊蛋糕（每做完一個 story），客戶都可以吃到一整塊的蛋糕（得到一個對客位而言有價值的功能）。吃到一整塊蛋糕，即使很小一片，還是有算吃到蛋糕。吃到一整塊鮮奶油，即使很大一片，還是很噁...不算吃到蛋糕。

如果以後還有人問你：什麼是 end-to-end [use cases, scenarios, stories]，如果是好朋友，就買塊蛋糕請他吃，如果是路人甲，就請他自己去看一下8X度C 的櫥窗。

Scrum 是一種制度

01/17 21:34~23:40

依稀記得大概在兩年半前看到 Scrum 這個字眼，當時直覺的反應是：『又來了一個 agile method』。市面上 agile methods 這麼多，要怎麼學？... 阿就... 亂學 挑選第一品牌 XP 就是了。抱著這樣的精神，Teddy 也就沒特別花時間去留意這個連英文單字都不知道是什麼意思的 Scrum。

幾個月後，也忘了什麼原因，實驗室的學弟被指派報告 Scrum。一如往常，聽完之後獲得槓龜貼紙一枚。當時只記得聽到一些奇怪的名詞，什麼『Sprint, Backlog, Daily Scrum...』為什麼不叫做 iteration, requirement list, stand-up meeting 就好, 還要自創武功名稱。這些老外是怕咱們單字不夠背嗎？當時 Teddy 最沒搞懂的，就是下面這張圖中央的這兩個圈圈。慧根不夠，一個 30 天的大圈圈，背著一個 24 小時的小圈圈，光看圖很難了解它的明白。

後來，實驗室學弟 被迫 自願在某個專案上採用 Scrum，結果又累積了另一張槓龜貼紙。當時 Teddy 正忙著撰寫博速論文，也沒心思幫忙。不過主要的原因還是 Teddy 自己根本不懂 Scrum，插不上手。

無奈老天爺還是不放過 Teddy，就在 Scrum 連兩槓之後沒過多久，無意間看到了 Scrum and XP from the Trenches: How we do Scrum 這本免費的電子書。這本書只有 120 幾頁，用平鋪直敘的方式搭配大量具體的範例來分享作者自己實施 Scrum 的經驗。這本書 Teddy 反覆看了好幾次，再搭配 Agile Software Development with Scrum 以及之前看過的一堆 agile 書籍，採用雞尾酒療法的精神卯起來一次服用，藥效很強，忽然有種被黃袍加身的錯覺，也想找隻白老鼠來試一下（PS：叔叔有練過，小朋友不要學）。

後來果真找到一隻小白老鼠，到現在一轉眼過了一年半。值得安慰的是，當年這隻白老鼠到現在還健康的活著 （至少 Teddy 認為牠還滿健康的啦）。這一年半的學習歷程，Teddy 有一點點感想整理如下：

第一次接觸：經驗不是很好，因為槓龜兩次。Teddy 覺的這不過是另一個 agile method 而已。

第一次實施：Scrum 是一個很簡單的框架 (framework)，規範了角色 (Product Owner, Scrum Master, Team)，活動 (Sprint Planning Meeting, Daily Scrum, Sprint, Sprint Review Meeting, Sprint Retrospective Meeting, Product Backlog Refinement Meeting)，產出物 (Product Backlog, Sprint Backlog, Task Board, Burndown Chart, Potential Shippable Software) 。但是 Scrum 並沒有特別規範 practices。從這個角度來看，要了解 Scrum 其實很簡單，但是要實際運用 Scrum 來開發軟體，還是需要紮實的軟體工程基礎（簡單講就是 agile practices, 像是 continuous integration, unit testing, refactoring, test-driven development, pair-programming, review, design patterns... 這一些都要真的懂而且要採用）。

實施幾個月之後：Scrum 很累... 要讓這些 刁民 團隊成員乖乖的按照書上說的方法來進行 Scrum 還真不容易。


上完 Certified Scrum Master 課程：Scrum 框架本身元素很少，所以很簡單。但是 Scrum 的精神卻不容易達成。例如，Scrum 強調『持續改善』，這一點就很難。還有 Scrum 要塑造 self-managed team（講成白話文就是自我管理的團隊，就是一個老闆都不用管，就會把事情做的又快又好的團隊）也是很難。

看了 Succeeding with Agile： Software Development Using Scrum 這本書：這本書第五頁提到 Scrum 很難的六個原因，包含

1. Successful change is not entirely top-down or bottom-up; 
2. The end state is unpredictable; 
3. Scrum is pervasive; 
4. Scrum is dramatically different; 
5. Change is coming more quickly than ever before; 
6. Best practices are dangerous。

內容是什麼意思有興趣的鄉民們就去賣本書來看，Teddy 想講的是第三點『Scrum is pervasive』，也就是說，公司要導入 Scrum，不是只有某一個團隊，或是整個開發部門的事情而已，而是整個公司都要『換腦袋』。業務部門要知道在 Scrum 框架下如何跟客戶溝通，人力資源部門要改變傳統以個人來評量績效的方法（Scrum 講的都是團隊... 有點社會主義的感覺）。QA 部門不能只從規格來驗收軟體，還要從客戶是否真正需要來考慮。結論就是，這根本是 革命 嘛。

各位 agile 先聖先賢們，咱們只是想好好開發個軟體，有那麼嚴重嘛！

總之，Teddy 現在的感覺是，Scrum 其實是一種『制度』，在這個制度底下，要做的事情其實很多。好比民主制度，主流價值觀都認為民主制度很好，但是真正實踐起來卻很難，而且很花時間。以咱們台灣為例，民主國家形式上要有的元素都有了，但是實質面卻還是有很多進步的空間。買票，賄選，立法院打架，民粹，立法效率差...等等一狗票的問題都還存在，但是不繼續走下去好像也不行。實施 Scrum 的過程，有點像是從專制或是帝制換到民主共和制度一樣，以程式語言的術語來講，這就是一種『典範轉移』（paradigm shift）。會寫程式的鄉民們回想一下，從程序導向的思考模式要換到物件導向的思考模式花了你多少時間？所以實施 Scrum 要有長期抗戰的準備。

但是，先決條件是，你，你的團隊，還有最重要的是，你老闆要相信民主制度比較好。如果你的老闆是袁世凱，那實施 Scrum 是『祝恐怖』滴。此時還是大喊一聲『皇上聖明』比較實際一點。

友藏內心獨白：可以用『台澎金馬民主領域』申請加入聯合國嗎？

是的，日本的拉麵真的比較好吃

01/12 22:00~23:20

2009 年 12 月10日，Teddy 和 Kay 到日本京都玩了六天五夜。對 Teddy 而言，此行除了旅遊之外，還肩負著一個略帶研究性質的使命，是發表論文嗎，錯。是為了解開一個放在 Teddy 心中多年的疑惑：『日本的拉麵真的有比較好吃嗎？』

多年前有一陣子 Teddy 經常看『電視冠軍』這個節目，節目中時常有日本各地各種不同拉麵的比賽，每一種看起來都好好吃。在台灣，市面上也經常看到很多賣拉麵的連鎖店，Teddy 也吃過好幾間不同的拉麵麵店，可是怎麼無法體會電視節目中那些來賓們吃過日本拉麵時所散發出的幸福感。難道是日本人演技太好？還是台灣的拉麵真的沒有哪麼好吃？由於 Teddy 之前沒有去過日本，因此無法證實，這個疑問一直存放在心中。

此行 Teddy 只負責出人，行程完全由 Kay 規劃。還好 Kay 做了不少功課，在網路上查到，京都火車站 10 樓有一塊全部在賣拉麵的區域，稱作『拉麵小路』，裡面有一家叫做『寶屋』的拉麵店，賣的拉麵很好吃。

還好有漢字可以看，真的是『拉麵小路』

寶屋店門口排隊的人潮

到了日本才見識到什麼叫做『販賣機文化』，到處都有販賣機。吃拉麵之前，要先在門口的販賣機投錢買餐卷。Teddy 不懂日文，怎麼買？簡單，從最貴的開始選。不要以為 Teddy 是好野人，這邊的拉麵以日本的消費來講應該不算貴，單價最高的好像才八百多日幣。

拉麵餐卷販賣機，可接受紙鈔和銅板

Teddy 去吃的時候已經是晚上八點多，單價最高的前兩名都賣完了，所以買了780 跟 650。

拉麵餐卷

進去之後發現店面不大，大概只能容納不到20個客人。位子很乾淨，客人一離開馬上就有服務生把桌面清理乾淨並放上新的筷子和紙巾。

座位桌面長這樣

煮麵的地方長這樣

這家店有一個很貼心的服務，服務生會給你一個大箱子，讓你把厚重的衣服或皮包放在裡面。剛剛提到了，店面很小，所以箱子是直接放在地上的。由於箱子夠大，所以完全不必擔心東西放不下。鄉民們一定會認為，這樣有什麼好，不是會擋到路？錯，完全不會，就是那麼剛剛好。

箱子長這樣

講了這麼多，啊麵在哪裡？進去之後好像等不到五分鐘麵就來了。

拉麵1

拉麵2

什麼，你問 Teddy 拉麵好不好吃？這還用問嗎，用看的也知道，好吃的不得了。無論是麵條，湯頭，配料，都是 Teddy 吃過最好吃的。份量也是剛剛好，不會像台灣很多拉麵店給個超大嚇死人的碗，湯頭又不是很好，麵和週邊配備用料又省。

要怎麼形容吃完之後的感覺呢...嗯，就好像跑 JUnit，100 個 test cases 全部通過，看到一路都是綠燈的那種感覺，就差不多了。

結論就是，日本的拉麵真的比台灣的好吃很多，好想再吃一碗啊。

友藏內心獨白：以後吃不到這麼好吃的 叉燒飯  拉麵該怎麼辦啊！

用 Robustness stories 評估 SyncFree 有多強壯

01/09 23:03 ~ 01/10 00:20

對於 Teddy 的底細略有了解的鄉民們，應該知道 Teddy 博速論文研究的是軟體『例外處理』(exception handling)。如果一個軟體在執行時妥善地處理所遭遇到的例外情況，我們就說這個軟體很 robust，在此中文姑且稱之為『強壯』。一個強壯的軟體，遇到例外不會假裝沒事欺騙使用者，更不會隨隨便便的就當機 （至少會硬撐一下再當）。一個強壯的軟體是可信賴的好伙計，讓你可以放心的工作交給他。

就好像沒有人希望買到一台一撞就爛的汽車一樣，相信也沒有人願意使用動不動就死當或是造成資料損毀的軟體（暈到死系列軟體具有治外法權，不在此限）。問題來了，使用者要如何判斷一個軟體系統強不強壯？而稍微有點良心的軟體開發人員要怎麼自我評估軟體夠不夠強壯到可以拿給使用者用？

這邊 Teddy 提供一個簡單的方法，藉由撰寫 robustness stories (強壯故事？好爛的翻譯) 來表達軟體例外處理的需求。Teddy 用 SyncFree 這個軟體舉個實際的例子說明。SyncFree 是一個跨平台的檔案同步軟體，可以雙向同步來源與目的資料夾中的檔案，也可以單向的把來源資料夾中的檔案備份到目的資料夾中。SyncFree 是用 Java 開發的軟體，在Windows 和 Linux 平台上都可以正常的執行。以下是 SyncFree 在 Ubunut 9.10 x64 執行的畫面。

使用 SyncFree 的人（就是 Teddy 啦），最擔心的就是執行 SyncFree 之後檔案並沒有真正同步，以及發生檔案損毀的問題。為了評估 SyncFree 是否夠強壯到可以保護 Teddy 的資料，Teddy 寫了以下這幾個 robustness stories 。

1. 身為使用者，Teddy 希望當來源或目的磁碟機容量不足時，執行 SyncFree 雙向同步不會造成檔案複製不完整 （不會影響資料正確性）。
2. 身為使用者，Teddy 希望使用 SyncFree 同步檔案時若來源目錄不存在，不會毀損目的目錄中的資料。
3. 身為使用者，Teddy 希望使用 SyncFree 同步檔案時若目的目錄不存在，不會毀損來源目錄中的資料。
4. 身為使用者，Teddy 希望使用 SyncFree 同步檔案時若有檔案被其他使用者刪除，不會造成同步資料錯誤。
5. 身為使用者，Teddy 希望使用 SyncFree 同步檔案時若有檔案被其他使用者改名，不會造成同步資料錯誤。
6. 身為使用者，Teddy 希望使用 SyncFree 同步檔案時若有檔案被其他使用者鎖住，不會造成同步資料錯誤。
7. 身為使用者，Teddy 希望使用 SyncFree 同步檔案時若遇到唯讀的檔案，不會造成同步資料錯誤。
8. 身為使用者，Teddy 希望使用 SyncFree 同步檔案時若使用者操作檔案的權限不足，不會造成同步資料錯誤。
9. 身為使用者，Teddy 希望使用 SyncFree 同步檔案時若來源檔案檔名太長無法複製到目的磁碟，不會造成同步資料錯誤。
10. 身為使用者，Teddy 希望使用 SyncFree 同步檔案時若檔名中有特殊編碼的字元，不會造成同步錯誤。
11. 身為使用者，Teddy 希望使用 SyncFree 透過網路同步檔案時若網路中斷，不會造成檔案複製不完整或同步資料錯誤。
12. 身為使用者，Teddy 希望使用 SyncFree 同步檔案時若 SyncFree 被殺掉或電腦當機或電源中斷，不會造成檔案複製不完整或同步資料錯誤。
13. 身為使用者，Teddy 希望使用 SyncFree 同步檔案時若 Teddy 中斷同步執行，不會造成檔案複製不完整或同步資料錯誤。
14. 身為使用者，Teddy 希望使用 SyncFree 同步檔案時若發生 out of memory exception，不會造成檔案複製不完整或同步資料錯誤。
15. 身為使用者，Teddy 希望使用 SyncFree 同步單一檔案大小為 20G 的檔案不會造成檔案複製不完整或同步資料錯誤。
16. 身為使用者，Teddy 希望使用 SyncFree 同步20萬個檔案不會造成檔案複製不完整或同步資料錯誤。
17. 身為使用者，Teddy 希望 SyncFree 執行完畢之後不會鎖住檔案造成磁碟機無法卸載。
18. 身為使用者，Teddy 希望即使來源與目的電腦時間不同步，SyncFree 還是可以正確地同步檔案。
    

如果上面這 18 個需求 SyncFree (或是任何一個檔案同步軟體) 全部都可以做到，那麼鄉民們應該可以放心的把心愛的資料交給 SyncFree 來同步或備份。當然，前提是在沒有任何例外發生的情況下，SyncFree 的功能要能正常執行，也就是說雙向同步或是單向備份之後，兩邊的資料要是正確的。如果正常功能都不正確 （correctness），就不用談例外處理的問題了 （robustness）。

什麼，你問 Teddy Syncfree 有沒有滿足這 18 個需求？
Teddy 說：如果有，就不會寫這一篇部落格了。