測試方面的最佳實踐：
1.測試驅動開發(fā)：先有測試再有開發(fā)。
我們一般的順序是先開發(fā)后測試，然則這個實踐要求我們先將測試想好，然后開發(fā)來滿足這些測試。
這個思路其實就是目標驅動，我們先假設軟件已經做好，那么我們先寫出測試用例，然后我們編寫的開發(fā)代碼應該能通過這些測試用例。這樣思路的好處就是能讓我們想清楚目標，所有的開發(fā)都是有針對性的，減少無用功，提高工作效率，同時因為測試已經寫好了，代碼的質量會更加有保障。
這個思路其實是相當優(yōu)秀的，但這個實踐可能是這么多最佳實踐中最難成功實施的！我們公司曾經推行過一段時間，最終還是失敗告終。難以施行有以下原因：
1）開發(fā)人員普遍沒有這么高的編程素質。
先不說測試驅動開發(fā)，我們往往連單元測試也做不到！測試驅動開發(fā)其實就是要求我們先寫出單元測試代碼，然后再寫出滿足單元測試代碼的代碼。
2）編碼是一個循序漸進的過程，不太可能一開始接口就想好并且后面不會變了。
我自己編寫代碼也不太可能一開始就完全想清楚類中的各個屬性方法，有時候會覺得方法名字不好會換掉，參數(shù)不太合適也會調整。如果我們先寫出測試的代碼，其實就要求我們先確定各類名稱以及各類的公開接口，但往往我們需要不斷調整，這樣就會導致開發(fā)代碼與測試代碼都需要同時調整，工作量就增大了。
3）達不到自動化測試的技術層次。
自動化測試需要工具支持，并不是所有公司都具備這樣的條件。
測試驅動開發(fā)的意義還是很重大的，我有這樣的一些實踐建議：
1）先寫開發(fā)代碼，然后寫單元測試代碼。
2）編寫代碼時，應該先想清楚類職責，類公開接口，然后再寫具體實現(xiàn)代碼。
3）某個類完成時或者階段性完成了一些功能時，應該馬上寫出相應的測試代碼，并保證開發(fā)代碼能通過測試。
4）如果不能針對所有類都寫出測試類，那至少應該針對重要的、核心的、被使用次數(shù)多的類編寫測試代碼。
5）單元測試應該能做到自動化。
2.自動化測試：自動化單元測試、自動化UI測試。
自動化單元測試，目前很多開發(fā)工具都支持，技術上問題不大，問題大的是大家不去執(zhí)行或者說是能力不夠執(zhí)行不了。
UI方面的自動化測試就有點麻煩了，有這樣兩點：
1）就算是比較好的自動UI測試工具，也難以捕捉到軟件界面上所有的控件以及動作。
2）軟件的界面經常調整是很常見的時間，界面不凍結，UI自動化測試寸步難行。
要推行100%的自動化測試難度還是很高的，不過應該還是盡量自動化測試，單元自動化測試與性能自動化測試在技術上是沒有問題的，是執(zhí)行的能力與決心問題。
自動化測試這個最佳實踐與測試驅動開發(fā)是緊密相關的，這兩個最佳實踐其實是整個極限編程中最核心、最精彩、要求最嚴格的兩個實踐。只要將這兩個實踐做好，代碼隨便你改，只要能通過測試就行，不用害怕需求變更帶來的代碼隱患，變就變，反正有自動化測試全面檢查！
編碼方面的最佳實踐：
1）重構：不講究一次將代碼寫好，但需要重構時應該毫不猶豫。
重構的意思是代碼的接口和實現(xiàn)功能不變，但修改代碼的具體實現(xiàn)，從而使代碼的結構、可讀性、性能、安全性等更好。
重構因為有測試驅動以及自動化測試這兩個實踐的支持，故不需要擔心重構帶來的影響，萬一重構失敗，取回原來的代碼便可。
2）結對編程：兩個人，組成一對，共用一臺電腦編程。
頭次聽說這個，還覺得很難想象，兩個人坐在一起，只用一臺電腦，一個人寫代碼，另外一個看，過一會兩個人可以交換一下。
兩個人一起寫代碼，相當于隨時在做同行評審，似乎效率降低了，但代碼的質量得到保障，并且能保證所有代碼至少有兩個人了解的。
另外要注意的是：組成一對的兩個人，應該水平相當。
這個實踐很有意思，不