工作已滿二個禮拜,雖說工作還算順利(應該吧XD),但回到家依舊在看書充實過去沒接觸過的東西,沒太多餘的時間能拿來開發Comic Surfer。不過看書還是不錯的,像是最近在看的《Patterns of Enterprise Application Architecture》就非常的好(下圖),解開我過去在思考如何改善ezCMS (Easy Conference Management System,實驗室開發的研討會管理系統)的許多問題,事實上,我很多的想法也在這書中得到證實,只是我當時不知道我的想法原來已經是一種pattern了。

  在有限時間裡,還是打算抽出一絲絲的時間(看每天是否能抽出1小時),把Comic Surfer 2.1的半成品變成完成品。由於2.1版支援外掛,所以自己也寫了一個外掛去讀取某知名漫畫網站上的漫畫,惡夢也就此開始,該網站程式似乎有固定的更新頻率(防止盜連?),每次程式一更新,外掛程式也得一併更新,但也因為這樣發現了一個Comic Surfer目前的缺點:程式雖然不會因為例外而當掉(Crash),而且能保持繼續運作,但卻沒有讓使用者知道發生什麼事了。再加上公司的What's New會議上,我想拿Comic Surfer當例子說明Domain model的設計(還不一定真的用這主題),用更高的層次看自己的程式後(看書也幫助自己提升層次),覺得某些物件的耦合(Coupling)還能再打掉,有助於單元測試的進行。所以2.1 M3的規劃如下:

  1. 降低Core套件中,物件間的耦合:用Observer pattern拆散某些直接耦合的物件,變成間接耦合,提升測試的方便性(只需要製造Mock subject即可)。
  2. 增加錯誤訊息的處理:目前程式的強健性(Robustness)還算是不錯,在例外拋出後大多能維持在可繼續運作的狀態,但在使用者體驗的部分要加強一下。
  3. 提高測試涵蓋率到40%以上:過去測試涵蓋率曾經一度到45%,但Refactoring後,部分測試被移除掉,涵蓋率降到31%,希望在降底耦合後,把測試補回去,然後看有沒有機會將涵蓋率提升到40%以上。
  4. Slideshow (幻燈片播放):Java的全螢幕API我已經試玩過了,而且從J2SE 4就開始有支援(當然,此API和Android的全螢幕API不相容),原則上會有幻燈片播放功能,但我還在考慮用視窗模式做幻燈片播放,還是用全螢幕做幻燈片播放?

  別看只規劃了四項,如果每天只有一小時(最好的情況),這四項也要讓我花上十幾天才弄得完了,至於會不會像標題所說的遙遙無期?我也不知道,目前Comic Surfer在bitbucket上的Git Repository已經有些人拿到權限能夠取得原始碼,但我也不知道什麼時候開始能多人協同開發XD

dbi1463 發表在 痞客邦 PIXNET 留言(0) 人氣()