出錯時的軟件開發
在開發的過程中有錯誤發生了,此時你該如何應對呢?John Ferguson Smart在他的最新博客中提出了一些想法,大家可以參考一下(2008.10.27最后更新)現今比以后任何時候,都需要開發者更加高效。極度高效。組織需要提高從它們的開發項目中得到的附加值,并且它們也樂于尋找實現這一目標的方法。
當然,你可以采用傳統的方法--努力工作。為了消除項目中不可預見的癥狀,每天工作16個小時,還沒有周末。但做的更聰明一點兒,會不會更好些?
在引進新的實踐方法及改進現有方法方面投入的相對多一些,以使組織能努力獲得更多回報,這就是開發的過程。一般而言,事物中有許多方面都可以被改進,但此處有一些小竅門能使你的開發流程更加合理,只是為你開個頭罷了。
持續集成(CI)通知策略的再思考
到目前為止,最通用的CI通知機制就是陳舊的郵件服務器。然而,你能肯定在你手邊能完成這項任務的最合適系統就是電子郵件嗎?嘗試不使用電子郵件,而使用即時消息去完成你的CI通知。記住,電子郵件易成為一種干擾--如果你僅僅大約每兩小時才查閱一次郵件,你就會變得十分高效。電子郵件只是,或至少是,用于構建失敗--人們需要快速地知曉失敗任務。
積極地優化構建過程
構建度量(Build Metrics)是一種監控構建過程健康狀況的極好方法。為什么過去3周中,代碼覆蓋率一直在下降?為什么單元測試的數量并未呈有規律的增長?為什么要花費很長的時間去修復這樣的構建?運行單元測試需要多長時間--是否有一些測試需要執行過分長的時間?這些信息并非華而不實的東西--在不斷改進構建過程的工作中,它們都扮演著關鍵的角色。現代CI工具,如Hudson,Bamboo和TeamCity,能為構建展示豐富的統計。Bamboo在這方面做的尤佳。無論你正使用何種CI工具,都要學習如何最大限度地使用它的報表特性,并使用這些特性去定位及修復開發過程中討厭污點。如果你的CI工具不能給你所需要的全部信息,那就找一個能做到的。
合理化發布過程
在發布過程中有許多必做的工作,如準備發行說明,確定該版本中哪些問題已被解決了,標記版本,等等。這些都是軟件生命周期的重要部分,如果你忽略了它們,QA們和最終用戶可能會很生氣。但要盡量自動地去做這些工作。許多CI工具能很好地與問題追蹤系統(如JIRA和Trac)進行集成,以便你能基于版本控制日志看到某個問題是在哪次特定的構建中被解決的。如果你在使用Eclipse,Mylyn能幫你將處理過的問題歸總成邏輯變化組,并使用標準的模板列出在某項工作中已被解決的(或僅是影響到的)問題。或者你可使用Subversion的hook腳本去確保每次向Subversion做的提交都能對應到一個有效的問題編號。
這只是一些想法罷了--還有更多。底線就是--你不需要忍耐一個次理想的開發過程--相反,要進入其中,并做些能改進它的事情。祝好運!