基本上這次開發沒有加太多班，主要的原因可能是有些預估要比較花時間的部份，像右鍵選單，在後期因為繼承的方法，加快了開發速度，剛開始的時候，在開發底層報價和走勢圖的部份，花的時間比預估的長很多，一度以為並不樂觀，但是底部架構好，接下來畫面部份很快就完成了。在以後類似功能評估時，在底層應該多估一點時間，而其繼承的畫面花的時間應該也會相對少一點。這次時間較上次充裕，測試也較充足，感覺上Bug應該會比較少。這次開發也有幾項心得，依好壞種類分成二大項：
幾個常犯的開發錯誤：
- 修改底層類別，未檢查繼承類別的相關方法，造成繼承類別功能錯誤。這很難避免，每次都會自己提醒自己，甚至盡量繞過不要改底層類別，Bug總是在想不到的地方產生，實在想不出較有效率的解決方法，只能小心的檢查了。
- 依語意開發，而非自以為替換實際行為。右鍵許多功能原意等同於其相當的快捷鍵，原本的開發方法是右鍵功能同樣使用快捷鍵呼叫的方法，沒想到卻造成許多無法預期的意外，尤其是MFC MessageMap指標函式的關係，造成繼承失效。最後解決的方法還是送出postmessage，來模擬呼叫。
- 在可行性評估時，未了解真正的需求。現在回頭看，當初做可行性評估時，做的許多測試程式，和現在用的有很大的不同。不知是當初對需求認知有誤還是需求有改變，有很多時間浪費掉了。
- 不要將與其他DLL不相干的資訊紀錄在共用include檔中。之前在IMODMenu.h加入了幾個沒有要給其他DLL共用的資料，卻造成IMUI介面改變，其他所有相關的DLL都要重Build，一直到很後面才發現這個錯誤，浪費了很多時間。
- 記住引用其他DLL時常出現的錯誤。這次花了不少時間浪費在設定上得錯誤，一開始以為程式碼有錯，一直link不到，後來才知道setting處都沒設好，才出現這些錯誤。
- 測試計畫的撰寫應與開發並行，測試計畫這次是排在開發一個段落後才開始撰寫，容易造成開發途中可能想到要在什麼特殊情況下測，但是後來反而忘了測。理論上應該先應規格書寫一個初版，開發途中再改版，最後單元測試還得再改一次，這樣可能比較不容易漏東漏西。
這次用的幾個開發策略，下次可以延伸引用，
- 在部份大功能最後加個重構程式碼的WBS，其實重構我是邊開發邊做，不一定是整個完成才做，因為通常開發到一半，整個最適的架構已經成型了，後期也改不了多少，反而多估的WBS，在解決變動的需求或當初沒發現要做的部份，現在回想如果沒預估這部份，可能又要加不少班。
- 企劃進入測試。因為這次與泳要看樣式修改後的畫面，所以開發到一半，他就開始玩程式了，如預期的他發現了幾個我們沒開發到的部份，不過我認為這次狀況比較特殊，他才會先玩程式，下一版就算請企劃先測，大概也沒這個效果了。
- 先做不受BK影響的部份。因為記取184的教訓，184前兩個禮拜因為港股BK沒有開發完成，造成我們開發效率嚴重低落，這次我先排右鍵選單，等資料源與BK介面都確定了，再進入開發，效率感覺比184好多了。
紀錄一下，或許debug時又會發現新的想法。下一版再回頭來看看這些問題。
留言