項目管理學習之(2)-避免打地鼠式開發

    

       「當估計某一功能的實現時間時，不要只考慮最初寫代碼所花費的時間，還要加上提高、調整和改進這些代碼所需的時間。寫高質量的代碼和測試都須要花時間。從短時間來看，這彷佛是一種損失，然而它帶來的倒是長期收穫。」速度當然重要，可是因爲速度快致使的後果是無窮的。

         上面這段話引用自「項目經歷應該知道的97件事」。文中舉例有兩個開發人員，一個速度快(開發出的代碼可維護性差)，一個穩紮穩打(寫出的可維護性好)。 在項目前期，開發速度快的人員很快的提交了可運行的代碼，開發速度慢的則忙於架構代碼，對代碼總體框架進行優化，爲後續功能的添加和改動做鋪墊。在項目後期，因爲新功能的加入，需求的變動，致使速度快的人員編寫的代碼出現了維護難，修改了這裏那裏就沒法運行，花去了大把大把的時間來修復這裏缺陷。就像打地鼠，你永遠不知道下一個地鼠從哪裏出現，下一個缺陷什麼時候出現如何解決。而相反的是，前期開發速度慢的人員卻發力了。因爲以前的代碼架構不少，模塊之間的耦合度低，模塊的變更不會影響其餘模塊，添加修改功能更簡單更方面。

         結合上面兩段話，我聯想起我接手過的一個二手項目。項目初期開發人員因爲時間緊，缺少經驗，在功能實現的時候東拼西湊，僅僅是爲了完成功能而編寫了某些代碼。最直接的後果就是後期項目測試環節，反饋的衆多問題沒法修改，或者只能折中方式去修改。改了這個地方，那個地方又出問題了。就像大海里行駛的木船，拆了這塊板補那個洞，補好了以後剛纔的地方又開始漏水了。

        所以項目前期不妨稍微慢一點，對基礎架構進行慎重的考量，由此帶來的好處天然沒必要多說。尤爲稍大的項目，前期的準備更是尤其重要。

        根基不勞，你還期望能建造出什麼樣的摩天大樓？~ 爲了你的項目按時交付，避免打地鼠式的開發。