中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

eXtreme Programming 極限編程-XP

XP概述

XP是一種輕量（敏捷）、高效、低風險、柔性、可預測、科學而且充滿樂趣的軟件開發方式。在以前的開發過程中，很多規則已經難于遵循，很多流程復雜而難于理解，很多項目中文檔的制作過程正在失去控制。人們試圖提出更全面更好的一攬子方案，或者寄希望于更復雜的、功能更強大的輔助開發工具（CaseTools），但總是不能成功，而且開發規范和流程變得越來越復雜和難以實施。XP就是在這樣的情況下誕生的，它是靈巧的輕量級軟件開發方法，它跳出復雜的流程和文檔，而是以輕量的框架和極限的思想為核心進行開發。

這里講的極限編程更像是一套理論知識，面向開發人員的指導，甚至是考核開發人員素質或者說優異程度的一個思想指標。雖然以下理論看起來難免枯燥無味，但是真正想了解敏捷開發的一些知識的還是需要好好閱讀一下。我個人甚至覺得，XP提出的一些價值，原則，實踐，可以用來培訓一些開發新手，成為一套有理論依據的準則。當然，這樣的準則還是需要根據情況調整，而不是生搬硬套。

（文章理論上的東西比較多，不好消化，需要思考理解，如果讀者是快餐式閱讀，建議不要浪費時間）

4大價值

溝通

XP方法論認為，如果小組成員之間無法做到持續的、無間斷的交流，那么協作就無從談起，從這個角度能夠發現，通過文檔、報表等人工制品進行交流面臨巨大的局限性。因此，XP組合了諸如對編程這樣的最佳實踐，鼓勵大家進行口頭交流，通過交流解決問題，提高效率。

簡單

XP方法論提倡在工作中秉承“夠用就好”的思路，也就是盡量地簡單化，只要今天夠用就行，不考慮明天會發現的新問題。這一點看上去十分容易，但是要真正做到保持簡單的工作其實很難的。因為在傳統的開發方法中，都要求大家對未來做一些預先規劃，以便對今后可能發生的變化預留一些擴展的空間。

反饋

反饋在團隊合作中是非常重要的，不僅是客戶與項目負責人之間的反饋，還應該包括開發人員在內，做到項目所有相關人自覺的反饋，讓他人知道項目進度，每個開發人員任務完成情況，做到人人都能及時知道項目的情況，人員的情況。這樣所有人都能心里有數，才能做到相互配合，有效的溝通。

勇氣

要知道，XP是提倡擁抱變化的，那么要積極響應變化就需要相關相關人員，特別是開發人員有勇氣來面對快速開發，重新開發，代碼重構等情況，快速開發需要勇于面對更多h3ug，將一些h3ug留到下一版，重新開發要敢于廢棄之前的努力，不要因為已經開發出來了即使沒有什么用處也要使用，重構則是要勇于改變現狀，讓代碼脫胎換骨。

5個原則

快速反饋

及時地、快速地獲取反饋，并將所學到的知識盡快地投入到系統中去。也就是指開發人員應該通過較短的反饋循環，迅速地了解現在的產品是否滿足了客戶的需求。也就是需要我們持續交付，調整功能，這也是對反饋這一價值觀的進一步補充。快速反饋同樣適用于開發人員之間，團隊人員之間，及時反饋，有效溝通。

簡單性假設

類似地，簡單性假設原則是對簡單這一價值觀的進一步補充。這一原則要求開發人員將每個問題都看得十分容易解決，也就是說只為本次迭代考慮，不去想未來可能需要什么，相信具有將來必要時增加系統復雜性的能力，也就是號召大家出色地完成今天的任務。這點下文還會繼續說明。

逐步修改

就像開車打方向盤一樣，不要一次做出很大的改變，那樣將會使得可控性變差，更適合的方法是進行微調。而在軟件開發中，這樣的道理同樣適用，任何問題都應該通過一系列能夠帶來差異的微小改動來解決。

提倡更改

在軟件開發過程中，在解決最重要問題時，盡量為下一次修改做好準備。開發不息，h3ug不斷，我們都要打從心里明白，h3ug是不可能有完全修改完的一天的，所以需要不斷進行更改，也不要守著最初的方案，不敢做任何變動，要為隨時可能到來的改動做好心里準備。

優質工作

在實踐中，經?？吹皆S多開發人員喜歡將一些細小的問題留待后面解決。例如，界面的按鈕有一些不平整，由于不影響使用就先不管；某一兩個成員函數暫時沒用就不先寫等。這就是一種工作拖泥帶水的現象，這樣的壞習慣一旦養成，必然使得代碼質量大打折扣。而在XP方法論中，貫徹的是“小步快走”的開發原則，因此工作質量決不可打折扣，通常采用測試先行的編碼方式來提供支持。

總結

優質工作這點是個人自覺問題，特別體現開發人員的個人素質，拖泥帶水這個問題經常出現在進度比較趕的情況下，但PM或者leader也不能在這點上面妥協，而且一般這種問題也不會消耗很多開發時間，都是一兩句代碼的事，有時只是開發人員懶得去修改而已。一旦妥協，以后這種情況必然反復出現。逐步修改這點除了開發人員實現，同時還需PM來配合，在迭代中進行微調，將更改控制在可控范圍，不會造成太大影響。

13個最佳實現

計劃游戲

計劃游戲的主要思想就是先快速地制定一份概要的計劃，然后隨著項目細節的不斷清晰，再逐步完善這份計劃。計劃游戲產生的結果是一套用戶故事及后續的一兩次迭代的概要計劃。

編寫故事：由客戶或者PM談論系統應該完成什么功能，確定需求。

進行估算：開發人員對每個用戶故事進行估算，先從高優先級開始估算。如果在估算的時候，感到有一些故事太大，不容易進行估算，或者是估算的結果超過2人/周，那么就應該對其進行分解，拆成2個或者多個小故事。

迭代周期：接下來就是確定本次迭代的時間周期，這可以根據實際的情況進行確定，不過最佳的迭代周期是2~3周。

小型發布

XP方法論秉承的是“持續集成，小步快走”的哲學，也就是說每一次發布的版本應該盡可能的小，當然前提條件是每個版本有足夠的商業價值，值得發布。

由于小型發布可以使得集成更頻繁，客戶獲得的中間結果也越頻繁，反饋也就越頻繁，客戶就能夠實時地了解項目的進展情況，從而提出更多的意見，以便在下一次迭代中計劃進去。以實現更高的客戶滿意度。

隱喻

創造心照不宣的詞匯和列子，更形象有趣的溝通。比喻有時候更能讓人更快更好的理解你的意思，而不是一堆晦澀專業術語。

簡單設計

簡單設計這個實現是一個很容易讓人誤解，也讓許多批評者詬病的一條實現，因為它秉承“夠用就好”的思路，盡量地簡單化，只要今天夠用就行，不考慮明天會發現的新問題，明明是擁抱變化，怎么又不考慮明天的問題了呢。而在傳統的開發中，需要我們考慮后期可能的需求，讓代碼做到高可擴展性，要求我們經?？紤]后期需求。這樣看起來，傳統開發在這個方面似乎比XP更貼近擁抱變化的思想，我們再仔細看看。

這里的簡單設計提出沒有重復代碼，盡量少的類和方法，使用迪米特法則等，只是針對今天而言，不要因為后期可能會用到，就添加了一個現在不用的類或者方法，而不是不做可擴展性，這兩者并不沖突。即使因為沒有考慮很多，而可拓展性沒有做到很好，XP提倡重構也能將擴展性提高一個檔次，而且更精確更符合現在的需求。而傳統的方式將一切考慮到位也不見得擴展性就完美，畢竟變化是不可預測的，現在考慮的擴展性在幾個月后可能也用不上了，到時必然也是要重構。

簡單設計從本質上來說擴展性就很強，就像一張白紙，要怎么畫都行，就看你能不能體會到其中的深度了。

測試驅動開發

這個是常規思維難以理解的概念，測試先行，程序都沒寫出了，怎么測試？參考資料的例子非常好：

• 工匠一：先拉上一根水平線，砌每一塊磚時，都與這跟水平線進行比較，使得每一塊磚都保持水平。
• 工匠二：先將一排磚都砌完，然后再拉上一根水平線，看看哪些磚有問題，對有問題的磚進行適當的調整。

工匠一代表的就是測試驅動開發的方法，當然為了有效的實現它，需要我們借助一些自動化測試工具。

XP鼓勵程序員原意甚至喜歡在編寫程序之前編寫測試代碼，所以提供了以下一些理由：

• 如果你已經保持了簡單的設計，那么編寫測試代碼根本不難。
• 如果你在結對編程，那么如果你想出一個好的測試代碼，那么你的伙伴一定行。
• 當所有的測試都通過的時候，你再也不會擔心所寫的代碼今后會“暗箭傷人”，那種感覺是相當棒的。
• 當你的客戶看到所有的測試都通過的時候，會對程序充滿前所未有的信心。
• 當你需要進行重構時，測試代碼會給你帶來更大的勇氣，因為你要測試是否重構成功只需要一個按鈕。

這樣的嘗試還是需要勇氣的，這也是XP的核心價值，不真正去使用去理解，一般人都會覺得天馬行空。

重構

重構時一種對代碼進行改進而不影響功能實現的技術，XP需要開發人員在聞到代碼的壞味道時，有重構代碼的勇氣。重構的目的是降低變化引發的風險，使得代碼優化更加容易。重構有時并不是需要做很大的修改，不用談虎色變，對于XP來說，它只是一個常規操作。

結對編程

簡單來說就是兩個人坐在一起寫程序，結對編程也是一個飽受質疑的舉措，一般認為它過于耗費人力資源，自尊心較強的開發人員也比較排斥結對編程。

當然結對編程也有結對編程的好處：

• 所有的設計決策確保不是由一個人做出的。
• 系統的任何一個部分都肯定至少有2個人以上熟悉。
• 幾乎不可能有2個人都忽略的測試項或者其他任務
• 結對組合的動態性，是一個企業知識管理的好途徑。
• 代碼總是能夠保證被評審過。

而且XP方法論集成的其他最佳實踐也能夠使得結對編程更加容易進行：

• 編碼標準可以消除一些無謂的分歧。
• 隱喻可以幫助結對伙伴更好地溝通。
• 簡單設計可以使得結對伙伴更了解他們所從事的工作。

結對編程還是要視情況使用，并不是有理論支持的就一定適用，如果覺得使用結對效率不高，還可以通過Leader審核代碼來替代。

集體代碼所有制

由于XP方法論鼓勵團隊進行結對編程，而且認為結對編程的組合應該動態地搭配，根據任務的不同、專業技能的不同進行最優組合。由于每個人都肯定會遇到不同的代碼，所以代碼的所有制就不再適合于私有，因為那樣會給修改工作帶來巨大的不便。

也就是說，團隊中的每個成員都擁有對代碼進行改進的權利，每個人都擁有全部代碼，也都需要對全部代碼負責。同時，XP強調代碼是誰破壞的（也就是修改后發生問題），就應該由誰來修復。

• 由于在XP項目中，集成工作是一件經常性得工作，因此當有人修改代碼而帶來了集成的問題，會在很快的時間內被發現。
• 由于每一個類都會有一個測試代碼，因此不論誰修改了代碼，都需要運行這個測試代碼，這樣偶然性的破壞發生的概率將很小。
• 由于每一個代碼的修改就是通過了結對的兩個程序員共同思考，因此通常做出的修改都是對系統有益的。
• 由于大家都堅持了相同的編碼標準，因此代碼的可讀性、可修改性都會比較好，而且還能夠避免由于命名法、縮進等小問題引發經常性得代碼修改。

持續集成

持續集成是指團隊每天盡可能多次的進行代碼集成，保證團隊獲取的代碼都是近期統一過的代碼，避免太多不一致造成沖突。而上文說的小型發布則是更多的發布測試版本，中間版本，讓客戶或者PM審核，確認功能開發沒有錯誤。需要我們引入代碼管理工具，版本控制工具。

可持續的速度

簡單來說，就是反對加班，將進度控制在合理的范圍，讓開發人員保持一個健康高效的狀態。

做到讓開發人員享受開發，而不是讓他們感受到了煎熬。

現場客戶

為了保證開發出來的結果與客戶的預想接近，XP方法論認為最重要的需要將客戶請到開發現場。就像計劃游戲中提到過的，在XP項目中，應該時刻保證客戶負責業務決策，開發團隊負責技術決策。因此，在項目中有客戶在現場明確用戶故事，并做出相應的業務決策，對于XP項目而言有著十分重要的意義。特別是在發布中間版本后，需要客戶進行體驗，確保業務功能正確。

編碼標準

如果你的團隊已經擁有編碼標準，就可以直接使用它，并在過程中進行完善。如果還沒有，那么大家可以先進行編碼，然后在過程中逐步總結出編碼規則，邊做邊形成。當然除了這種文字規范以外，還可以采用一些如自動格式化代碼工具之類的方法進行代碼規范。事實上，你只需要很好地貫徹執行其他的實踐并且進行通，編碼標準會很容易地浮現出來。

配合是關鍵

有句經典名言“1+1>2”最適合表達XP的觀點，Kent h3eck認為XP方法論的最大價值在于在項目中融會貫通地運用12個最佳實踐，而非單獨地使用。你當然可以使用其中的一些實踐，但這并不意味著你就運用了XP方法論。XP方法論真正能夠發揮其效能，就必須完整地運用12個實踐。你甚至可以跳出XP開發方法，和其他開發方法進行結合，只要是遵循敏捷宣言的方法，必定有它們共同之處，也有能夠相互配合，更加完善的地方。

作者：Frayne，個人博客：Frayne.githuh3.io/Agile/xp.html

本文由 @Frayne 原創發布于人人都是產品經理。未經許可，禁止轉載。