xp作為一種還算年輕的軟體研發的方**目前應該可以說開始普及了。作為乙個軟體研發人員，我非常贊同xp理念，xp的理念中充滿了使專案成功的關鍵思想，而這些思想不僅僅是技術上的，而是很大一部分是管理與溝通方面的。xp整合了許多最佳實踐，而這些串連後的最佳實踐使整個專案又變的有趣起來，這其中也包括了xp開發人員特有的積極向上的態度與責任心。這裡我想向大家描述一下我個人的xp實踐感受……
下面我分別寫一下我對xp中其中12種最佳實踐的感受：
現場客戶(on-site customer)。客戶的需求不是一成不變的，往往在需求收集階段事情總是很抽象，就連客戶自己都不知道他們具體要什麼，他們只是提供乙個輪廓，要我們雙方共同去構造理想中的產品。但是我們，包括客戶都不可能**說我們現在定下來的需求就是真正的一成不變的需求，總是有千萬個理由會促使需求的變動，也就是說需求的變動是必不可免的，它不是單純的可以人為控制的。那現在的問題是，但需求變動時，我們有能力迎接（適應）它嗎？現在xp提出了幾種最佳實踐來迎接需求的變動，而其中一種既是on-site customer，通過客戶在整個專案中的不斷參與我們可以保證我們所作的一切都真正是客戶想要的，而我們不會浪費時間與精力在不需要的功能上。這是按時交貨，交好貨的一種關鍵做法。注意這個最佳實踐要求的並不是客戶每天8小時的參與專案，而是但我們需要客戶解答某些需求疑問時，客戶能及時的提出意見，給出反饋！
小發行版(**all releases)。上面提到了需要客戶能及時給出反饋，那麼及時得到反饋的一種好的做法就是提供給客戶軟體的預覽版，畢竟沒有實物客戶很難提出他們對我們正在做的專案的看法。xp要求小發行版正是這個用意，通過快速的小的迭代開發得到很多的小版本，然後將這些小版本拿給使用者體驗，收集反饋，再根據使用者的反饋繼續下乙個小版本的迭代開發，這是乙個良性迴圈，保證了專案不走歪路，保證了客戶對我們正在做什麼沒有偏見，同時也保障了專案的質量，因為直接參與測試的同時也有我們的客戶。
簡單的設計(****** design)。上面講的是從需求的角度出發的，現在讓我們來看看開發流程方面。我們都知道設計是好的，而事物總是保持越簡單越好，那麼為什麼不選擇簡單的設計呢？通過簡單的設計我們可以快速的理解與開發。但是但靠簡單的設計往往不是很有作用，很快我們就發現以往的設計已經不再有彈性，很快就不能滿足我們的需要了。這裡就是體現xp精華概念的時候了，xp中有極限一詞，也就是說不管是做什麼，都要做到極限。簡單的設計也不例外，同樣也要不斷的迭代，通過在簡單的設計上重構出另一種簡單的設計來不斷改變設計與設計質量，會讓你在不知不覺間作出與超級設計大師一樣優質的設計。（當然，如果你真的很糟糕，那麼即使xp再好我想也幫不了你了）
規劃策略(planning game)。既然簡單的設計有助於快速的進展那麼不斷的規劃也一定會幫助到專案的方方面面。很難說架構師做好的架構就一定不會在後期改變，既然需求都很有可能有大改變，那麼架構與整體專案規劃也不是一成不變的。這是xp的核心，xp告訴你如何迎接變化，如何在快速變化的今天作出最優質的產品，真正滿足客戶的需求。
系統隱喻(system metaphor)。說實話，我也是剛剛開始真正了解xp，所以對這個實踐還不太了解，所以這裡就不談了，免得敗壞xp的名聲！^_^
重構(refactoring)。我想很少有人在這個年代沒有聽到過重構吧？上面所講的很多方面都是基於這個思想的。既然設計是好的，那麼我們能不能快速的、小步的迭代設計呢？能不能通過不斷的改善已有的**來使它們更健壯呢？目前的專案大多數都會在維護一段時間後變的僵硬，**越來越難以維護，有時不得不寫一些自己都認為很難看的**來維護新增或修改的功能，而正是這樣的動作導致了下一次維護時的困難，使**陷於了惡性迴圈，使的專案的維護成本越來越高，最後不得不放棄維護而重新開發。xp提出了迭代的重構方案，它使我們每一次都先重構再在重構好的**的基礎上再做修改，這使得我們每次都不用花太多的精力去完成對**的維護而又與此同時提高了**的簡易度、健壯度。
結對程式設計(pair programming)。既然對設計、對**的評審是好的，那麼為什麼不隨**審呢？通過評審，我們可以用多個人的腦袋想問題，尋找解決方案，無疑這要比只用乙個腦袋要好的多，畢竟人多力量大嘛，曾經也有教育家做過試驗，證明了在群組討論學習的環境下學生學到的知識更深刻，理解的更透徹，思想也更活躍。軟體開發又何嘗不是如此呢？我不完全贊成「結對」，但是我贊成有問題就問，不管什麼樣的問題，不管什麼樣的同事，只要你有疑問，那麼你就可以向大家提出來，看看每個人的想法，這會使你最終得到乙個當前最好的解決方案。
集體所有權(collective ownership)。在上個實踐中其實已經提到了這個集體所有權的概念，既然你有問題就可以問，別人又都參與你給你他們認為的可能性答案，那麼是不是反過來但別人有問題的時候你也要主動參與提出自己的看法呢？這種把多個大腦運作在一起的模式就是xp中集體所有權的概念了，在這裡沒有個人的殊榮，只有團體與團體的共同目標。注意這裡就是xp的特點了，xp是以人為本，xp堅信人與人之間的作用要比單純的依靠技術要更重要的多。畢竟只有最後依靠到人心上，專案才可能獲得最後的成功。而作為一名xp開發人員也意味著你的個人休養與風格。
編碼規範(code standards)。**在xp中被看作一項非常重要的在開發人員之間溝通的工具。畢竟軟體反映了開發者的心智，開發人員的思想變為一行行**被寫在程式中，這是一門藝術。但藝術也要有人去欣賞，如果每個人都看不懂其他人的藝術，那麼怎麼進行溝通呢？集體所有權讓我們每個人都可以去改進其他人的**，那麼如果沒有統一的編碼規範將不是一件容易的事了。
一周40小時(40-hour week)。xp不主張加班加點，這只能是當有某些環節出問題的前兆。xp在每次快速的迭代中都很明確下一次迭代要做什麼，xp有很高的可控性。
測試(testing)。測試是xp的核心部分，是xp重要的環節，也正是處於這種原因，我將兩種測試放在了最後面介紹，不是因為它們不重要，而相反是因為它們太重要了！測試其根本目的是為了保證質量，告訴我們所作的一切沒有白做，它的確可行。xp中的自動化測試（常指簡單有效的單元測試）是非常關鍵的，它有多重目的。其中乙個很重要的目的就是給予我們開發人員信心，試想每次系統變動後執行自動化測試時看到一排路燈亮著是那麼暢快的一件事啊！xp主張先測試後編碼，每次的測試用例都能夠反映出最確切的需求，測試亦是設計的一部分。其中的奧妙真的是只有真正用過才能體會得到。
持續整合(continuous integration)。這是另一種保證質量的測試手段，通過反覆快速的整合我們可以及早發現軟體中的隱患，同時持續整合也可以提供給我們多個小版本(**all releases)以便客戶的反饋。這個概念比較像微軟提出的每日編譯，只是xp並沒有規定必須每日執行一次，xp反而主張每幾個小時甚至每幾分鐘整合一次，總之就是當有較大變動時就及時整合給出反饋，這一點也能夠充分的體現出xp極限程式設計中的極限來！
十二種實踐方法與我的XP心得
xp作為一種還算年輕的軟體研發的方 目前應該可以說開始普及了。作為乙個軟體研發人員，我非常贊同xp理念，xp的理念中充滿了使專案成功的關鍵思想，而這些思想不僅僅是技術上的，而是很大一部分是管理與溝通方面的。xp整合了許多最佳實踐，而這些串連後的最佳實踐使整個專案又變的有趣起來，這其中也包括了xp開發...
十二種實踐方法與我的XP心得
十二種實踐方法與我的xp心得 收藏 xp 作為一種還算年輕的軟體研發的方 目前應該可以說開始普及了。作為乙個軟體研發人員，我非常贊同xp理念，xp的理念中充滿了使專案成功的關鍵思想，而這些思想不僅僅是技術上的，而是很大一部分是管理與溝通方面的。xp整合了許多最佳實踐，而這些串連後的最佳實踐使整個專案...
XP的十二種方法
xp的十二種方法將其定義為規則，下面我們來簡單地看看到底是哪十二種 極限 方法 b 規劃策略 the planning game b b 結對程式設計 pair programming b 就是在開發中兩個程式設計師一起編寫乙個專案的一種技術。兩個程式設計師工作在同一臺機器上，當乙個程式設計師在寫 ...