極限編程12個開發實踐

12個核心實踐翻譯自論文

——Extreme-Programming-A-Case-Study-in-Software-Engineering-Courses

 

1、在正式翻譯論文以前，本人就我的查閱資料的相關狀況，先對Extreme-Programming作一個簡要概述：

         極限編程是一個輕量級的、靈巧的軟件開發方法；同時它也是一個很是嚴謹和周密的方法。它的基礎和價值觀是交流、樸素、反饋和勇氣；即，任何一個軟件項目均可以從四個方面入手進行改善：增強交流；從簡單作起；尋求反饋；敢於實事求是。XP是一種近螺旋式的開發方法，它將複雜的開發過程分解爲一個個相對比較簡單的小週期；經過積極的交流、反饋以及其它一系列的方法，開發人員和客戶能夠很是清楚開發進度、變化、待解決的問題和潛在的困難等，並根據實際狀況及時地調整開發過程。

「Extreme」（極限）是指，對比傳統的項目開發方式，XP強調把它列出的每一個方法和思想作到極限、作到最好；其它XP所不提倡的，則一律忽略（如開發前期的總體設計等）。一個嚴格實施XP的項目，其開發過程應該是平穩的、高效的和快速的，可以作到一週40小時工做制而不拖延項目進度。

XP在制定需求方面，提倡客戶是項目開發的隊伍中的一員；在設計階段提倡測試先行；在編碼階段提倡結對編程。

基於敏捷的核心思想和價值目標，XP要求項目團隊遵循13個核心實踐

團隊協做(Whole Team)、規劃策略(The Planning Game)、

結對編程(Pair programming)、測試驅動開發(Testing-Driven Development)

重構(Refactoring)、簡單設計(Simple Design)

代碼集體全部權(Collective Code Ownership)、持續集成(Continuous Integration)

客戶測試(Customer Tests)、小型發佈（Small Release）

每週40小時工做制（40-hour Week）、編碼規範（Code Standards）

系統隱喻（System Metaphor）

 

                                                                                    ——以上內容引自百度文庫

 

2、12個核心實踐論文翻譯

一、規劃策略(The Planning Game)：將業務與開發團隊彙集到一塊兒，共同決定需求的特徵將會最大化業務價值。在XP中收集需求的相關技術與傳統軟件方法有着根本的不一樣。首先，客戶需求使用天然語言寫成的，非正式的「用戶故事」卡片，與用例類似。這些卡片沒有形式化，彼此之間沒有關係和依賴，不容易被識別。軟件開發人員將時間估算和客戶分配到每張卡片的優先級。開發人員和客戶一塊兒玩「規劃遊戲」，在這個遊戲中，用戶選擇那些包含一個月左右的短時間增量交付的最重要內容的用戶故事。客戶接受並嘗試每一個短的執行增量。而後，從新檢查其他的用戶故事以查找可能的需求和/或優先級變化，而且爲下一個執行增量從新開始計劃遊戲。

二、小型發佈（Small Release）：一個包含了一系列有用特徵的簡單系統能夠儘早的投入生產而且能夠在較短週期期內頻繁更新。XP經過3-4周的短時間發佈提升了螺旋式發展的速度。每次發佈結束時，客戶都會審閱中間產品，識別缺陷並調整將來的需求。

三、隱喻（Metaphor）：每一個項目都有一個「名稱系統」和描述，有助於指導各方之間的發展過程和交流。XP相信每一個應用程序都應該具備基於簡單隱喻的概念完整性，這就解釋了系統工做的本質。例如，一個大的XP項目是克萊斯勒的工資系統。 這個項目的隱喻是，工資系統就像一條裝配線，其中小時零件被轉換成美圓零件，全部零件都被組裝併產生薪水。

四、簡單設計(Simple Design)：只要知足當前業務需求，最簡單的設計老是用於構建應用程序。不管如何，隨着時間需求的變化，不要擔憂將來的需求。重構實踐（見下文）將確保設計的高標準。XP致力於超級簡單的設計。他們強調程序員不該該試圖預測將來的需求，並相應地產生更復雜的設計。開發人員應該遵循簡單的設計實踐和「作能夠工做的最簡單的事情」。

五、測試（Testing）：XP遵循「測試優先」的方法，即在添加新功能以前，編寫測試來驗證軟件。而後開發該軟件以經過這些測試。使用XP開發的軟件始終獲得驗證。進行兩種類型的測試，單元和功能測試

      5.一、單元測試：普遍的自動化白盒測試用例是在生產代碼以前編寫的。這些自動化測試被添加到代碼庫中。在程序員能夠將他們的代碼集成到代碼庫以前，他們必須經過他們本身的測試用例的100％，以及在代碼庫中寫過的每一個測試的100％。這可確保新代碼在不破壞其餘人的代碼的狀況下實現新功能。

      5.二、功能測試：傳統上，項目管理技術是基於開發人員本身評估他們的任務已完成的。或者，XP推廣使用功能測試用例跟蹤來計算項目完整性。XP將此評估稱爲「項目速度」。功能測試用例基於客戶場景。當功能測試用例成功經過時，能夠認爲指定功能已正確實施。項目的完整性基於已經過的功能測試用例的百分比。團隊成員能夠明確地計算這個度量。

      5.三、自動化測試：編寫測試是不夠的，你必須運行它們。單元測試所有收集在一塊兒，每當程序員向代碼庫發佈任何代碼時（代碼對一般天天發佈兩次或更多），每一次程序員測試都必須正確運行。百分之百，全部的時間！開發者有興趣使用適當的自動化測試框架，例如 JUnit和NUnit，來控制和簡化重複測試和持續集成的任務。這意味着程序員能夠當即得到關於他們如何作的反饋。另外，隨着軟件設計的改進，這些測試提供了很是寶貴的支持。

六、重構：重構是在保留（而不是改進）其功能的同時改進代碼結構的過程。XP主張持續而明確地重構代碼。這是一種改進現有代碼庫設計的技術。其本質是應用一系列小的行爲保留轉換，以改善代碼的結構。經過小步驟完成它們，能夠下降引入錯誤的風險。

七、結對編程：使用XP的編程人員進行配對，並使用每對配對的單個機器編寫全部生產代碼。這有助於代碼在寫入時不斷進行審閱。結對編程證實能夠生成高質量的代碼，但生產力幾乎沒有降低。

八、代碼集體全部：全部代碼都屬於團隊的每一個成員，團隊中沒有一個成員擁有一段代碼，任何人均可以隨時對代碼庫進行更改。這鼓勵每一個人爲項目的全部部分貢獻新的想法。

九、持續集成：軟件系統一天建成並集成數次;至少全部變動都集成到主集成平臺的主代碼庫中，至少天天一次。所以，天天都有不少產品構建。每一個構建都使用相關的測試用例進行測試。

十、40小時制：XP項目中的程序員一般堅持每週工做40小時，以保持生產力並避免加班。人們發現，在加班工做的緊急時期，產品的質量不好。

十一、現場客戶：將使用正在構建的系統的一個或多個客戶分配給開發團隊。客戶有助於指導開發，並有權優先考慮，還能夠說明需求並回答開發人員可能遇到的任何問題。這確保了與客戶進行有效的溝通，這樣須要的文件就更少了。

十二、編碼標準：XP項目中的每一個人都使用相同的編碼標準，從而能夠輕鬆地成對工做並共享全部代碼的全部權。開發成員不該該可以分辨出誰在XP項目中使用了哪些代碼。應該定義並遵循商定的編碼標準。

轉載請註明出處！