【推薦】極限編程的十二大原則——前言

解讀極限編程的十二大原則

前言

作為軟體開發人員，我們很羨慕那些商業軟體的開發人員，比如Windows，因為感覺它們的開發人員很幸福，不會說哪個使用者提出來某個功能就馬上去修改程式，甚至當使用者使用這些軟體的時候出現了問題首先都會懷疑是不是自己的操作出了問題。

不幸的是我們很多開發人員從事的是行業軟體、定製軟體的開發，總會聽到定製的聲音，總會感到需求的不斷改變，總會感到軟體永遠沒有穩定下來的日子，總會感到修改的日子沒有盡頭。管理員也很頭疼，按照研發規範的要求，開發人員必須在編寫代碼的同時編寫設計文檔，然而不斷的修改最終使得文檔的編寫成了累贅，於是：

n         我們的文實一致性得不到保證

n         我們的設計文檔成了“廢物”，甚至誤導

n         我們的新員工花費了大量的時間閱讀文檔卻發現不如去直接讀程式

n         我們加班卻總是發現有永遠幹不完的事情

n         ……

傳統軟體工程中對軟體開發過程的定義在這種需求變化頻繁、卻要求快速交付的軟體開發實踐中顯得那麼的無助。大家都在困惑，在尋找出路，於是，當我第一次在ThoughtWorks的網站上看到關於極限開發的理念時，很激動，開始了關於極限開發的學習，也嘗試根據自己的理解在工作中實踐。網上關於極限開發的爭論一直都很多，關於這套理論並不是一切問題的終結者，但是隨著學習和思考的深入，我日益感覺到極限開發理念為我們提供了一個新的思維方式：原來，我們可以這樣思考問題！比喻的說就是我們的開發模式如思想般已經僵化了，需要一種新的聲音來灌輸新的活力，只有思維活躍了，才能創新，作為開發人員不光是技術需要創新，思維更要創新。更重要的是，我覺得對於硬體開發，極限開發理念中一樣有其可以借鑒的地方。

 

希望能夠通過根據自己的體驗解讀有關極限編程的十二大原則，來吸引更多的志同道合者一起對我們的工作進行思考和改良。

 

附錄：極限編程的十二大原則

1.計劃的制定：包括客戶選擇的項目大小、程式功能的優先順序、各個版本的合成和發布日期。

2.小版本：用最少的代碼工作量帶來最大的業務價值。

3.簡單設計：通過所有測試，沒有重複和費解的邏輯代碼，簡單的設計能保證代碼的簡單。

4.測試：一個功能存在的前提是有一個測試能夠驗證它，任何有被破壞的可能的代碼就必須有一個對應的測試。

5.持續整合：大量減少在整合中耗費的時間，減少團隊開發問題。

6.重構：確保加入新功能後代碼仍保持簡單，從而保證簡單的代碼仍然能夠運行所有的測試。

7.配對編程：提供持續的資訊反饋和確保正在編程的人進行重構、測試和遵守編碼通訊協定，實現代碼共用目的。

8.代碼共用：在通過測試的前提下，任何一個人都能夠對系統做出修改。

9.每周只工作40小時：充分利用你的時間，一個星期工作40小時已經足夠了。

10.現場客戶：討論，使用程式員和客戶都能夠的語言描述功能。

11.隱喻：普通語言和術語的集合，用來預見項目中的功能。

12.編碼通訊協定：遵守編碼通訊協定，讓其它程式員明白代碼，減少不必要的溝通。