l

2011年4月22日 星期五

落實的能力 (2)

April 22 21:20~22:18

昨天寫到一半跑去到垃圾,當 Teddy 把垃圾放在電線桿旁邊,人站在離垃圾約 5 步之遙的位置,正在等待垃圾車到來時,突然發現有某位婦人正在偷偷地亂搞 Teddy ...的垃圾。Teddy 也沒想那麼多,直覺反應立刻跑過去說了一聲『這是我的垃圾耶 (垃圾還怕人家搶...XD)』。原來那位婦人手上拿著兩包小垃圾,但是她沒有使用 舊北市 台北市政府所規定的垃圾袋,所以她就到處找『落單的垃圾袋』,試圖把她自己的垃圾『寄生』在別人的垃圾袋之中。

被 Teddy 一喊,這位婦人面露不好意思的表情,就帶著她的那兩小包垃圾,另外尋找合適的寄生對象。事後 Teddy 想一想,會不會太嚴厲了一點,也許有些人真的有經濟上的困難,雖然一般人可能覺的一包專用垃圾袋沒多少錢,但是對於經濟較不寬裕的人,長期省下來也是一筆小錢。至少這位婦人也沒把垃圾亂丟,還願意把自己的垃圾寄生在別人的垃圾袋裡面,也算是還有守法的精神了。和那些把垃圾隨地亂丟,或是硬塞到路邊垃圾筒的人相比,這位婦人算是有公德心的了。以後如果再遇到這種『垃圾寄生事件』,應該要抱持著寬容一點的心去看待才是。

***

昨天談到在持續整合系統(以下簡稱 CIS)上面如何兼顧『縮短整合執行時間』與『執行多樣化整合任務』這兩件事,最後得到『安裝兩套 CIS,一套用來跑編譯與產生安裝程式的工作,另一套用來執行整的整合任務』這樣的結論。

說真的 Teddy 之前沒想過這個問題,記得有快四年前有一次 Teddy 聽到有人在 CIS 上面只編譯程式而沒有執行單元測試,當場表現出『CI 不是這樣做滴』的鄙視態度。對於對方回答『測試案例執行時間太久了啊,所以為了縮短整合的時間,只能選擇不去執行單元測試』這樣的理由,當時 Teddy 是完全無法接受。為什麼?因為『書上說』單元測試就是要『想辦法』跑的很快啊,如果寫出來的單元測試跑的很慢,那一定是不認真沒有寫出『正港的單元測試啦』。因為單元測試跑太久在 CIS 上面就不執行,如此因噎廢食的態度,實在是無法認同。

沒多久 Teddy 也面對到同樣的問題...結果...走上同樣的道路...『測試案例執行時間太久,所以為了縮短整合的時間,只能選擇不去執行單元測試』。如此向下沉淪,實非 Teddy 行事之道。很遺憾,已經如此苟且偷生快三年了,難道這就是傳說中的『理論與實務之間的差距』?以Teddy 的情況而言,會演變至此有以下幾個原因:
  • 把 code 送交到 CIS 之前都有在開發環境(Eclipse)上執行 JUnit,所以在 CIS 上面沒有跑 JUnit 的罪惡感就沒有那麼重...XD
  • 每次把 code 送交到 CIS 之後,過不久就會產生一個 Installer 程式,而 Teddy 所屬團隊後來都有一個習慣,會直接去測試這個新產生的 Installer。由於我們有採行一些辦法讓測試整個 Installer 的流程比較順一點,所以慢慢也就覺的沒有在 CIS 上執行單元測試好像還過得去。
  • 因為我們的程式需要跨平台與硬體設備相依性很高,而 CIS 目前是安裝在 Linux 上面。以前剛開始還有在跑 JUnit 的時候,有一些與平台或是硬體相依的 test cases  會失敗,也沒有人去理它,因為大家都知道此為正常現象,請安心服用...XD。久而久之就沒有去注意 CIS 上面執行失敗的測試案例。既然沒人去看,為了省時間就乾脆廢掉算了。
  • 當然最後總歸一句就是要省時間,趕快拿到新產生的 Installer。
  • 再加上後來有採行每天晚上自動執行功能測試案例,自此之後在 CIS 上沒有執行單元測試這件事情就更加逐漸的被遺忘。
***

其實省時間的另外一個方法就是升級硬體,自從換了高檔的伺服器作為執行 CIS 的電腦之後,『手頭寬裕了不少』,因此開始想要儘量回歸到原本 CI 的精神,除了執行單元測試以外,test coverage 與靜態程式碼分析(FindBugs, PMD 這類的工具)也都要執行一下。今天在 sprint demo meeting 時,大家看了一下 PMD 的報表,就當場不小心找到一個 bug。雖然是一個小小的 bug,但是當下大家都認同這件事情應該要做。PMD 這個工具大概 5-6 年前 Teddy 就用過了,但是都是心血來潮時稍微用了一下下,從來沒有持續使用下去。可是只要是跟別人介紹 CI 觀念,都會提到 test coverage,PMD, FindBugs 這類的工具。為什麼不能持續使用的原因姑且先不談(因為打字打到手痛了),現在把 test coverage,PMD, FindBugs 放到 CIS 上面,有以下幾個好處:
  • 整個 team 的人都看的到,專案變的更透明了。例如,當 Teddy 看到某個 class 的 test coverage 很低的時候,就有一股衝動會想要去多寫幾個 test cases。這難道是『便利商店集點活動症候群』發作嗎?
  • 由於專案變透明了,如果自己寫的程式被這些工具找出太多明顯的 bugs,那就有點『太難看了』。所以 programmers 會更『自愛』一點。往正面思考,可以學到一些平常疏忽的 coding 技巧或是應該要避免的壞習慣。
  • Scrum Master 如果沒事可看看報表,很容易可以找出一堆有待改善的項目。
  • Test coverage 如果很高,可以拿到客戶面前去『炫耀』。
啊,衣服洗好了,Teddy 要去批衣服了。
***

友藏內心獨白:好忙的一天,為了九顆硬碟得罪了一堆人。

2011年4月21日 星期四

落實的能力

April 21 20:46~21:32

幾年前 Teddy 還在唸書的時後,看了一篇 Continuous Testing 的 paper,大意是說,在 Eclipse 平台上,利用現在個人電腦都跑很快的特點,當使用者在 coding 的時候,Continuous Testing 系統(一個 Eclipse plug-in)就偷偷在背景模式幫 programmers 執行 unit tests,如此可以縮短 coding -> run unit testing 這個開發週期的時間。當時  Teddy 和某個學弟還改良這個想法,在 Eclipse 上面也開發了一個類似的 plug-in,雖然研究的性質居多,在實際軟體開發上面沒有真正派上什麼用場,但是覺的滿有趣的。

最近 Teddy 在思考如何縮短持續整合與建構的時間(請參考『Ten-Minute Build 』),雖然可以透過硬體升級的方法,把產生安裝軟體的時間從原本的 15 分鐘縮短到 3 分鐘,但是過這個過程是不包含執行單元測試的時間。做持續整合沒有跑單元測試其實是不對的,但是在實務上雖然 developers 都有寫單元測試,但是有些單元測試的執行時間還滿長的。最理想的作法當然是要想盡辦法用 mock objects 這一套方法來讓單元測試跑的很快,但撇開這個不談,假設鄉民就是有一堆跑起來不是很快的單元測試,那麼在實施持續整合的時候到底要不要跑這些單元測試?請鄉民們先想一想...

***

所以,為了加速數產生安裝程式的速度,有一種方法是要求 developers 至少在開發環境上(例如Eclipse)要執行單元測試,然後在持續整合系統上則不用執行,但是另外以 Robot 撰寫自動化功能測試來彌補。這些自動化功能測試每天晚上會執行一次(nigh),早上的時候有一個 倒楣的人 專門的人會去看看那些 test cases 沒有過,然後去找出問題並加以解決。

如果鄉民們喜歡的話,也可以把這些自動化功能測試範例搞成一包『自動化功能測試包』,然後用綠色軟體的方式隨時佈署到待測平台上面執行功能測試。

***

假設鄉民們的持續整合機器具有多核心的 CPU,例如有兩顆 Intel Xeon 的 CPU,每一顆 CPU 有 6 個 core,可以跑 12 個 threads,只用來執行單一的持續整合工作太浪費了。此時可以考慮在持續整合系統上面幫『執行單元測試』這件事專門建一個專案,然後當有需要的時候就去跑一下單元測試,如此一來便可同時兼顧『快速建構』與『執行單元測試』這兩件事。

其實每一次建構一個專案,除了基本的 compile 與 testing 以外,還有很多事可以做。例如,分析 test case coverage (會有點花時間),做靜態程式碼分析等等,這些都是以前很想做但是『沒時間』做的工作。現在把『執行單元測試(廣義的來講,應該是執行完整的整合工作)』這件事獨立成一個專案,這樣就有機會可以很頻繁的執行。你問為什麼?因為電腦跑很快啊,所以可以在電腦上面裝兩套持續整合系統,一套跑現有的工作(編譯並產生安裝程式),另外一套跑『完整的持續整合』,這樣就有點類似把 Continuous Testing 的概念套用在 Continuous Integration 上啦。

這樣講不知道鄉民們有沒有看懂...啊,Teddy 要準備去倒垃圾了,改天再聊。

***

友藏內心獨白:知道持續整合和落實持續整合中間的 gap 還是滿大的。

2011年4月19日 星期二

答客問 (二)

April 19 22:23~23:18

經過一天的沈澱 Teddy 突然又想到當天客人問的兩個問題,剛好今天也沒什麼料可以寫,就來講一下這兩個問題。

人客丁:在 Daily Scrum 的時候你會分派 task 嗎?

Teddy:會...每天...XD... 嗯嗯... 這樣講起來好像 Teddy 假 Scrum 之名行獨裁之實。其實應該說,2/3 的時間不會(因為不需要),其他 1/3 的時間不知為什麼有些比較重要但卻賣相不好的 tasks 就是沒有人認領。這些 tasks 包括:

  • Acceptance testing:因為團隊中都是 programmers,像 acceptance testing 這種『苦力』的工作認領度就比較低一點。
  • Review:這一類的 tasks 也是屬於比較冷門的工作,要在一團麵線中理出個頭緒也是挺花腦筋的。
  • 寫使用手冊:這...別說是英文的手冊,就算是中文的手冊大部分的 programmers 也不喜歡寫。寫『文章』畢竟和寫程式不同,所以這一點 Teddy 是可以體諒的。寫文件本來就應該要找 technical writers... 但是...別想太多...還是自己包了吧。
  •  古怪型:有一些『古怪』的 task 大家也都不想去認領,至於哪些屬於『古怪』的 tasks 就要看情況而定。例如,要去釐清一個不知名原因的 issue 就屬於『古怪』的 task。
通常 Scrum Master 只要堅持一個簡單的原則,就不需要『分派』tasks,這個原則就是『重要性高的 story 所屬的 tasks 要先做』,由於沒辦法『柿子挑軟的吃(task 挑喜歡的做)』,這樣子大家被逼的沒辦法就只好去領取那些『不討喜』的 tasks。萬一有些 tasks 就是有意無意被忽略,那麼 Scrum Master 也應該用比較婉轉的方式來提醒:
  • 這裡有一個比較重要的 task 還沒做,有沒有誰要認領的?這種說法很類似『這裡有一隻流浪貓/流浪狗快要餓死了,有沒有那位善心人士願意認領回家照顧?』,如此可激起 programmers 的惻隱之心...。使出此招有 60% ~ 70% 以上的機會可以成功將冷門 tasks 推銷出去。
  • 如果第一招不行,那只能用點名的方法(一次點兩位以上)。這個 tasks 『工程師甲』 或是『工程師乙』你們那一位可以幫忙認領?
  • 如果上面兩招都不行,那就只能看看誰今天還沒有 task 或是誰最合適做這個無人認領的 task,然後直接問:『工程師X,你能不能認領這個 task? 』。
  • 如果還是不行,那大家就撐在那裡(開不完的 daily scrum....),看看最後誰受不了跳出來認領。
依 Teddy 印象所及,還有沒動用到第四招的機會。

***

下一位是人客戊關於 GUI Testing 的問題,原本的問題 Teddy 記不得了,大意是說 GUI testing 很容易出錯,是不是應該用類似 unit test 的方式來測試 UI。

Teddy 猜測這位人客應該是有看過 MVP (Model View Presenter) 相關的資料,所以才會問這樣的問題。以 Teddy 本身的經驗:
  • 要把軟體的 UI 都套用 MVP 似乎不是那麼容易,如果只是為了『讓 UI 自動化測試變得很漂亮』而套用 MVP 可能(短期)會讓軟體開發的進度變慢。
  • 如果是開發 Web AP,用類似 Selenium 的工具透過  UI layer 來做自動化功能測試還是有一定的必要性。至少不用管軟體是否套用什麼 patterns,而且只要稍微學一下立即可以上手(說實話,Teddy 自己是沒寫過...都是同事在寫...Teddy 只負責做 monkey testing...)。
***

以上就是 Teddy 想到的兩個問題。最後再補充一點,昨天 Teddy 奉送一篇免費的『敏捷式例外處理』paper,今天突然想到還有一篇和例外處理有關的 paper,『A Scenario-Based Approach for Modeling Abnormal Behaviors of Dependable Software Systems』,在此也提供給鄉民參考。據 Teddy 的指導教授說,這篇 paper 有某位台灣 『國際大嘴巴』公司的『老先生』很喜歡,至於是什麼原因 Teddy 也不知道,閒閒沒事的鄉民參考一下給點意見。

***

友藏內心獨白:明天該不會又想到其他客人問的問題吧...XD

2011年4月18日 星期一

答客問

April 18 21:20~22:35

趁著 Teddy 還記得的時候整理一下上禮拜六 Scrum 經驗分享活動中來賓所問的問題。

人客甲:我有一個新專案是 fixed price 的專案,如果按照 Scrum 的講法,客戶可以一直改需求但是 fixed price 的專案又不能增加費用,這樣可以採用 Scrum 嗎?

Teddy:請問您以前是否有接過類似性質的專案?

人客甲:有。

Teddy:請問以前的案子都有準時結案嗎?客戶都不會更改需求嗎?

人客甲:沒有準時結案過,客戶會修改需求。

Teddy:那你還怕甚麼....XD

***

上面這個算是有點不負責任的回答,不過既然以前的方法已經多次被證明了不 work,那換個新的 Scrum 方法有什麼好怕的?當場 Teddy 沒有給這位人客太多 狡辯 回應的機會,他心裡可能在想,『雖然以前的方法不 work,但是可能只會 delay 個兩個月,萬一改用 Scrum 變成 delay 三個月甚至更久那怎麼辦?

的確,這種情況可能發生。好幾年前 XP 很流行的時候,Teddy 聽過一個故事,台灣某家本土做 ERP 的大公司的某個小團隊,決定採用 XP 來開發某個軟體。因為他們認為 『XP 不需要做 big up-front design,只需要透過 refactoring 來改善 design』,於是他們就真的沒有做什麼 design,導致有一陣子連續花了超過 6 個月的時間在 refactor 他們的軟體。最後這個案子已失敗告終。該公司得到一個結論,就是 XP 不 work。

人客啊,俗話說『不會駛船嫌溪彎』,自己不學好要怪東怪西這樣 Teddy 也沒辦法。Teddy 在『同誰,九陰真經不是這樣子練滴』曾經說過:

就算你是『逆練九陰真經』,好歹練功的內容還是和『九陰真經』相關連,總不能說當年郭靖給歐陽峰一本『瑜伽大全』或是『第一次學有氧舞蹈就上手』然後騙他說這是『九陰真經』,這樣就『騙太大了』。

那有採用 XP 的團隊會連續 6 個月以上都在做 refactoring 的,這樣就是在練『瑜伽』而不是在練『九陰真經』了,別搞錯方向了。

回到原本的問題上面,如果怕自己 Scrum 不熟,那麼至少有兩個方法可以解決:
  • 花錢:找顧問來協助導入,這樣最快而且比較保險。但是,千萬,千萬記住,不要找錯顧問啊,否則是會...祝恐怖..滴...。花錢又不能消災,到時候又要怪 Scrum 不好。如果不知道要找誰,請看『工商服務 』,服務範圍應該有包含海峽兩岸
  • 自己慢慢試:這個方法風險就比較高了,首先,在公司內部找到一個類似 Teddy 這樣的人來擔任 Scrum Master 幫忙導入。可以先送這個人去上課(2 天搞定),然後從『殺傷力最小』的地方開始導入 Scrum。例如,可以先改善工作環境,把辦公室隔間先拆掉,幫 developers 換大桌子,大螢幕,好電腦,並且多準備一些測試環境。接著,試著將需求改用 story 的方式來表達,如果客戶無法接受,那麼這個 story 就變成開發者自己看的資料就好,不需要告訴客戶。再下來就可以開始 sprint planning meeting, daily scrum, sprint demo meeting, and retrospective meeting。如果一開始無法立即上手,可以試著採用 iteration 0。.... 等等...再寫下去可以寫一本書了,下面就自由發揮。
總之,Teddy 的經驗是,只要找對 Scrum Master,事情應該就成功一半了。至於採用 Scrum 的效果,就要看公司文化,長官的支持程度,每個團隊成員的能力與配合度,這是需要時間來證明的。

***

人客乙是一位年輕小伙子,問了 Teddy 好幾個問題,試圖將 350 元報名費發揮到極致,不過 Teddy 只記得其中兩個問題。

人客乙:請問如果到專案快結束的時候,客戶改了一個需求影響到整個軟體架構,需要大改,那該怎麼辦?

Teddy:請問每個 sprint demo 的時候客戶都在做什麼?如果 sprint demo 客戶都有參加,『理論上』你講的這個問題發生的機率應該是很低的。這樣的問題在採用 waterfall 的專案倒是很常見。不管如何,萬一真的發生,你也只好認了啊。不過,至少你可以說『每個 sprint demo 的過程你都有參與,現在你要做這麼大的改變,是不是應該要重新談專案合約』。雖然客戶並不一定會買單,但是只要有點人性的客戶應該多多少少有點商量的餘地。

***

當人客乙問了下一個問題之後 Teddy 就知道他一定沒有看過(或是沒有專心看)搞笑談軟工,問題如下。

人客乙:Use case 裡面有所謂的 main success path 以及 extension 或是 exceptional path。通常我們會把 main success path 寫成 story,那麼 extension 與 exceptional path 要怎麼辦?

Teddy:嘿,嘿,嘿,你沒看過搞笑談軟工對不對? 嗯嗯...總之這個問題說來話長,請參考 Teddy 部落格的『exception handling』分類文章,至少要把『敏捷式例外處理設計的第一步:決定例外處理等級』與『用 Robustness stories 評估 SyncFree 有多強壯』看完。

最後再奉送一篇免費的 paper『敏捷式例外處理』,如果這樣還不了,那就要付費請 Teddy 一對一教學了... XD

 ***

還有一位人客問到:如果團隊有 50 - 60 人那怎麼辦?Teddy 回答那要用 Scrum of Scrum... 不過很可惜,Teddy 的團隊人數遠遠遠小於這個數目(Teddy 內心獨白:我也很想有 50-60 個人可以帶啊),所以沒辦法分享任何具體的經驗。
 
ㄟ,年紀大了,只記得這四個問題,下次還有機會的話,Teddy 要記得把人客的問題記下來。

 ***

友藏內心獨白:其實 Teddy 的博速論文就是研究 exception handling 滴...



2011年4月17日 星期日

工商服務

April 17 11:58~12:45

昨天的『Scrum 經驗分享』活動結束後和 MaoYang 與郁琇又聊了一會,很佩服他們創業的精神與勇氣。想當年 Teddy 也是經常陪著業務到處去 demo 公司產品,分析使用者需求,以及陪著老闆到處去找資金(薪水快發不出去了...XD),所以深深體會到在台灣要經營一家『純』軟體公司是很不簡單的。

以前曾經聽到一個江湖上的傳言,在台灣開軟體公司要能夠賺錢,只有倒閉才能賺錢。什麼意思?因為軟體後續的『維護問題』很多(可能是軟體品質不良,也可能是需求變更還有一些奇奇怪怪的問題),光是處理維護的問題就吃掉公司開發人員絕大多數的時間。所以,案子錢收到了,公司也倒閉了,省去維護的成本,這樣才能賺到一點點錢。這...和詐騙集團有什麼不同...

***

在答應 MaoYang 出席這個活動之後,才發現 MaoYang 也是北工的校友。MaoYang 告訴 Teddy 說,他之前一直以為 Teddy 是『中央資工』畢業的...錯,錯,錯,在此 Teddy 要大聲宣告:Teddy 是 台北科技大學資工系 畢業滴(是在忠孝東路三段光華商場附近那一間北科大,不是基隆路那一家台科大,不要搞錯了喔)。順便幫 Teddy 所屬的實驗室打個廣告:軟體系統實驗室,鄉民們如果要找好的軟工人才,看到北科大資工系軟體系統實驗室畢業的,直接錄取就對了,不用想太多。

在聊天的過程中,MaoYang 提到有些公司對 Scrum 有興趣,但卻不知該如何導入。有些公司是基層的開發人員想用 Scrum,但是老闆想的卻是要拿到 CMMI 的牌子。接下來是本篇工商服務的主題,因為 Teddy 的指導教授去年拿到一個經濟部技術處三年的案子,要輔導台灣的廠商導入 Scrum,Teddy 利用這個機會順便幫忙打個廣告,有興趣的人可以參考 ezScrum 這個網站上面的資料。以下是節錄自網站上的說明:

導入Scrum與最佳實務計畫由經濟部技術處支持,主要以輔導案的方式協助業界導入 Scrum與最佳實務(尤其針對 ICT/CE 資通訊/消費性電子產業的軟體開發),並且開發軟體工具(ezScrum)降低業界使用成本、提高導入達成率。另外,本計畫也希望將整套導入流程發展成熟後,完整地技轉給輔導廠商,以達成本計畫協助、促進產業軟體技術精進、活絡的初衷。

就 Teddy 所知道,該計畫除了導入 Scrum 方法之外,也包含導入 TDD (test driven development),CI (continuous integration),CM (configuration management),software testing,exception handling 等 practices,還有如何採用 Scrum 來滿足 CMMI Level 2/3 的要求。如果想要找人到公司去介紹 Scrum 也是可以滴(不要找 Teddy,因為 Teddy 還要上班啊...除非演講費高到值得請假去參加....XD)。

各項子計畫的負責人都是很有經驗的教授(因為 Teddy 都認識...XD),實施方法絕對不是上上課隨便唬爛一下就結束了。不過,Teddy 要先說明一下,這些導入活動是要付費的,如果口袋空空的鄉民們就請看看免費的『搞笑談軟工』就好了,不要想太多。

最後補充一點,這整套導入的方法是可以技轉給軟體(顧問)公司,讓有興趣經營軟體顧問服務的公司們可以持續耕耘下去。

***

題外話,昨天的活動還真的有幾位是 Teddy 部落格的粉絲,著實讓 Teddy 小小地感動了一下下...

***

友藏內心獨白:Scrum 除了沒有牌以外,絕對比 CxxI 便宜又有效。

2011年4月16日 星期六

Scrum 經驗分享投影片

April 16 22:22~21:36

今天下午到 MaoYang 舉辦的『Scrum 經驗分享』活動中擔任講者,這是 Teddy 第一次和 MaoYang 見面,也是第一次參加『網路揪團』活動...XD。台灣軟體業有這種熱心辦活動的人實在是應該多給點鼓勵。類似分享軟體開發經驗或軟體工具使用經驗的活動 MaoYang 已經辦過幾次,聽 MaoYang 說之前有幾次活動是不收費的,但是造成有些報名的人沒有來參加,對於主辦單位而言場地不好控制。說真的,類似的活動收 350 元真的是聽到賺到,大概只能勉強 cover 工本費而已。主辦單位用心找好的講師,就當作看場電影付點門票費用也是值得滴。

有人可能會認為說 MaoYang 想要推廣他自己公司的軟體,不過 Teddy 覺的這也無可厚非,整個活動的商業氣息其實很低,如果沒有興趣的人就當作在路邊拿到一份 DM,也沒有人會纏著你推銷東西 。

接下來是 Teddy 的自我檢討。整個活動最失敗的地方就是 Teddy 話太多了,原本活動是 14:00~16:00,結果搞到快 17:00 才結束。以往 Teddy 演講時間都控制的還不錯,這次難得遇到那麼多都是業界的聽眾,話匣子一開一下子就忘了時間。另外一點要改善的地方,就是 Teddy 跟實驗室要了 6 份 Scrum Poker 數目太少了,應該多 A 一點,這種獎品還滿熱門的。

由於聽眾的背景不同,可能會有人覺的 Teddy 講得太簡單或是太抽象,也可能有人覺的跳太快,有些細節沒講。所以這種分享的活動,也許應該把題目定『小一點』,例如,sprint planning meeting 經驗分享(光這個就可以講一小時吧),或是 continuous integration 經驗分享等等,因為光是講『Scrum 經驗分享』有點太包山包海了。



Teddy 說要把演講的投影片放到部落格上面...剛剛才發現,google 的部落格根本沒有上載檔案的功能啊...好里加在還有以前實驗室的網頁可以使用,需要的人可以從這邊下載:投影片

***
友藏內心獨白:話太多也是很累滴。

2011年4月13日 星期三

時間到

April 13 21:08~22:19

相信鄉民們一定有那種和別人約好要見面,可是卻苦等不到對方的經驗。如果是男女朋友約會,通常是男方比較早到,女方遲到個 30 分鐘算是正常,遲到 1 - 2 個小時也不算太超過。在熱戀中的男方,心目中的 timeout 可能是 > N 小時,但是一旦 騙到手 結婚之後,timeout 時間可能會被調整成 < 5 分鐘,真是太現實了。

不管如何,具有 timeout 的觀念是很重要的,真實世界沒有什麼『不見不散』,『等你一生一世』的那種事,像『王寶釧』這種把 timeout 設成『18 年』以上的人,已經算是瀕臨絕種的稀有寶物了。

***

Timeout 對於 programmers 而言也是很重要的觀念,之前 Teddy 在『還少一本書:Release It! Design and Deploy Production-Ready Software 』有稍微介紹一下書中 Use Timeouts 這個 stability pattern。今天 Teddy 解了一個 bug,剛好也是和 timeout 有關,順便再幫鄉民們複習一下。

這個 bug 和使用 Java 建立 socket 有關,假設你在寫網路應用程式,有下列幾個步驟:
  1. client 建立一個 socket 連到 server。
  2. client 透過 socket 得到一個 output stream,利用這個 output stream 送出 request。
  3. client 透過 socket 得到一個 input stream,利用這個 input stream 讀取 server 傳回來的 response。
以上為一個很典型的網路應用,由於 Teddy 有看過 Release It 這本書,知道開發網路應用程式要套用 Timeouts 這個 pattern。經過分析,上述第 3 個步驟可能會因為 server 很忙以至於過了很久都沒有把結果傳回來,導致 client 『卡住』,很容易讓使用者以為程式當掉,所以這邊就要利用到 timeout 機制。還好 Java 都有幫鄉民們考慮到這個問題,Socket 物件有一個 setSoTimeout method ,看一下 JavaDoc 的說明:

setSoTimeout

public void setSoTimeout(int timeout)
                  throws SocketException
Enable/disable SO_TIMEOUT with the specified timeout, in milliseconds. With this option set to a non-zero timeout, a read() call on the InputStream associated with this Socket will block for only this amount of time. If the timeout expires, a java.net.SocketTimeoutException is raised, though the Socket is still valid. The option must be enabled prior to entering the blocking operation to have effect. The timeout must be > 0. A timeout of zero is interpreted as an infinite timeout.
Parameters:
timeout - the specified timeout, in milliseconds.
以上 JavaDoc 說明已經很清楚了,但是,只有 read 會卡住嗎?Teddy 今天遇到的問題就是卡在個步驟 1。Teddy 用一個簡單一點的例子來說明,假設你的程式 ping 某個 IP address,在正常的情況下,很快就會有回應,如下圖所示。




如果 ping 一個沒人使用的 IP address,應該會出現如下的結果,也是很快就會有回應


但是,如果隨便 ping 一個 IP address,整個程式就會卡住,如下圖所示。


如果你的程式是呼叫 public Socket (InetAddress address, int port) 來建立 socket,那麼就可能在個步驟 1 卡住。看一下這個 constractor 的 JavaDoc:

public Socket(InetAddress address,
              int port) throws IOException

Creates a stream socket and connects it to the specified port number at the specified IP address. If the application has specified a socket factory, that factory's createSocketImpl method is called to create the actual socket implementation. Otherwise a "plain" socket is created.

使用這個 constractor 當 Socket 物件被建立的時候,同時也 connect 到遠端。仔細看一下 Socket 物件所提供的 9 個 constractor,沒有一個可以指定 timeout 的,所以程式要改成下面這樣。

  1. 使用這個 Socket() 不帶參數的 constractor,根據 JavaDoc 的說明這個 constractor『Creates an unconnected socket』。
  2. 使用 connect (SocketAddress endpoint, int timeout) 來建立連線,根據 JavaDoc 的說明『Connects this socket to the server with a specified timeout value. A timeout of zero is interpreted as an infinite timeout. The connection will then block until established or an error occurs. 』。
故事就這麼簡單,程式改完之後建立連線時就不會一直卡住了。由於 connect (SocketAddress endpoint, int timeout) 是在 JDK 1.4 版之後才出現的,所以鄉民們到網路上亂找範例的時候,可能找到類似呼叫 Socket(InetAddress address, int port) 這樣的範例(產生 Socket 物件並建立連線)就給它直接抄過來用,所以這類的程式碼(建立 connection 時沒有指定 timeout)其實還滿常見的。

***

如果講到這裡就結束那就遜掉了,還有一個重點是這種 bug 其實不太好找,為什麼?因為同樣的 code 在 Windows 上面並不會有問題,而在 Linux 上面卻會。不要傻傻以為 Java 是跨平台,Java 底層很多程式還是呼叫 native code,網路程式就是一個例子,所以有一些行為還是跟作業系統相關的。總之,跟著 Teddy 大聲念三遍:

寫網路應用程式的時候要記得 Use Timeouts 。


***

友藏內心獨白:如果要害一個人,就送他一張不限航點的飛機艙位升等券...這一句有緣人才看得懂...XD

2011年4月4日 星期一

什麼是軟體工程 (2)

April 04 20:19~21:52

Teddy 之前寫過一篇『什麼是軟體工程』的文章,內容純屬搗蛋,沒人記得也就算了。今天因為在準備一個演講的投影片,不禁又讓 Teddy 想起了這個問題:『什麼是軟體工程』?

說來慚愧,本部落格名為『搞笑談軟工』,事實上 Teddy 從來沒有修過『軟體工程』這門課。因為 Teddy 想修的時候系上沒開,等系上開了課 Teddy 學分已經全部修完了,也就偷懶沒去聽。不過,好學不倦的 Teddy 還是自己買了三本軟體工程的書來自修。先介紹一下這三本書,再來看看這些教科書都在講些什麼。

  • Software Engineering: Principles and Practice, 2/e, 2000. 約 700 頁。
  • Object-Oriented Software Engineering: Using UML, Patterns, and Java, 2/e, 2004. 約 750 頁。
  • Software Engineering: A Practitioner's Approach, 6/e, 2005. 約 900 頁。
不比不知道,比了嚇一跳,怎麼講的內容還真是類似啊,可見 Teddy 白花了不少錢 這些寫教科書的作者們對於軟體工程的範疇有大致的共識。基本上,這些書都包含了以下內容:
  • Software Process:介紹 process models, 包含 waterfall, spiral model, agile methods 等,這一部份佔了  5% 左右。
  • Software Engineering Practice/The Software Life Cycle:這個分類佔了書本內容約 40%,主要就是講軟體開發所包含的需求分析,系統分析,系統設計,軟體架構,軟體元件,使用者介面設計,軟體測試。有點類似 OOAD 裡面所教的內容,只不過稍微抽象一點。
  • Managing Software Project/ Managing Change:這一部份內容份量也滿重的,佔了 35%~40% 左右。包含了建構管理,專案管理,人員和團隊管理,品質管理,風險管理,成本預估等。
  • Advanced Topics:包含了 正規方法,reengineering,software reusability,software reliability 等,內容約佔 10%~15% 。(Teddy 內心獨白:舉凡教科書中的 advanced topics 內容,內行的人都知道,這是永遠都不會教到的章節)
在這三本書中,第三本因為比較新(這本書是 2005 年初版的,Teddy 是 2005 年 11 月買的,所以從當年的角度來看算是新書了),而且頁數比前兩本多了 150-200 頁,所以多了一個新的內容:
  • Applying Web Engineering:介紹 Web Engineering,如何開始一個 WebApp 專案,如何分析,設計與測試 WebApps。
看到這邊,鄉民們應該多多少少了解到這個軟體工程長得到底是圓還是扁的。說真的,平常軟工,軟工一直講,經過這次『盤點』之後對軟工的印象又更具體了一點。

***

但是,故事並未到此結束。話說因為放假 Teddy 閒閒在家突然想起有一陣子沒去天瓏書局了,加上今天下雨去書局的人應該不多,可以悠閒地慢慢挑書,所以下午四點多的時候去了一趟天瓏書局(PS:事實上一點都不悠閒,因為有人不停地在書店門口騎樓抽煙,而煙味順著風吹入店內,失敗!這是 Teddy 越來越少去天瓏的主要原因)。原本是鎖定要買幾本和 agile 有關的書,因為現場人太少了 Teddy 時間又多,看著看著不小心看到了『Software Engineering』這個分類(Teddy 內心獨白:其實是為了躲避門口的煙味而越跑越往裡面...XD),又不小心看到了一本 2011 年出的新書,於是 Teddy 的書櫃又多了一本軟體工程的書:Software Engineering, 9/e by Ian Sommerville, 2011. 約 770 頁。

照理講 Teddy 都畢業 2 年多了應該不需要買這種教科書了,而且這本書的內容有 70% 和之前這三本都重複了,但是這本書有九章新的內容吸引了 Teddy。
  • Part 2 Dependability and Security
    • Chap 10: Sociotechnical systems
    • Chap 11 Dependability and security
    • Chap 12 Dependability and security sepecification
    • Chap 13 Dependability engineering
    • Chap 14 Security engineering
    • Chap 15 Dependability and security assurance
  • Part 3 Advanced Software Engineering
    • Chap 19 Service-oriented architecture
    • Chap 20 Embedded software
    • Chap 21 Aspect-oriented software engineering
記得在唸書的時候讀過 IEEE Transactions on Dependable and Secure Computing 的幾篇 papers,沒想到才沒過幾年 Dependability and Security 已經變成軟體工程教科書的內容了;還有包括 SOA,Embedded 和 AOP 也都被放到軟工教科書中。這也代表這些領域在軟體工程中越來越被重視。

***

其實買教科書有很多好處:
  • 高  CP 值:和『流行書』(例如 Agile methods,手機程式開發)相比,這些教科書算是大碗又便宜。隨隨便便一本 700-800 頁才賣你 1000 台幣出頭。像 Teddy 今天買了另外一本書 Managing Software Debt 才 240 頁就要 1440 ... 心還是挺痛滴...
  • 幫你省時間:這些教科書的內容很多都是從學術論文中整理出來的,如果要你自己去看,光是把這幾百篇的論文... 找出來... 都還不用看喔,就夠你嗆的了。
  • 快速了解地形地物:如果對於某個領域不熟,最快的方法之一...就是去找一本該領域的教科書來看這樣就可以很快的了解該領域的基本常識。
***

講了這麼多,大概也沒幾個人記的起來。總之,把握以下幾個重點:
  1. 軟體不是軟的。事實上,軟體很硬
  2. 軟體工程的目的:
    • 讓你可以把軟體做出來
    • 讓你的軟體變軟
    • 讓你在可接受的成本範圍內達成上述兩件事
講完收工。

***

友藏內心獨白:怎麼在兒童節寫了這麼『兒童不宜』的文章...XD