C. C. Agile 聚會Sprint 6 精華報導

Feb. 21 23:12~23:45

2/21號晚上第六次C. C. Agile每月聚會由Teddy分享：「搞懂Java例外處理的難題：Checked與Unchecked Exceptions不再是問題」。這次聚會場地換到位於台大附近的靈感咖啡，整個場地的氣氛還不錯，位置也還算寬敞。

一開場先提一個問題：有沒有人覺得自己寫的程式很穩定的？結果現場的朋友都很客氣的不舉…手。

 

系統不穩定會造成公司獲利下降的問題。而導致系統不穩定的原因有兩個，系統正確性不足與系統強健度不足。

 

增加軟體可靠度的方法可由contract specification與exception handling這兩方面著手。

 

Java語言原本希望藉由checked exception來提升程式開發人員對於例外處理的重視。

 

Java語言設計者希望用checked exception來代表「可修復的錯誤狀況」，用unchecked exception代表「不可修復的錯誤狀況（programming error，白話文叫做bug）」，。

 

Checked exception之所以叫做checked exception（受檢的例外或是被檢查的例外），指的是Java Compiler會幫鄉民們檢查checked exception的使用使否有符合所謂的handle-or-declare rule（捕捉或宣告原則）。違反此原則的程式Java Compiler將視為語法錯誤。

 

Checked exception所引發的幾個問題。

 

最後導致鄉民們內心怒吼：我不會處理Exception怎麼辦啊？

 

所以光是知道exception type是不足以設計例外處理程式，需要同時考量下列五個因素。

 

結尾做幾個簡單的思考練習，幫助大家把今天分享的內容串起來。

 

最後打個廣告，Teddy今年會開例外處理設計與重構的課程。

***

今天分享的投影片內容Teddy放在「搞笑談軟工Facebook社團」當中，有需要的鄉民請自行下載。

***

友藏內心獨白：這一週的生活也太札實了一點吧，難道這是過年太爽的報應嗎。

Location-Based Reminder

Feb. 20 17:00~18:35

昨天在《重回校園》中Teddy提到這學期在台北科技大學兼了一門「軟體生命週期管理」的研究所課程，這門課將在Scrum框架下分組開發一個Android App。今天跟助教討論這個App的題目，是要由學生自由發想，還是由我們指定。討論到一半Teddy突然想到之前很想做一個Location-Based Reminder的App，那就不如以這個當作題目好了。

先把這個App的vision寫出來，上課的時候讓學生依據這個vision來發想與討論出product backlog。

Vision
你有以下這些困擾嗎：「來到超市買東西，卻怎麼也想不起某樣上次忘了要買的物品」、「到迴轉壽司店又不小心點了之前吃過但卻不好吃的生魚片」、「路過超商卻忘了繳電話費」、「逛夜市卻忘了上次吃過某樣很好吃的食物是什麼」、「走在某條路上不小心踩到狗屎」…。身處資訊爆炸的時代，現代人的腦袋已經嚴重超載，很容易忘東忘西。智慧型手機的普及與便利性，正好可以用來協助人們記憶一些瑣碎的事情。

我們想要開發一個可以依據「使用者所在地點」提供提醒功能的手機App，當使用者到達或離開某個特定地點（例如台北車站、忠孝新生路口）與某特定類型商店（例如便利商店、郵局、銀行、飲料店），此App可以主動提醒使用者於事前所記錄的提醒事項。

需求發想

撰寫story的時候應考慮以下幾點可能會影響App是否容易使用的因素。

• 如何指定地點或特定類型的商店？
• 如何指定提醒事件？
• 距離解析度（要趨近目標多近或離開目標多遠啟動提醒功能）？
• 可否與社群網路、Google Map、照相等功能結合？
• 不可因為執行此App而過於耗電。

***

雖然市面上已經有Location-Based Reminder的App，不過這個題目Teddy還是覺得挺有趣的，希望學生能夠開發出輔助 中年大叔 記性的好用小工具。

***

友藏內心獨白：期末sprint review就要在Teddy的手機上實際安裝執行田野測試。

重回校園

Feb. 18 23:06~23:58

過完年學校也開學了，原本學校開學不關Teddy的事，但這學期Teddy在指導教授的熱心推薦與牽線之下，在台北科技大學（北科大，是捷運忠孝新生站那一間，不要和基隆路那一間搞錯了啊）兼了一門「軟體生命週期管理」的研究所課程。這門課由資工所和互動所合開，借用之前跨界開發的經驗（請參考《我們都是設計師：跨界敏捷工作坊實況報導》），希望把設計師（互動所學生）和工程師（資工所學生）混和搭配，利用一學期的時間，在Scrum框架下實作出一個Android App。

以下是這門課的課程內容，每次上課6小時，隔週上一次課。在一學期中安排6個雙週長度的sprint，每次在課當中讓學生們當場進行sprint planning、review、retrospective等活動，開發工作則在課程結束之後進行。除了Scrum框架的介紹與活動練習，課程內容還包含Agile UX、Pattern原理介紹、Mobile UI Pattern、ATDD & Mobile App Testing、Usability Testing、手機雲端持續整合系統使用等。

上課日期	課程內容	備註
1 (02/21)	1. 課程進行方式說明 2. SLM + Scrum overview 3. 分組需求發展、Product backlog介紹 4. ezScrum使用介紹 5. 建立初始product backlog	1. 課程中完成分組，確定分組名單，每組5~7人。 2. 選定Product Owner、ScrumMaster、Team Member
2 (03/07, sprint 1)	1. Sprint planning meeting part 1說明 (Value、Story point) 2. Sprint planning meeting part 1 練習 3. Sprint planning meeting part 2 (切task、估算task)、Daily Scrum 4. Sprint planning meeting part 2練習	1. 製作task board、練習畫Burndown chart 2. Daily Scrum練習 3. 課堂結束後各團隊即開始正式第一個Sprint 。各團隊必須請TA參與一次該組的Daily Scrum。
3 (03/21, sprint 2)	1. Sprint 1: Sprint Review and Retrospective 2. Agile UX，參考Agile Experience Design 3. Sprint 2: Sprint planning meeting	1. Demo:完成User Story、Burndown Chart 2. 實施Scrum的過程，附上照片與相關截圖。
4 (04/11, sprint 3)	1. Sprint 2: Sprint Review and Retrospective 2. Pattern原理與寫作練習 3. Sprint 3: Sprint planning meeting	1. Demo:完成User Story、Burndown Chart
5 (04/25, sprint 4)	1. Sprint 3: Sprint Review and Retrospective 2. Mobile UI Patterns 3. Sprint 4: Sprint planning meeting	1. Demo：完成User Story、Burndown Chart 2. 繳交期中自我評量表
6 (05/09, sprint 5)	1. Sprint 4: Sprint Review and Retrospective 2. ATTD and Mobile AP Testing Tools、CI 3. Sprint 5: Sprint planning meeting	1. Demo:完成User Story、Burndown Chart 2. MonkeyTalk、Robotium 3. 雲端測試系統使用介紹
7 (05/23, sprint 6)	1. Sprint 5: Sprint Review and Retrospective 2. Usability Testing 3. Sprint 6: Sprint planning meeting	1. Demo:完成User Story、Burndown Chart、測試報表 2. Usability testing 實作練習 3. App上架準備
8 (06/06, release)	1. Sprint 6: Sprint Review and Retrospective 2. Software release 3. Selected Topic I	1. Demo：完成User Story、Burndown Chart、測試報表 2. 繳交期末自我評量表
9 (06/20)	Selected Topic II

***

這是一門著重實作以及動手參與的課程，評分標準也很簡單：

• Sprint成果：70%
• 前五次sprint每次佔10%，最後一個sprint（release）佔20%
  出席與課堂活動參與：30%

***

友藏內心獨白：教書比當學生還要累啊。

Fault、Error、Failure、Exception

Feb. 18 20:48~22:43

今天下班之前整理了一下Teddy發表在部落格上關於例外處理的文章，一共有32,557個字。雖然Teddy很想在今年底之前寫完《設計模式的逆襲》這本書，但是看到部落格上例外處理的文章比設計模式的還要多，此時Teddy便有點猶豫了，到底是要先寫比較不好寫但應該比較有「錢途」的《設計模式的逆襲》，還是讓Teddy的「法定專長」《例外處理設計的逆襲》先插隊哩。好難抉擇啊。

先不想那麼多了，什麼資料比較完整，就先寫什麼吧。Teddy在2007年12月寫了《例外處裡 (2)：名詞解釋》，解釋了例外處理設計領域很重要且容易混淆的四個觀念：fault、error、failure、exception，今天用一張圖來補充說明一下，看了圖之後就比較容易了解這四者的關係。雖然上圖由右至左、由上至下的順序是fault、error、failure、exception，但解釋這些觀念用相反的順序比較容易理解。

***

Failure

Failure（失效）指的是一個系統或軟體元件（function、method、service）的行為偏離其原先定義好的規格 (specification)。例如：

• int add(int first, int second)這個function，傳入1和5這兩個參數。在正常情況下應該要回傳6，如果傳回6以外的任何答案，都算是add()這個function失效。
• 一個網路購物系統，所有的線上扣款動作都必須在60秒之內完成。如果超過60秒尚未完成則視為扣款功能失效。
• 一個客戶關係管理系統要連到後端資料庫讀取使用者登入帳號與密碼，但是網路不穩導致連線斷斷續續，系統登入功能無法使用，使用者登入失敗。

Error

Error（錯誤）指的是系統或軟體元件內部處於錯誤狀態(erroneous state)。當error發生的時候，如果系統或軟體元件可以加以修復，回到一個沒有error的正確狀態，則就可以避免發生failure。反之error則會導致failure。一個最常見的例子就是資料庫交易處理（transaction processing）。當交易處理失敗，例如某個table的資料被別人鎖住或是要刪除的資料已被其他人給刪除，此時的資料庫內部狀態是不正確的（error 發生）。但只要rollback此筆交易，讓資料庫回到正確的狀態，則failure就不會發生。

Fault

Fault（缺陷）可以區分為兩大類：design fault（設計缺陷）和component fault（元件缺陷）。

• Design fault又稱為defect或bug，是人類在軟體開發過程中所犯下的錯誤。例如，忘記初始化物件、把除數設定為零、演算法設計錯誤等。
• Component fault則是指軟體元件與軟體元件之間，或是軟體元件與執行環境之間互動時所產生的不正常情況。例如，一個原本運作正常的網路連線忽然中斷、儲存資料時發現硬碟空間不足、列印檔案時印表機未開啟等等。

軟體系統若是存在著fault，在系統執行期間如果執行到這些fault所屬的程式，則將會導致error發生。在開發軟體時，除非考慮到design fault與component fault所可能導致的error並加以處理修復，否則error將進一步使得軟體產生failure。

Exception

在支援Exception（例外）概念的程式語言中（例如Java、C#），則是使用exception來表示error與failure。當程式語言的執行環境發生到fault的時候，會產生一個exception物件來代表這個fault。例如Java語言的BufferOverflowException、NoSuchElementException、NullPointerException。如果這些error沒有被處理，最後導致某一個method執行失敗，則該執行失敗的method可以丟出一個自己定義的FailureException例外用來表示failure。

***

友藏內心獨白：看完 寫完之後頭好暈啊…Orz。

Checked or unchecked exceptions (5)

Feb. 17 23:33~Feb. 18 00:47

畫面節錄自：這裡。

雖然Java的例外處理設計還有很多可談之處，不過關於checked與unchecked exception的愛恨情仇第一回合到今天要先告個段落。今天要談在《Checked or unchecked exceptions (1)》文末所遺留下的第四個問題：

有些鄉民們「不遵教化」，打死都不想用 checked exception。問題是這些鄉民們又沒事寫出很多很好用的open source軟體，那麼當我們使用這些軟體的時候，就開始神經錯亂了。原本Java告訴大家，unchecked exception代表bug，不需在程式中handle而是應該是去修復這個bug。但是不甩這一套的人也很多，他們只願意使用unchecked exception，也就是說這些人用unchecked exception來代表recoverable condition與 programming error。那麼使用這些人所寫出的程式的鄉民們將「民安手措其手足」？

舉個例子，在Standard Widget Toolkit (SWT, Eclipse的UI元件)中，SWTException用來表示可修復的SWT錯誤（recoverable SWT errors），而SWTError則用來表示不可修復的錯誤。這兩個例外都是unchecked exception，換句話說，SWT不使用checked exception，而是用兩種不同類別的unchecked exception（SWTException與SWTError）分別代表可恢復與不可恢復的例外狀況。

類似的例子還有Spring與Hibernate這兩個廣泛被使用的開源軟體，它們也是不喜歡checked exception而只使用unchecked exception。

***

看到這邊鄉民們可能會想，好啊，有人不喜歡checked exception而只用unchecked exception那又怎樣，關我屁事？對於Java程式設計師而言，這其實是一件很討厭的事，Teddy歸納如下：

• 原本Java語言告訴鄉民們：「checked exception代表可修復的例外，unchecked exception代表程式中有bug（不可修復的例外）」。
• 但是，有人不吃這一套。所以搞到最後，有規則等於沒有規則，因為不管是checked或是unchecked exception，都可以用來表示可修復的例外。
• 那麼鄉民們就要搞混了，到底哪些例外要補抓起來加以處理，那些不需要？

其實問題的答案Teddy在《Checked or unchecked exceptions (2)》已經說明過了，在程式中收到一個例外的時候，光是依據例外的類別是不足以決定例外處理的方法，必須要一併考慮下列五項因素才能決定：

• Exception Type
• Recoverability
• Application Context
• Robustness Level 
• Exception Handling Policy (Strategy)

也就是說，不管是任何物件導向程式語言，決定例外處理的設計方法必須要考慮上述五個因素。舉個例子，假設鄉民們在程式中收到一個SWTError exception，依據剛剛的說明：

• 首先判斷Exception Type。這是一個unchecked exception所以如果不想處裡的話在程式中可以不必使用try-catch特別去捕捉。
• 接著判斷Recoverability。在SWT的定義中，這是一個不可修復的例外（irrecoverable exception）。基本上如果是一個不可修復的例外，就更不需要捕抓它，直接讓這個例外往上傳遞即可，交給最上層的程式將這個例外訊息回報給使用者知道即可。

但是，上述的五個因素還有三個沒有考慮。如果全部考慮進去，例外處理的方法就不一定是直接往外丟。

• 接著同時考慮Robustness Level（強健度等級）與Application Context。假設捕捉到SWTError exception的這個元件是屬於底層（Application Context）的元件，鄉民們希望這個元件的Robustness Level能夠到達Level 3: Behavior-recovery (行為回復）的等級以便減輕上層的元件的錯誤處理負擔。要達到Behavior-recovery，就代表程式要具備容錯的能力，因此既使SWTError exception是一個不可修復的例外，鄉民們也要想辦法設計出可以修復此例外的程式。
• 最後決定採用哪一種Exception Handling Policy（例外處理策略）。選擇方法也不難，因為已經知道要達到Behavior-recovery，而SWTError exception又代表一個不可修復的例外。也就是說理論上原本發出SWTError exception的那個元件已經變得不可靠了，因此最好不要採用retry的方式重新呼叫原本發出例外的那個元件。此時便可選擇Retry with alternative methods（可能還須配合使用其他方法以便將系統回復到一個正確的狀態）。

***

結論也很簡單，只要謹記Exception Type、Recoverability、Application Context、Robustness Level、Exception Handling Policy，不管鄉民們使用哪一種物件導向程式語言，都可以輕鬆設計例外處理程式。

***

友藏內心獨白：年假結束要上班了。

2009北越跟團之旅Day3-A陶藝商店、還劍湖、胡志明廣場

Feb. 16 11:05~11:54

第三天一早起床從飯店窗外拍了幾張照片，遠望可以看到下龍灣以及海中的船隻。

 

吃完早餐之後離開下龍灣回到河內，途中在一家陶藝店暫停休息，這應該算是購物行程兼下車尿尿。

 

有些作品還滿可愛的，配色很好看。

 

離開陶藝店後回到了河內。

 

中午在某個地方吃越式吃到飽自助餐，用餐的地方非常的大，大過所有Teddy在台灣吃過的吃到飽餐廳。

 

吃完飯之後下午終於來到今天第一個真正的景點，還劍湖。明朝初年越南還是明朝的屬地，據說越南「黎利」在此湖得到神龜送來寶劍，黎利以此劍帶領越南軍隊打敗明朝駐軍，獨立建國成為安南國王。擊退明軍之後，黎利將此劍還給神龜，故此湖稱之為還劍湖。

 

湖旁邊有一間廟名約「鎮國古寺」，主要行程是來參觀此廟。據說此廟是越南最古老的寺廟，建立於六世紀。

 

廟中有一棵1959年由印度前總統Rajendra Prasad與胡志明一起種下的菩提樹。

 

還有一個寫著漢字的石碑。

 

離開還劍湖之後來到胡志明廣場，整個偌大的廣場沒什麼人，當時太陽很大，在這裡拍幾張照片之後就閃人了。

***

友藏內心獨白：怎麼感覺一整天都在「快閃」。

2009北越跟團之旅Day2-下龍灣

Feb. 05 21:50~22:28

早上來到渡口搭船遊下龍灣，這裡的船隻有夠多，遊客也很多。

 

空少…不對，應該是船少。

 

海面上船很多。

 

小蜜蜂也不少。

 

出發不久之後來到海中的一個平台，地陪說要幫中午加菜，請旅客協調一下要買些什麼海產當午餐。

 

下龍灣的景色真的很漂亮，用看得比較快。

 

這塊石頭很特別，船隻還要排隊讓旅客照相。

 

接著來到某個小島，參觀鐘乳石洞。

 

印象中參觀完鐘乳石洞之後回到船上吃午餐，同時間船慢慢地開回渡口。

***

友藏內心獨白：如果能夠在海上待久一點應該會更好玩的說。