一個資深程序員的敏捷開發心得

我收集各式各樣的至理名言。最近我一直在研究敏捷軟件開發；有收穫嗎？

奉上可以指導敏捷軟件開發團隊的24條核心原則。

1.用例一徹底可以運行後再開發用例二

廚房裏有一種說法正好能夠印證這個問題：「作好一盤菜後你再作下一盤」．對於軟件開發來講一個最大的問題就是人們喜歡並行開發多個任務。由於不可避免的，咱們設計的功能中總會有一部分會被放棄砍掉，若是提早開發，極可能作無用功。一次只開發一個用例（或不多幾個用例，這根據你的開發團隊的大小而定）；讓這個用例功能完整；讓相應的測試用例都能經過；相應的文穩都補齊；只有在當前的用例徹底開發完成後，才作爲一個總體提交到版本庫，才進行下一個用例。

2.避免提交一個半成品

避免提交一個半成品。這一點你們彷佛都知道，但這條原則必須列入任何一個開發指導裏。可以聽取這些忠告進行開發測試而後提交代碼的程序員必定不會發生代碼提交到版本庫使整個項目沒法編譯碼經過狀況。若是系統編譯失敗，那必定是有人抄近道到了。

3.必定不要在沒有使用例的狀況下往類裏添加成員方法

必定不要在沒有使用例的狀況下往類裏添加成員方法。這跟上面一條極其類似，除了這裏針對的是數據成員。開發人員很容易想到：一個‘客戶記錄’裏應該有‘送貨地址’的信息，但必定不要在沒有任何用例要求這個屬性的時候實現這個屬性。

4.不要懼怕作決定；不要懼怕改變之前的決定

不要懼怕作決定；不要懼怕改變之前的決定。敏捷開發的目的是應對客戶需求的不肯定。開發前期你不可能獲到所有的信息。你應該儘量的拖延作決定的時間，但一旦到了你該作決定的時候，你應該當機立斷，讓項目向前推動。你不能說一直等到有了足夠的信息才作決定。相反，你要依賴現有的信息做出最正確們決定。以後，當有新的信息出現後，不要懼怕對之前的決定做出更改。(老輩人有的稱之爲觸發器，但我稱之爲隨環境而變)

5.不斷地瞭解如何改進系統

不斷的瞭解如何改進系統。這項工做沒有盡頭，你應該作好思想準備，持續不斷的尋找能夠改進的地方，收集各類關於如何找到質量問題、解決質量問題的案例。

6.不要在尚未任何使用案例的狀況下設計通用模塊

只有在你知道有具體用例的狀況下，你才能夠實現一個具體的類，並且你在該類中只應該實現當前該用例須要的方法。你也許會想到未來這個類會有其它的用途，你能夠用註釋的方式記錄一下，但不要去實現它，只有在有了具體用例後你才能夠實現它。

7.審查，審查，審查

審查，審查，審查。敏捷開發能夠幫助咱們應對需求在未來的不肯定，但過去的事情也存在不肯定性。測試工做永遠不能停下來。程序每次運行的表現都要被評審和記錄。

8.軟件的設計要以人爲本，而不是系統

軟件的設計要以人爲本，而不是系統。不少開發人員退而求其次、以技術爲中心，讓設計爲技術服務。永遠不要忘記軟件的終極目標是什麼，是幫助人們完成工做。

9.測試是產品的一部分

測試是產品的一部分。許多開發人員和經理都認爲產品就是你打包給客戶的東西，其他的都不重要。其實測試也應該看做是產品的實際一部分，應該在設計時給予至關的重視，甚至，在不少時候，測試功能也應該同產品一塊兒提交給客戶。（後面說的這部分不少人都不承認，一個內置的能自我測試軟件包並不會佔用多少額外的資源，但當你須要用到它時，你會發現它的巨大價值。)

10.先寫測試用例，後寫代碼

先寫測試用例，後寫代碼。測試用例能夠用來精確的說明咱們的設計需求。不少時候咱們都是經過運行測試用例後發現咱們的設計中存在問題。想一想吧，先寫測試用例後編碼能節省多少時間。可是：寫完測試用例1，而後編寫用例1，完後纔開始用例2。

11.清理垃圾代碼

清理垃圾代碼。很顯然，又是一個盡人皆知的道理，但它也必須寫入任何的開發原則裏，由於它是如此的重要。查找垃圾代碼的工做永遠沒有盡頭，找到它，消滅它。要去除掉全部的不能給實際用戶帶來價值的代碼。若是你不能指出某段代碼對用戶有什麼用處，那它極可能就是沒用的。

12.培養對集成失敗問題當即作出反應的習慣

培養對集成失敗問題當即作出反應的習慣。你要明白，當集成構建失敗時，它會影響項目中的每個人，因此沒有比讓核心程序能正確的集成和測試經過更重要的事情了。我曾經見到過有的團隊的集成構建中斷幾個月都不去管它，由於他們有其餘的工做要作。每一個人都在忍受這種狀況，但沒人採起措施。咱們應該明白，應該普遍的認識到，只要作出一點點工做，整個的團隊會所以獲得很是大的回報。

13.團隊的每一個成員都要知道客戶的需求

團隊的每一個成員都要知道客戶的需求。大型複雜的項目必需要分割到幾個獨立的團隊去開發，而後派發到每一個開發人員的手中，但這絕對不能變成程序員能夠不明白最終產品的使用用戶的需求和目標是什麼。

14.把意義相關的東西放在一塊兒

把意義相關的東西放在一塊兒。組織好代碼，讓高度相關的東西都放在一塊兒，也就是放在一個類裏。這是標準的面向對象設計原則裏的封裝的概念。理想狀況下，類以外的程序並不須要知道類裏面的工做細節。有些開發人員喜歡把代碼放到好幾個文件裏，這樣是爲了按另外一種方式組織它們：例如把相同的數據類型的放到一塊兒，或按字母順序分類。舉個例子，有人會把全部的常量放在單獨一個包下的一個類裏，他們這樣作毫無必要，增長了程序的複雜性。按照指導原則，它們應該按照相關性進行分組，從而減小複雜性。

15.先測試後提交代碼

先測試後提交代碼。這個準則能讓你確保「永遠不要讓集成構建失敗」的準則。

過早優化是災難之源這句話是引用DonKnuth的，今天聽起來一點不錯。在內核裏的代碼應該盡力的寫好來避免不要的浪費，但針對高於單個方法的級別的優化應該在整個項目測試經過、針對最終實際用戶的壓力測試用例經過以後才能進行。僅僅根據靜態的代碼來判斷哪些是影響整個性能最主要的問題的論斷每每是錯誤的。相反，評審整個系統的運行表現，找出真正影響性能的1%的代碼，只針對這些代碼作優化。

16.最小化未完成的編碼任務的工做包（backlog）

最小化未完成的編碼任務的工做包（backlog）。當開發人員開發一個設計用例時，有的功能會牽涉到全部修改着的但未徹底開發完成、充分測試的代碼。把未修改完成的代碼保存到本地數天或數星期，這樣增長了工做浪費的風險，會出現返工。想象有三個任務，每一個估計都要一天。若是三個一塊兒開發，並行起來每一個都須要3天，這樣一累計會有9個’單位’的風險。若是順序的開發，一個開發完成後再開發另外一個，只會有3個‘單位’的風險。這個並不符合咱們的直覺。咱們的直覺告訴咱們，當咱們在這種狀況下時，咱們但願三個一塊兒完成。可是軟件不像蓋房子。小的、迅速的、完整的任務不只僅會下降咱們的認知負荷，也減小了進行中的開發對其餘人正在進行的開發的相互影響。

不要過分功能範化。也就是咱們所說的「YAGNI–You Aren’t Going to Need It」。程序員在編寫一個類時喜歡料想：這個類可能在其它地方其它類中會有其它用途用．若是這些用途是被當前的用例用到，那這樣思考是沒錯的，但經常開發人員想到的這些用途都是目前不存在的用途，實際上多是永遠不會用到的用途。 IIS7站長

17.若是兩行代碼能完成就不要寫成三行

若是兩行代碼能完成就不要寫成三行。簡潔的代碼永遠都會給須要閱讀這段代碼的人帶來好處。但千萬不要把代碼壓縮的難以理解了。精簡的、書寫規範的代碼易於維護和查找錯誤，冗長的、太多修飾的代碼則相反。儘量的簡化但不要過分。

18.永遠不要按行數多少來評價代碼頭

永遠不要按行數多少來評價代碼頭。編寫某個任務所產生的代碼行數會因程序員而異，因編碼風格而異。代碼的行數不會提供任何關於程序完成狀況和代碼質量的信息。代碼質量能夠相差200倍之多，這是計算代碼行數的方法不能勝任的。應該計算功能性的用例數。

19.咱們應不斷地再設計、再分析

咱們應不斷的再設計、再分析。應用這一條時你要很是的當心，由於有些代碼很脆弱、難以維護。但不要懼怕修改這些代碼、讓它符合真正的需求。一個數據成員之前是整數型的，但如今有個用例須要它是浮點型，不要懼怕去改變它，只要你按步驟：測試，寫文檔，佈署。

20.刪除死代碼

刪除死代碼。當發現有一大段不能理解的代碼時咱們習慣的作法是「讓死狗躺在哪」。好比說，咱們須要往類裏添加一個新方法來替換之前的舊方法，通用人們會保留老方法‘以防不測’。其實，咱們應該花一些功夫去檢查看看這個老方法是否還有用，若是沒有證據顯示它還有用，就該刪掉它。更糟糕的錯誤作法是把這些代碼註釋掉，留下一堆註釋碼。註釋掉的代碼一旦發現就該被刪掉，不能留到測試時還有、甚至提交到代碼庫。添加代碼老是容易的，刪除代碼老是困難的。所以，一旦發現有可能沒用的代碼，你應該花點時去確認它、刪除它，這樣會讓代碼更加可維護。

21.不要自創新語言

不要自創新語言。程序員喜歡使用文本文件來實現功能性的趨動，這樣可使程序變的可配置。經過配置文件來改變軟件行爲所產生的後果是不過控的。XML的誕生促使了一系列的特別的自定義的‘腳本語言‘的出現，人們試圖經過文件的配置以讓最終用戶‘編程’來控制軟件的功能、避免從新編譯。這種設計上的缺陷是：軟件裏的各類操做的準肯定義在脫離了具體上下文的特定實現的狀況下不可能被準確的定義。這些各式各樣的腳本型語言只是對那些對軟件代碼的內部工做機理有着相關的知識背景的人才會價值。因此，真正的最終用戶是不可能知道軟件的內部工做機理的，不可能推理出這些複雜的指令組合會產生什麼樣的預期結果。腳本有它的用途，也不該該被抵制，但設計人員必須以很是很是安全的方式使用它們，儘量使用現有的語言，必免使用新發明的語言。

22.只有當準備好了實現和測試纔去肯定設計

只有當準備好了實現和測試纔去肯定設計。我應該有一個整體的認識咱們要作什麼，應該有個整體架構目標，而不是詳細設計、詳細的具體方法的實現，只有當開發迭代到必定程度後、足以讓咱們定下設計細節後纔去把它表現成文檔。詳細設計只應該包括當前需求用例中須要覆蓋的部分。軟件開發中最大的浪費就是你花時間設計出來東西后被告知不須要了，或者是你的設計一開始就創建在錯誤的假設上。

23.軟件是可塑的

軟件是可塑的。軟件不像蓋房子，咱們能夠輕易的改的面目全非。無數事實代表軟件比它的規格說明書善變的多。並且，軟件產品和設計之間的互動明顯比規格說明書有效率。因此，你應該直接實現你的設計，這樣客戶就能很容易明白你的設計細節。當發現有問題、要改變設計時，修改軟件要比修改文檔容易的多。更重要的是，當客戶看到了能運行的程序後，你也就更能搞清客戶的需求是什麼了。

24.對被檢測到的和被報告的異常狀況請多花一點時間對其進行詳細描述

對被檢測到的和被報告的異常狀況請多花一點時間對其進行詳細描述。程序員通常都很是的懶，拋出異常時只描述錯誤的表面現象。設想若是隻是做者本身會遇到這種錯誤，他會記得這種一直使用的錯誤描述信息是什麼意思。但站在客服技術支持的處境，他們由於這種不許確的、不完整的錯誤描述浪費了大量時間。這些信息應該達到讓一個剛走進屋裏沒有任何經驗的人能看明白的程度。客戶和客服基本都是對編程不懂的人。