Spirit的異想世界

　　昨天和公司的高層(含最高層，我是裡面最菜的)開會，因為目前專案的進度可以說是delay了非常非常之久，我進到這個專案時，這專案就已經是delay的狀態了(據說已經跑了快2年)，所以我要說明為什麼開發時程會這麼長的理由，以及剩下的功能能在什麼時候完成。說起來有趣，我會和目前公司結緣，是參加了北科ezScrum團隊每個月舉辦的C. C. Agile。進公司快半年，雖然PM認為團隊開始進入狀況，我也認為團隊氣氛變好，但我不敢說我貢獻了什麼？我只盡力保住由團隊成員估時程的機會，而不是上面說了一個時程然後就是那樣；再來就是讓團隊成員有更多機會學更多東西，試著讓整體的開發速度變快；在code review時，盡量提供意見及分享自己寫的程式。雖然我試著東加一些西加一些，但其餘的agile practice，我目前還幫不上忙，因為這不是一個agile team。
　　其實是不是agile team我並沒有這麼在意，因為我自己本身沒有任何流派(unified proecess、scrum或waterfall之類)的信仰，只是我印象中曾經看過一句話，scrum master應該是保護羊群的牧羊犬，我還在努力中。不過，下個禮拜五，我還是(很無奈地)得交出一份類似計畫書的東西，上面會有一個時程：剩下12個功能(長期目標)完成的時程，而且是根據某個公式算出來的(現在電腦不只會選土豆，還會算時程)，這讓我想起之前看過一篇吃蘋果的文章，如果開發軟體能像吃蘋果那樣，每個人速度都差不多(事實上也不可能一樣)，那或許我調整一下公式裡的參數，多留一點buffer，團隊就會很高興，但那對團隊的進步沒什麼幫助，我之所以想保住讓團隊估時程的機會，是希望當團隊進步後，不斷地修正短期目標的時程，當短期目標不斷地減少，離最後的目標也就不遠了(好啦~其實我是想偷偷把scrum塞進團隊裡)。
　　昨天的會議，直屬主管、架構師和處長都幫團隊近況說了不少好話，不過，有些決定還是定下來了，包含今天我宣導的一件事(暫且就稱作是A吧)，沒想到剛宣導完，就引起一點不小的抱怨(我自己也...)，但離開公司前，我還是做了A才回家(以身作則)。結果，晚上收信，看到一封過去某人做A做了一陣子覺得A很好的信，那封信就像是傳教士在宣導『信耶穌得永生』。我認為A不是壞事，但就跟讀書方法一樣，某個人B很會念書考試成績很好，但B的讀書方法不見得適用於另外一人C，也許可以好心讓C試試看B的讀書方法，但不該是強迫C用B的讀書方法，因為有時候反而會有反效果。事實上，我自己的讀書方法是自己求學過程中一路摸索出來的，如果真要說，我的讀書方法肯定不適合很多人，因為我幾乎上課都不太聽課(我連自己指導教授的課有時候都會打瞌睡了)，也不太作筆記，完全是依照自己的步調在念書。

　　今天中午把其中一個功能給完成了，那個功能當初用IBM的公式計算需要24人時的時間，差不多就是三天多到四天(人一天工作是不可能滿8小時的)，不過我自己的time log顯示，2天搞定了，主要是因為這功能在我比較不熟的前台只有查詢，沒有任何編輯的動作，相對簡單很多，而本來就比較熟悉的後台在前開發一個功能時，留了很多可以重複使用的東西，所以省下一些時間可以拿來準備課程的投影片。下午開始忙下一個功能，老實說這個功能是我估算最麻煩的一個，因為它橫跨了好幾個畫面和動作，更有趣的是，幾乎所有的功能都有規格書，唯獨這個功能沒有，因為PM也不知道要怎麼做？
　　為此，不久前曾開了一個需求會議，我跟架構師、PM和大PM一起討論過，但其實還是留了一些未知數，所以下午又去找架構師討論，該怎麼處理這種跨好幾個模組、畫面的東西，最後還是決定用Spring framework去攔截action後再來處理(AOP)，定案後開始一邊看Spring framework的書一邊寫code (別懷疑，我本身不是那麼喜歡AOP的programming style，所以過去都不太碰它)，本來程式放在A專案，因為dependency和visibility的問題，後來又把程式改放到B專案，花了大概2小時把攔截action需要的程式搞定(ㄟ...這只是這個功能的其中一個步驟而已)，告一段落後找架構師code review，很好，沒什麼大問題，明天可以繼續往下做了。
　　回到自己的座位，隔壁的同事跟我說有個會議在C室，哈~我忘記今天有Team leader會議了，趕緊匆匆忙忙趕過去，一進去就看到投影片打著XX銀行的YY系統規格書，似乎是某位剛當team leader的同事在和主管討論規格書及開發手冊的撰寫吧！嗯~我自己是不寫那種東西的，等等，剛剛我不是才說某個功能沒有規格書嗎？那自己如果要負責一個新project卻不寫規格？其實平常我也不太看規格，現在寫程式都是根據prototype一邊操作一邊把功能實作出來，規格書只是在我測試時參考用的，就如同主管說的，當規格書越寫越多，之後程式跟規格書的差異維護就越痛苦，如果程式寫的易讀好懂，看程式有時候會比看規格書快(ok，真的只是有時候，畢竟我看到現在，讓我驚嘆的好程式不多)，我自己也是靠看程式摸索目前系統的架構，不過這方法不見得適合資淺的工程師，所以開發手冊還是要有，規格書...我倒不那麼在意，只要能溝通清楚就好。但是...凡事都有一個但是，那些規格舒是XX銀行要求的，難怪有一堆奇奇怪怪看不懂的縮寫，他們真的很愛縮寫耶！因為這樣...就只好寫給他們啦~

　　說來慚愧，和現在Comic Surfer Core的98%涵蓋率(Statement & branch coverage)相比，進公司到現在，我目前在寫的程式，搭配有單元測試的不多，主要有幾個原因，第一是Comic Surfer共121個測試案例，全部執行完畢平均不到2秒，這是讓我寫單元測試的動力，當一個測試要跑超過10秒，除非是超大系統的整合測試，我實在不想跑，也就自然不想寫了，現在光是一個小小的converter要測試，都要靠Spring framework注入一堆web services，10秒能啟動完整的環境就算是幸運了，即使那個method的測試案例可能不到0.1秒，但整體來說一個測試案例要跑10秒，啟動環境的時間是執行測試時間的100倍？光想就覺得煩...
　　第二是如果不想靠Spring framework注入web services，那就寫mock的web services然後再用setter注入吧！事實上Spring framework也用類似的機制注入所需要的物件，但問題來了，以最近寫的converter為例，需要三個web services，也就是說我要一次mock三個web services，會用到這麼多web services是因為我們不直接跟DB溝通，都是透過web services，當初表格正規化的很徹底，而一張表格通常就對應了一個web service，在這樣的情況下，為了取得必要的資料，一個簡單的功能可能就需要多個web services，mock一個我還考慮考慮，mock二個我勉強勉強，mock三個我放棄，特別是公司用的mock framework，寫出來的mock不太能重複使用，我就不想寫mock了，最後還是透過Spring framework注入真的web service算了。
　　第三是DAO的測試有點討厭，而且很難省時間，都是需要操作真正的DB，即便可以用In memory DB加快從硬碟讀取資料的速度，但Hibernate還是要靠Spring framework注入，因為transaction是由Spring framework來管，DB已經慢了，再加上Spring framework，唉...所以，另外一個同事以及架構師都說，測試都是丟到Jenkins上離線的時候跑，若當成regression test這idea很好，每天跑時時跑(我每天都會收到一堆Jenkins的報告)，但單元測試的重點不就是快速反應錯誤然後快速修改嗎？目前Jenkins建置加上跑完所有測試案例超過半小時，我如果只是改一個小小地方，在Tomcat沒關掉，Eclipse plug-in會自動將程式更新到server的情況下，我還是寧願透過UI測試。

　　幾天前一位同事被指派了一個任務，幫新進業務上機算機概論課程，我當時想還好我不用去當講師，結果高興不到一天，我就收到信了，因為一個人要上八節課實在太多了，所以我也被安排去分攤其中三堂課，什麼！我上禮拜五的planning meeting和另外一位同事已經跟大PM拍胸脯保證1/25會完成這個sprint的所有功能，時間是我跟另外一位同事估量後我們自己壓的，不是大PM壓的，但這已經是抓很緊的case了，手頭上還有1x張JIRA單要解，這突然其然的授課，勢必又要壓縮我的開發時間。
　　雖然主管說聽課的是業務，不用上太難，但總不能隨便上上吧！幾年下來準備group meeting的習慣，要給一個talk，投影片加上準備都至少要一天，後來又一封mail來了，附上的是某校某教授上機算機概論的投影片，老實說這沒什麼幫助，不是自己做的投影片，怎麼講怎麼不順，對我來說，我反而要多花點時間準備，省的只有做投影片的時間...
　　今天收到課表，其中有兩堂課安排在四點到六點半，這...表定上班時間不是早上八點半到下午五點半嗎？我可是都很準時地早上八點半就到，如果問題沒處理好，我都會繼續弄完，盡量在六點前下班，都已經晚半小時了，又要再晚半小時？這讓我想起以前赫哲補習班有位年輕的老師，上課速度超快(還是講得很清楚，少講點笑話)，然後通常都會提早半小時下課，學生也很樂，也許，我也來這招好了，我想那些上課的業務應該也會很樂！

　　自從有了AJAX技術開始，越來越多網站都使用AJAX技術開發，好像沒用Asynchronous (或是event-driven)的方式寫程式就很落伍了，就連最新的WinRT API都加了一大堆Asynchronous API，但我常常看到一堆網站，在點下某個按鈕後，整個畫面變成灰色的，然後有個輪子轉啊轉的，轉個半天什麼事也不能做，這其實跟傳統的Synchronous網頁沒什麼差別啊！只差在有個輪子轉啊轉，讓使用者誤以為server還在(其實早就死了)，比較好的方式應該是只Block需要同步的部分，不需要同步的部分應該還是要讓使用者操作吧！GMail在load信件時會把整個頁面block住嗎？不會吧！不然不就失去Asynchronous的好處了嗎？
　　自己寫程式倒是很少用Asynchronous方式開發程式，主要的原因跟這篇學長的文章相似：難測！Comic Surfer一直到2.0才有會轉動的輪子，不過，我的設計只封鎖Navigation的事件，其餘動作功能依然能夠使用，ㄟ...這不是重點，有點離題了，2.0核心沒有加任何Asynchronous method，但多了multi-thread，搭配polling的UI，所有會耗比較多時間的動作(載入大張圖片)和要平行處理的事情(快取其他頁面)都是用獨立的thread處理，這些功能原本都是Synchronous method，所以測試上就和傳統的測試一樣：呼叫method，當程式return檢查結果和物件狀態。至於不同thread之間怎麼同步，例如什麼時候該轉圈圈？什麼時候要把畫面上的圈圈拿掉？看情況，有時候用lock，有時候就跟Swing的event dispatch thread機制一樣，送event給等待的thread。
　　其實Synchronous和Asynchronous之間的差異沒有像一個是天和一個是地那麼大，把Synchronous method丟到一個獨立的thread執行加上call back method就可以包裝成Asynchronous method，Asynchronous method加上一個busy waiting lock、time out和exception機制就可以包裝成一個在失敗時(time out)會拋出例外的Synchronous method，開發程式時，我個人還是喜歡先寫Synchronous版本，真的有必要，才用thread轉成Asynchronous方式，畢竟測試時，還是Synchronous比較好測！

　　最近在修改Comic Surfer的Preferences模組，由於需要大量的字串(String)和各種形態(Integer, Double, Color, etc.)之間的轉換，寫著寫著，有個地方一直有問題，後來發現了一個有趣的地方，所以放了一段程式碼，裡面有10個問題，請猜猜看每題的Type應該是Integer還是Double？(點圖會放大，請別先偷看答案XD)
     

　　我不確定這是bug還是規格就是如此定義(Java執行環境：J2SE 7 Update 6)，不過如果用上if shortcut表示法，Java似乎只會使用其中一種Type表示冒號的左右兩側的物件，以例子的第九和第十題來看，以能表示範圍最大的Type為主，也就是Double，但如果是正常的if else就不會，所以如果你的程式對Type很敏感，還是盡量別用if shortcut表示法(雖然我蠻喜歡用的，省空間)。

　　這又是一篇源自於學長在其『搞笑談軟工』部落格上的關於Design for testability問題，同樣這也引起網友的討論，但總覺得偏向於『對測試程式的修改』或是『使用第三方套件存取私有變數』，而不是修改程式讓程式變好測(Design for testability)，所以就野人獻曝，提供一個我覺得比較合適的解法。問題中的WidgetFactoryV2類別同時肩負了Simple Factory和Singleton的責任，前者負責針對Windows平台和Motif平台提供不同的factory instance；後者則讓factory在一個JVM只有一個instance。這樣的設計會讓測試不好測試，就如同問題中提到的，但事實上，這問題和Singleton是無關的，更貼切地說應該是『如何測試由平台引起的Simple Factory』，所以我將WidgetFactoryV2改成如圖1的SimpleWidgetFactory，只負責平台相依的問題，Singleton不再是它的責任，此外，我也將『平台』的資訊從程式內部直接呼叫System.getProperty()的方式，換成從參數傳入，如此一來，針對SimpleWidgetFactory就變得很容易測，如圖2所示。

　　今天的內容源自於一個學長於Facebook上問的問題：『你的軟體即將於這個sprint結束之後就要準備送給測試部門進行測試，但是軟體還有幾十個open issues (bugs)還沒解完，而其中大部份的issues都只有某一位programmer可解。請問假設你是Scrum Master，你將如何處置？』這問題一出，引來許多人的討論，也有人開玩笑地說在解決完issue後要把那一位唯一能解的programmer開除，因為他程式寫得不好，所以別人才看不懂無法解決問題，真的是這樣嗎？有時候程式看不懂，並不是因為程式寫得不好，而是領域差太遠。如果整個專案都在同一個領域中，大家都是該領域的programmer，還出現這樣的情形，或許那位programmer真的要稍微檢討一下，但如果一個跨領域的專案，而且跨得很遠，如果沒有另外一個領域的知識，寫程式都很難寫了，更別說要解bug了。
　　另外，bugs明明是學長放在括號內的補充說明，大家似乎都把open issues跟bugs畫上等號，但有時候open issues不見得是bugs，例如有一個車牌辨識的模組，由團隊中唯一一個影像處理專才A開發，大多數的情況下都能辨識出車牌號碼，但前一個sprint結束後，QA實測後發現當在黃昏接近晚上時，辨識率就很差，甚至比晚上還差，因此QA列出一個issue希望能夠改善辨識率，這是一個issue但不是bug (目前沒有100%辨識率的影像處理技術)，問題來了，車牌辨識的過程中，有許多參數可以調整，調整了x參數可能可以提高黃昏時的辨識率，但也降低了白天的辨識率，或者是這個演算法本身就是有在白天到夜晚這之間昏暗不明時辨識率下降的問題，但其他時間辨識率很高，要解決這個issue，沒有影像處理相關知識，短時間內要解決基本上不可能，最後還是交給A來處理。
　　雖然大多數Scrum的書都說，當一個Scrum team要組成時，成員的能力必須涵蓋開發整個專案所需要的各種知識，現實狀況中，如果專案沒有跨很大的領域，這可能容易達成，例如幫銀行開發某個行銷活動的配合系統，那大概就是由具database / network / security能力的programmers，加上有處理過金融系統經驗的programmer，這樣的團隊就組成了。不過話說回來，會用database的programmer好找，懂得最佳化database的programmer就不見得好找；直接用network API寫程式的programmer好找，會設計protocol或實作protocol的programmer難找，當網路出現異常，能排除網路問題的programmer也不好找；會用加解密API寫程式的programmer好找，但對流程是否安全、金鑰是否安全等問題清楚的programmer就不見得好找，於是，在公司經費有限或是徵才不順的情況下，可能出現一個團隊裡都是只會用API的programmer，外加一個經驗老到的天才programmer (同時具備上述三種技能的最高等級)，如此一來，即使不定期的由經驗老到的programmer和其他人pair programming，當發生問題時，可能還是由經驗老到的programmer處理。

　　前言
　　北市府與Google對於Android Market的七日鑑賞期之戰，到目前還沒有結束，反倒是Apple果斷地回覆草草結束戰役讓我頗為意外。但如果認真想，App Store對Apple來說，重要的收益是透過App Store吸引顧客，然後賣出更多iPhone，而不是軟體利潤的分紅(雖然為數眾多的軟體，其三成分紅可能不少)，即便App Store上的所有軟體都是免費，只要iPhone大賣，Apple就是賺錢，所以真要得罪，手機顧客是不能得罪的，軟體開發者就稍為抱歉一點了，畢竟App Store提供的是一個平台，這個平台可以提供曝光機會，但如何賺錢可不是這個平台要負責的事情(當然，Apple會否認我的說法XD)。會有這樣思考的轉變，跟看完《免費！切開零定價的獲利秘密》這本書有關，我不敢說這本書上說的趨勢是對的，我想沒有人能夠真的預言未來，但就親身經歷來說，現在真的身處在一個資訊免費的世代，於是一個可能潛在軟體工程師(迷之音：『潛在』是指也可能不當軟體工程師嗎？)，有些有趣的心得。

　　最近寫paper寫煩了，就會拿起書翻一翻，加上先前幫忙鄭老師的Scrum推廣課程時，一邊聽課程一邊我的腦中也冒出一堆問題，所以我找上《Agile Software Development with Scrum》這本書，還沒看完整本書，不過，這本書確實解決了我腦中的一些問題，但也冒出一些新問題XD，由於這本書被當成睡前時看的書，有時候還會想這些問題想到沒睡好，看到現在，印象最深刻的卻是3.3.5節Working Environment一節中的一段：
　　If I were starting another company, I'd gut whatever space I had, put in wood or concrete floors, cover the walls with the whiteboards, and scatter telephone and network connections throughout. Then I'd issues everyone a rolling desk, a rolling file cabinet, and a cart with a computer and monitor. I'd let people form their own groups, clusters of furniture formed on the basis of who was working with whom at the time.