2007-01-30 源自:IT粉絲網 網友評論 我要發布知識
本文章地址：/IT/soft/System/117009070019269.html [點擊復制地址分享知識給朋友]
在按照我的理解方式審查了軟件開發的生命周期後，我得出壹個結論：實際上滿足工程設計標準的惟壹軟件文檔，就是源代碼清單。 -- jack reeves
簡介
2001年，為了解決許多公司的軟件團隊陷入不斷增長的過程泥潭，壹批業界專家壹起概括出了壹些可以讓軟件開發團隊具有快速工作、響應變化能力的價值觀和原則，他們稱自己為敏捷聯盟。敏捷開發過程的方法很多，主要有：scrum，crystal,特征驅動軟件開發（feature driven development，簡稱fdd），自適應軟件開發(adaptive software development，簡稱asd)，以及最重要的極限編程(extreme programming,簡稱xp)。極限編程(xp)是於1998年由smalltalk社群中的大師級人物kent beck首先倡導的。
設計和編程都是人的活動。忘記這壹點，將會失去壹切。
-- bjarne stroustrup
極限編程(xp)是敏捷方法中最箸名的壹個。它是由壹系列簡單卻互相依賴的實踐組成。這些實踐結合在壹起形成了壹個勝於部分結合的整體。
下面是極限編程的有效實踐：
1、 完整團隊
xp項目的所有參與者（開發人員、客戶、測試人員等）壹起工作在壹個開放的場所中，他們是同壹個團隊的成員。這個場所的墻壁上隨意懸掛著大幅的、顯著的圖表以及其他壹些顯示他們進度的東西。
2、 計劃遊戲
計劃是持續的、循序漸進的。每2周，開發人員就為下2周估算候選特性的成本，而客戶則根據成本和商務價值來選擇要實現的特性。
3、 客戶測試
作為選擇每個所期望的特性的壹部分，客戶可以根據腳本語言來定義出自動驗收測試來表明該特性可以工作。
4、 簡單設計
團隊保持設計恰好和當前的系統功能相匹配。它通過了所有的測試，不包含任何重復，表達出了編寫者想表達的所有東西，並且包含盡可能少的代碼。
5、 結對編程
所有的產品軟件都是由兩個程序員、並排坐在壹起在同壹臺機器上構建的。
6、 測試驅動開發
編寫單元測試是壹個驗證行為，更是壹個設計行為。同樣，它更是壹種編寫文檔的行為。編寫單元測試避免了相當數量的反饋循環，尤其是功功能能驗證方面的反饋循環。程序員以非常短的循環周期工作，他們先增加壹個失敗的測試，然後使之通過。
7、 改進設計
隨時利用重構方法改進已經腐化的代碼，保持代碼盡可能的幹凈、具有表達力。
8、 持續集成
團隊總是使系統完整地被集成。壹個人拆入（check in）後，其它所有人責任代碼集成。
9、 集體代碼所有權
任何結對的程序員都可以在任何時候改進任何代碼。沒有程序員對任何壹個特定的模塊或技術單獨負責，每個人都可以參與任何其它方面的開發。
10、編碼標準
系統中所有的代碼看起來就好像是被單獨壹人編寫的。
11、隱喻
將整個系統聯系在壹起的全局視圖；它是系統的未來影像，是它使得所有單獨模塊的位置和外觀變得明顯直觀。如果模塊的外觀與整個隱喻不符，那麽妳就知道該模塊是錯誤的。
12、可持續的速度
團隊只有持久才有獲勝的希望。他們以能夠長期維持的速度努力工作，他們保存精力，他們把項目看作是馬拉松長跑，而不是全速短跑。
極限編程是壹組簡單、具體的實踐，這些實踐結合在形成了壹個敏捷開發過程。極限編程是壹種優良的、通用的軟件開發方法，項目團隊可以拿來直接采用，也可以增加壹些實踐，或者對其中的壹些實踐進行修改後再采用。