敏捷開發縱橫談(2)

　　這個實踐有點劍走偏鋒，有人還會因為這個實踐不仔細思考軟件設計就編碼了，我們有很多項目因為設計得太爛而吃了不少苦頭。實戰簡單設計時，我有這樣的一些建議：

　　1)對于沒有類似經驗的項目，設計應該盡量簡單，但簡單的設計是需要嚴謹的思考得到的，你不要認為簡單想一個設計出來就是簡單設計。

　　2)思考項目設計時，應考慮有什么東西可以重用，同時適當考慮本項目有什么東西可供以后的項目重用。

　　測試方面的最佳實踐：

　　1.測試驅動開發：先有測試再有開發。

　　我們一般的順序是先開發后測試，然則這個實踐要求我們先將測試想好，然后開發來滿足這些測試。

　　這個思路其實就是目標驅動，我們先假設軟件已經做好，那么我們先寫出測試用例，然后我們編寫的開發代碼應該能通過這些測試用例。這樣思路的好處就是能讓我們想清楚目標，所有的開發都是有針對性的，減少無用功，提高工作效率，同時因為測試已經寫好了，代碼的質量會更加有保障。

　　這個思路其實是相當優秀的，但這個實踐可能是這么多最佳實踐中最難成功實施的!我們公司曾經推行過一段時間，最終還是失敗告終。難以施行有以下原因：

　　1)開發人員普遍沒有這么高的編程素質。

　　先不說測試驅動開發，我們往往連單元測試也做不到!測試驅動開發其實就是要求我們先寫出單元測試代碼，然后再寫出滿足單元測試代碼的代碼。

　　2)編碼是一個循序漸進的過程，不太可能一開始接口就想好并且后面不會變了。

　　我自己編寫代碼也不太可能一開始就完全想清楚類中的各個屬性方法，有時候會覺得方法名字不好會換掉，參數不太合適也會調整。如果我們先寫出測試的代碼，其實就要求我們先確定各類名稱以及各類的公開接口，但往往我們需要不斷調整，這樣就會導致開發代碼與測試代碼都需要同時調整，工作量就增大了。

　　3)達不到自動化測試的技術層次。

　　自動化測試需要工具支持，并不是所有公司都具備這樣的條件。

　　測試驅動開發的意義還是很重大的，我有這樣的一些實踐建議：

　　1)先寫開發代碼，然后寫單元測試代碼。

　　2)編寫代碼時，應該先想清楚類職責，類公開接口，然后再寫具體實現代碼。

　　3)某個類完成時或者階段性完成了一些功能時，應該馬上寫出相應的測試代碼，并保證開發代碼能通過測試。

　　4)如果不能針對所有類都寫出測試類，那至少應該針對重要的、核心的、被使用次數多的類編寫測試代碼。

　　5)單元測試應該能做到自動化。

　　2.自動化測試：自動化單元測試、自動化UI測試。

　　自動化單元測試，目前很多開發工具都支持，技術上問題不大，問題大的是大家不去執行或者說是能力不夠執行不了。

　　UI方面的自動化測試就有點麻煩了，有這樣兩點：

　　1)就算是比較好的自動UI測試工具，也難以捕捉到軟件界面上所有的控件以及動作。

　　2)軟件的界面經常調整是很常見的時間，界面不凍結，UI自動化測試寸步難行。

　　要推行100%的自動化測試難度還是很高的，不過應該還是盡量自動化測試，單元自動化測試與性能自動化測試在技術上是沒有問題的，是執行的能力與決心問題。

　　自動化測試這個最佳實踐與測試驅動開發是緊密相關的，這兩個最佳實踐其實是整個極限編程中最核心、最精彩、要求最嚴格的兩個實踐。只要將這兩個實踐做好，代碼隨便你改，只要能通過測試就行，不用害怕需求變更帶來的代碼隱患，變就變，反正有自動化測試全面檢查!

　　編碼方面的最佳實踐：

　　1)重構：不講究一次將代碼寫好，但需要重構時應該毫不猶豫。

　　重構的意思是代碼的接口和實現功能不變，但修改代碼的具體實現，從而使代碼的結構、可讀性、性能、安全性等更好。

　　重構因為有測試驅動以及自動化測試這兩個實踐的支持，故不需要擔心重構帶來的影響，萬一重構失敗，取回原來的代碼便可。

　　2)結對編程：兩個人，組成一對，共用一臺電腦編程。

　　頭次聽說這個，還覺得很難想象，兩個人坐在一起，只用一臺電腦，一個人寫代碼，另外一個看，過一會兩個人可以交換一下。

　　兩個人一起寫代碼，相當于隨時在做同行評審，似乎效率降低了，但代碼的質量得到保障，并且能保證所有代碼至少有兩個人了解的。

　　另外要注意的是：組成一對的兩個人，應該水平相當。

　　這個實踐很有意思，不過往往也是很難實踐的。

　　就我個人來說，我就不喜歡兩個人一起編程，我覺得每個人的思考其實很難同步的，每個人都需要靜下心來一個人思考問題，思考后才適合與別人討論，如果思考過程也與別人在一起，很難想象這個思考能有好的效果。

　　我們曾經將兩位編碼新手放在一起，讓他們結對編程，嘗試了這個實踐，似乎有一點效果，但我們后期就沒有再推行過。

　　3)代碼共有：每個人寫的代碼都是屬于全體的，每個人可以去改別人的代碼。

　　這里強調共享與進步精神，歡迎互相研究代碼，歡迎寫出更好的代碼，只要能通過測試就可以了!這個實踐是依賴于測試驅動開發以及自動化測試這兩個實踐的，如果不能做到那兩個實踐，就不應該隨便改動別人的代碼。

　　4)強調編碼標準

　　對于這點大家應該沒啥異議了，現在有不少開發工具支持編碼標準檢查呢!

　　項目管理方面的最佳實踐：

　　1.持續集成

　　持續集成與微軟的“每日構建”是一樣道理的，強調我們的軟件要隨時處在可以編譯通過可以發布的狀態，持續集成讓軟件的問題提早暴露更快解決。持續集成需要一定的工具和管理措施支持，我有這樣的一些實踐建議：

　　1)代碼的簽入與簽出要定下嚴格的規矩，如：每天工作前先獲取最新代碼，每次簽入前必須先保證編譯通過。

　　2)如果能做到測試驅動測試和自動化測試，那么還應該規定必須通過所有測試才能簽入代碼。

　　3)一般來說我們沒有條件做到每日構建，也沒有這么多工具支持，那么至少一周要編譯一次內部版本，檢查軟件各部分的協調情況。

原文轉自：http://www.cnblogs.com/umlonline/archive/2010/03/17/1687760.html