極限程式設計思想

餘二五發表於2017-11-15
程式設計
極限程式設計（Extreme Programming，XP）是一門針對業務和軟體開發的規則，它的作用在於將兩者的力量集中在共同的、可以達到的目標上。它是以符合客戶需要的軟體為目標而產生的一種方法論，XP使開發者能夠更有效的響應客戶的需求變化，哪怕是在軟體生命週期的後期。它強調，軟體開發是人與人合作進行的過程，因此成功的軟體開發過程應該充分利用人的優勢，而弱化人的缺點，突出了人在軟體開發過程中的作用。極端程式設計屬於輕量級的方法，認為文件、架構不如直接程式設計來的直接。
      XP實際上是一種經歷過很多實踐考驗的一種軟體開發的方法，它誕生了大概有5 年，它已經被成功的應用在許多大型的公司，如：Bayeris che Landesbank，Credit Swis s Life，DaimlerChrysler，First Union National Bank　Ford Motor Company and UBS.XP 的成功得益於它對客戶滿意度的特別強調，XP 是以開發符合客戶需要的軟體為目標而產生的一種方法論，XP 使開發者能夠更有效的響應客戶的需求變化，哪怕在軟體生命週期的後期。
　　同時，XP 也很強調團隊合作。團隊包括：專案經理，客戶，開發者。他們團結在一起來保證高質量的軟體。XP 其實是一種保證成功的團隊開發的簡單而有效的方法。
　　XP 強調四種價值：交流，簡易，回饋，勇氣。XP 程式員之間緊密的相互交流，XP 程式設計師也和客戶緊密的交流。他們總是保持他們的設計簡單明瞭。專案一開始，XP 就強調通過對軟體的不斷測試來獲得反饋，程式設計師儘可能早的把軟體交給客戶，並實現客戶對軟體需求提出的變化，有了這些基礎，XP 程式設計師就可以自信的面對需求和軟體技術的變化。
　　XP 是與眾不同的，它有點象快步的舞蹈。XP 開發過程包括許多的小卡片，獨立的看，這些小卡片沒有什麼意義，但是當它們組合在一起，一幅完整的美麗的圖片就可以看見，XP方法有別於傳統軟體開發，它是軟體開發的一種新的重要的發展。它改變了我們開發程式的傳統思維方式。下面我們將介紹它帶給我們那些改變。

 

XP屬於輕量開發方法中較有影響的一種方法。輕量開發方法是相對於傳統的重量開發方法而言。簡單地理解，“量”的輕重是指用於軟體過程管理和控制的、除程式量以外的“文件量”的多少。XP等輕量開發方法認識到，在當前很多情況下，按傳統觀念建立的大量文件，一方面需要消耗大量開發資源，同時卻已失去幫助“預見、管理、決策和控制的依據”的作用。因此必須重新審視開發環節，去除臃腫累贅，輕裝上陣。
一、XP的核心思想
      從長遠看，早期發現錯誤以及降低複雜度可以節約成本。極限程式設計強調我們將任務/系統細分為可以在較短週期解決的一個個子任務/模組，並且強調測試、程式碼質量和及早發現問題。通常，通過一個個短小的迭代週期，我們就可以獲得一個個階段性的進展，並且可以及時形成一個版本供使用者參考，以便及時對使用者可能的需求變更作出響應。
二、XP的十二種方法
      規劃策略(The Planning Game)；

      結對程式設計(Pair programming)

      測試(Testing)

      重構(Refractoring)

      簡單設計(Simple Design)

      程式碼集體所有權(Collective Code Ownership)

      持續整合(Continuous Integration)

      現場客戶(On-site Customer)

      小型釋出（Small Release）

      每週40小時工作制（40-hour Week）

      編碼規範（Code Standards）

      系統隱喻（System Metaphor）
三、XP的四個核心價值
      極限程式設計中有四個核心價值是我們在開發中必須注意的：溝通（Communication）、簡單（Simplicity）、反饋（Feedback）和勇氣（Courage）。
　　XP用“溝通、簡單、反饋和勇氣”來減輕開發壓力和包袱；無論是術語命名、專著敘述內容和方式、過程要求，都可以從中感受到輕鬆愉快和主動奮發的態度和氣氛。這是一種幫助理解和更容易激發人的潛力的手段。XP用自己的實踐，在一定範圍內成功地打破了軟體工程“必須重量”才能成功的傳統觀念。
　　XP精神可以啟發我們如何學習和對待快速變化、多樣的開發技術。成功學習XP的關鍵，是用“溝通、簡單、反饋和勇氣”的態度來對待XP；輕鬆愉快地來感受XP的實踐思想；自己認真實踐後，通過對真實反饋的分析，來決定XP對自己的價值；有勇氣接受它，或改進它。
四、XP 帶給我們的變化
　　通過軟體工程設計的簡單而優美的軟體並不比那些設計複雜而難以維護的軟體有價值。這是真的嗎？XP認為事實並非如此。
　　一個典型的專案花在人力上的金錢是花在硬體上的時間的20 倍，這意味著一個專案每年要花200 萬美元在程式設計師身上，而僅僅花10 萬美元在電腦裝置上。很多聰明的程式設計師說：“我們如此聰明，發現一種方法可以節省20%的硬體開銷”，然後他們使得源程式大而且難懂和難以維護，他們會說：“但是我們節省了20%或者2 萬美元每年，很大的節省”。反之，如果我們寫我們的程式簡單而且容易擴充套件，我們將至少節省10%的人力開銷，一筆更大的節省，這是你客戶一定會注意到的一些事情。
　　另外一個對客戶來說很重要的問題就是程式的BUGS 。XP 不只是強調測試，而且要求正確的測試。測試必須是能自動進行的，以便為程式和客戶提供一個安全的環境。在編碼的所有階段，我們不斷增加測試用例。當找到bug 時，我們就新增新的測試，一個緊密的安全網就這樣產生了。同一個BUG 不出現兩次，這些一定會引起使用者的注意。你的客戶必須注意的另外一件事情：XP 開發者擁抱需求變化。XP 使我們能夠接受需求的變化。
　　一般情況下，客戶只有在系統被開發完成以後能真正去體會它。XP 卻不一樣，它通過加強客戶的反饋來縮短開發的週期，同時獲得足夠的時間來改變功能和獲得使用者的認同。在XP 中，你的客戶應該明確的知道這一點。
　　XP開發過程的大多的革命是在軟體開發的方法上，程式碼質量的重要程度超出人們一般所認為的。僅僅因為我們的客戶不能明白我們的原始碼並不意味著我們可以不努力去管理程式碼的質量。
五、我們什麼時候用XP
　　XP方法的產生是因為難以管理的需求變化，從一開始你的客戶並不是很完全的知道他們要的系統是怎麼樣的，你可能面對的系統的功能一個月變化多次。在大多數軟體開發環境中不斷變化的需求是唯一的不變，這個時候應用XP 就可以取得別的方法不可能取得的成功。XP 方法的建立同時也是為了解決軟體開發專案中的風險問題。假如你的客戶在特定的時間內，需要一個相當難開發的系統，而且對於你的專案組來說，這個系統是一個新的挑戰（從來沒有做過），那風險就更大了，如果這個系統對於整個軟體行業來說都是新的挑戰，那麼它的風險就更大了，採用XP 將可以減少風險，增加成功的可能。
　　XP方法是為小團體開發建立的，在2-10 個人之間。假如你的團體恰好合適，你就不需要用其他的軟體工程方法了，就用XP ，但是要注意你不能將XP 方法應用於大團體的開發專案中。我們應該注意，在需求一慣呈動態變化或者高具有高風險的專案中，你就會發現XP 方法在小團體的開發中的作用要遠遠高於在大團體的開發。
　　XP方法需要一個擴充套件的開發團體，XP 團體不僅僅包括開發者，經理、客戶也是其中的一員，所有的工作一環扣一環，問問題，商討方法和日程，增加功能測試，這些問題的解決不僅僅涉及到軟體的開發者。
　　另一個需要是可測試性，你必須能增加自動的單元測試和功能測試，然而在你進行這個需求的時候，你會發現有許多的問題很難測試，這需要充分發揮你的測試的經驗和智慧，而且你有時還要改變你的設計以便它可以更容易的進行測試。記住：那兒有需求，那兒就應該有測試的方法。
　　在XP方法的好處的清單上，最後一條是生產力。在同樣的合作環境下，XP 專案都一致的表現出比使用其他方法高的多的生產力。但這從來不是XP 方法學的真正目標。XP 真實追求的目標是：在規定的時間生產出滿足客戶需要的軟體。假如對於你的開發來說，這是很重要的方面，你就可以選擇XP 了。
六、極限程式設計的有效實踐
1、完整團隊
      XP專案的所有參與者（開發人員、客戶、測試人員等）一起工作在一個開放的場所中，他們是同一個團隊的成員。這個場所的牆壁上隨意懸掛著大幅的、顯著的圖表以及其他一些顯示他們進度的東西。
2、計劃遊戲
      計劃是持續的、循序漸進的。每2周，開發人員就為下2周估算候選特性的成本，而客戶則根據成本和商務價值來選擇要實現的特性。
3、客戶測試
      作為選擇每個所期望的特性的一部分，客戶可以根據指令碼語言來定義出自動驗收測試來表明該特性可以工作。
4、簡單設計
      團隊保持設計恰好和當前的系統功能相匹配。它通過了所有的測試，不包含任何重複，表達出了編寫者想表達的所有東西，並且包含儘可能少的程式碼。
5、結對程式設計
      所有的產品軟體都是由兩個程式設計師、並排坐在一起在同一臺機器上構建的。
      編寫單元測試是一個驗證行為，更是一個設計行為。同樣，它更是一種編寫文件的行為。編寫單元測試避免了相當數量的反饋迴圈，尤其是功功能能驗證方面的反饋迴圈。程式設計師以非常短的迴圈週期工作，他們先增加一個失敗的測試，然後使之通過。
7、改進設計
      隨時利用重構方法改進已經腐化的程式碼，保持程式碼儘可能的乾淨、具有表達力。
8、持續整合
      團隊總是使系統完整地被整合。一個人拆入（Check in）後，其它所有人責任程式碼整合。
9、集體程式碼所有權
      任何結對的程式設計師都可以在任何時候改進任何程式碼。沒有程式設計師對任何一個特定的模組或技術單獨負責，每個人都可以參與任何其它方面的開發。
10、編碼標準
      系統中所有的程式碼看起來就好像是被單獨一人編寫的。
11、隱喻
      將整個系統聯絡在一起的全域性檢視；它是系統的未來影像，是它使得所有單獨模組的位置和外觀變得明顯直觀。如果模組的外觀與整個隱喻不符，那麼你就知道該模組是錯誤的。
12、可持續的速度
      團隊只有持久才有獲勝的希望。他們以能夠長期維持的速度努力工作，他們儲存精力，他們把專案看作是馬拉松長跑，而不是全速短跑。
本文轉自 fsjoy1983 51CTO部落格，原文連結：http://blog.51cto.com/fsjoy/77833，如需轉載請自行聯絡原作者


相關文章