我收集各式各樣的至理名言。最近我一直在研究敏捷軟件開發(fā)；有收獲嗎？下面就是能夠指導敏捷軟件開發(fā)團隊的26條核心原則。

• 用例一完全能夠運行后再開發(fā)用例二。廚房里有一種說法正好可以印證這個問題：“做好一盤菜后你再做下一盤”． 對于軟件開發(fā)來說一個最大的問題就是人們喜歡并行開發(fā)多個任務。因為不可避免的，我們設計的功能中總會有一部分會被放棄砍掉，如果提前開發(fā)，很可能做無用功。 一次只開發(fā)一個用例（或很少幾個用例，這根據(jù)你的開發(fā)團隊的大小而定）；讓這個用例功能完整； 讓相應的測試用例都能通過；相應的文穩(wěn)都補齊；只有在當前的用例完全開發(fā)完成后，才做為一個整體提交到版本庫，才進行下一個用例。
• 避免提交一個半成品。 這一點大家似乎都知道，但這條原則必須列入任何一個開發(fā)指導里。 能夠聽取這些忠告進行開發(fā)測試然后提交代碼的程序員一定不會發(fā)生代碼提交到版本庫使整個項目無法編譯碼通過情況。 如果系統(tǒng)編譯失敗，那一定是有人抄近道到了。
• 不要在還沒有任何使用案例的情況下設計通用模塊。 只有在你知道有具體用例的情況下，你才可以實現(xiàn)一個具體的類，而且你在該類中只應該實現(xiàn)當前該用例需要的方法。 你也許會想到將來這個類會有其它的用途，你可以用注釋的方式記錄一下，但不要去實現(xiàn)它，只有在有了具體用例后你才可以實現(xiàn)它。
• 一定不要在沒有使用例的情況下往類里添加成員方法。 這跟上面一條極其相似，除了這里針對的是數(shù)據(jù)成員。 開發(fā)人員很容易想到：一個‘客戶記錄’里應該有‘送貨地址’的信息，但一定不要在沒有任何用例要求這個屬性的時候?qū)崿F(xiàn)這個屬性。
• 不要害怕做決定；不要害怕改變以前的決定。 敏捷開發(fā)的目的是應對客戶需求的不確定。 開發(fā)前期你不可能獲到全部的信息。 你應該盡可能的拖延做決定的時間，但一旦到了你該做決定的時候，你應該當機立斷，讓項目向前推進。 你不能說一直等到有了足夠的信息才做決定。 相反，你要依賴現(xiàn)有的信息作出最正確們決定。 之后，當有新的信息出現(xiàn)后，不要害怕對以前的決定作出更改。 (老輩人有的稱之為觸發(fā)器，但我稱之為隨環(huán)境而變)
• 不斷的了解如何改進系統(tǒng)。 這項工作沒有盡頭，你應該做好思想準備，持續(xù)不斷的尋找可以改進的地方，收集各種關(guān)于如何找到質(zhì)量問題、解決質(zhì)量問題的案例。
• 審查，審查，審查。 敏捷開發(fā)可以幫助我們應對需求在將來的不確定，但過去的事情也存在不確定性。 測試工作永遠不能停下來。 程序每次運行的表現(xiàn)都要被評審和記錄。
• 軟件的設計要以人為本，而不是系統(tǒng)。 很多開發(fā)人員退而求其次、以技術(shù)為中心，讓設計為技術(shù)服務。 永遠不要忘記軟件的終極目標是什么，是幫助人們完成工作。
• 測試是產(chǎn)品的一部分。 許多開發(fā)人員和經(jīng)理都認為產(chǎn)品就是你打包給客戶的東西，其余的都不重要。 其實測試也應該看作是產(chǎn)品的實際一部分，應該在設計時給予相當?shù)闹匾暎踔粒诤芏鄷r候，測試功能也應該同產(chǎn)品一起提交給客戶。 （后面說的這部分很多人都不認可，一個內(nèi)置的能自我測試軟件包并不會占用多少額外的資源，但當你需要用到它時，你會發(fā)現(xiàn)它的巨大價值。)
• 先寫測試用例，后寫代碼。 測試用例可以用來精確的說明我們的設計需求。 很多時候我們都是通過運行測試用例后發(fā)現(xiàn)我們的設計中存在問題。 想想吧，先寫測試用例后編碼能節(jié)省多少時間。 但是：寫完測試用例1，然后編寫用例1，完后才開始用例2。
• 清理垃圾代碼。 很顯然，又是一個盡人皆知的道理，但它也必須寫入任何的開發(fā)原則里，因為它是如此的重要。 查找垃圾代碼的工作永遠沒有盡頭，找到它，消滅它。 要去除掉所有的不能給實際用戶帶來價值的代碼。 如果你不能指出某段代碼對用戶有什么用處，那它很可能就是沒用的。
• 培養(yǎng)對集成失敗問題立即做出反應的習慣。 你要明白，當集成構(gòu)建失敗時，它會影響項目中的每一個人，所以沒有比讓核心程序能正確的集成和測試通過更重要的事情了。 我曾經(jīng)見到過有的團隊的集成構(gòu)建中斷幾個月都不去管它，因為他們有其他的工作要做。 每個人都在忍受這種情況，但沒人采取措施。 我們應該明白，應該廣泛的認識到，只要做出一點點工作，整個的團隊會因此得到非常大的回報。
• 團隊的每個成員都要知道客戶的需求。 大型復雜的項目必須要分割到幾個獨立的團隊去開發(fā)，然后派發(fā)到每個開發(fā)人員的手中，但這絕對不能變成程序員可以不明白最終產(chǎn)品的使用用戶的需求和目標是什么。
• 把意義相關(guān)的東西放在一起。 組織好代碼，讓高度相關(guān)的東西都放在一起，也就是放在一個類里。 這是標準的面向?qū)ο笤O計原則里的封裝的概念。 理想情況下，類之外的程序并不需要知道類里面的工作細節(jié)。 有些開發(fā)人員喜歡把代碼放到好幾個文件里，這樣是為了按另一種方式組織它們：例如把相同的數(shù)據(jù)類型的放到一起，或按字母順序分類。 舉個例子，有人會把所有的常量放在單獨一個包下的一個類里，他們這樣做毫無必要，增加了程序的復雜性。 按照指導原則，它們應該按照相關(guān)性進行分組，從而減少復雜性。
• 先測試后提交代碼。 這個準則能讓你確保“永遠不要讓集成構(gòu)建失敗”的準則。
• 過早優(yōu)化是災難之源 這句話是引用Don Knuth的，今天聽起來一點不錯。 在內(nèi)核里的代碼應該盡力的寫好來避免不要的浪費，但針對高于單個方法的級別的優(yōu)化應該在整個項目測試通過、針對最終實際用戶的壓力測試用例通過之后才能進行。 僅僅根據(jù)靜態(tài)的代碼來判斷哪些是影響整個性能最主要的問題的論斷往往是錯誤的。 相反，評審整個系統(tǒng)的運行表現(xiàn)，找出真正影響性能的1%的代碼，只針對這些代碼做優(yōu)化。
• 最小化未完成的編碼任務的工作包（backlog）。 當開發(fā)人員開發(fā)一個設計用例時，有的功能會牽涉到所有修改著的但未完全開發(fā)完成、充分測試的代碼。 把未修改完成的代碼保存到本地數(shù)天或數(shù)星期，這樣增加了工作浪費的風險，會出現(xiàn)返工。 想象有三個任務，每個估計都要一天。 如果三個一起開發(fā)，并行起來每個都需要3天，這樣一累計會有9個’單位’的風險。 如果順序的開發(fā)，一個開發(fā)完成后再開發(fā)另一個，只會有3個‘單位’的風險。 這個并不符合我們的直覺。 我們的直覺告訴我們，當我們在這種情況下時，我們希望三個一起完成。 但是軟件不像蓋房子。 小的、迅速的、完整的任務不僅僅會降低我們的認知負荷，也減少了進行中的開發(fā)對其他人正在進行的開發(fā)的相互影響。
• 不要過度功能范化。 也就是我們所說的“YAGNI – You Aren’t Going to Need It” 。 程序員在編寫一個類時喜歡料想：這個類可能在其它地方其它類中會有其它用途用． 如果這些用途是被當前的用例用到，那這樣思考是沒錯的，但常常開發(fā)人員想到的這些用途都是目前不存在的用途，實際上可能是永遠不會用到的用途。 (This subject always reminds me of the classic Saturday Night Live skit about the product which was both a floor wax, and a dessert topping.)
• 如果兩行代碼能完成就不要寫成三行。 簡潔的代碼永遠都會給需要閱讀這段代碼的人帶來好處。 但千萬不要把代碼壓縮的難以理解了。 精簡的、書寫規(guī)范的代碼易于維護和查找錯誤，冗長的、太多修飾的代碼則相反。 盡可能的簡化但不要過度。
• 永遠不要按行數(shù)多少來評價代碼頭。 編寫某個任務所產(chǎn)生的代碼行數(shù)會因程序員而異，因編碼風格而異。 代碼的行數(shù)不會提供任何關(guān)于程序完成情況和代碼質(zhì)量的信息。 代碼質(zhì)量可以相差200倍之多，這是計算代碼行數(shù)的方法不能勝任的。 應該計算功能性的用例數(shù)。
• 我們應不斷的再設計、再分析。 應用這一條時你要非常的小心，因為有些代碼很脆弱、難以維護。但不要害怕修改這些代碼、讓它符合真正的需求。 一個數(shù)據(jù)成員以前是整數(shù)型的，但現(xiàn)在有個用例需要它是浮點型，不要害怕去改變它，只要你按步驟：測試，寫文檔，布署。
• 刪除死代碼。 當發(fā)現(xiàn)有一大段不能理解的代碼時我們習慣的做法是“讓死狗躺在哪”。 比如說，我們需要往類里添加一個新方法來替換以前的舊方法，通用人們會保留老方法‘以防不測’。 其實，我們應該花一些功夫去檢查看看這個老方法是否還有用，如果沒有證據(jù)顯示它還有用，就該刪掉它。 更糟糕的錯誤做法是把這些代碼注釋掉，留下一堆注釋碼。 注釋掉的代碼一旦發(fā)現(xiàn)就該被刪掉，不能留到測試時還有、甚至提交到代碼庫。 添加代碼總是容易的，刪除代碼總是困難的。 因此，一旦發(fā)現(xiàn)有可能沒用的代碼，你應該花點時去確認它、刪除它，這樣會讓代碼更加可維護。
• 不要自創(chuàng)新語言。 程序員喜歡使用文本文件來實現(xiàn)功能性的趨動，這樣可以使程序變的可配置。 通過配置文件來改變軟件行為所產(chǎn)生的后果是不過控的。 XML的誕生促使了一系列的特別的自定義的‘腳本語言‘的出現(xiàn)，人們試圖通過文件的配置以讓最終用戶‘編程’來控制軟件的功能、避免重新編譯。 這種設計上的缺陷是：軟件里的各種操作的準確定義在脫離了具體上下文的特定實現(xiàn)的情況下不可能被準確的定義。這些各式各樣的腳本型語言只是對那些對軟件代碼的內(nèi)部工作機理有著相關(guān)的知識背景的人才會價值。 所以，真正的最終用戶是不可能知道軟件的內(nèi)部工作機理的，不可能推理出這些復雜的指令組合會產(chǎn)生什么樣的預期結(jié)果。 腳本有它的用途，也不應該被抵制，但設計人員必須以非常非常安全的方式使用它們，盡可能使用現(xiàn)有的語言，必免使用新發(fā)明的語言。
• 只有當準備好了實現(xiàn)和測試才去確定設計。 我應該有一個總體的認識我們要做什么，應該有個總體架構(gòu)目標，而不是詳細設計、詳細的具體方法的實現(xiàn)，只有當開發(fā)迭代到一定程度后、足以讓我們定下設計細節(jié)后才去把它表現(xiàn)成文檔。 詳細設計只應該包括當前需求用例中需要覆蓋的部分。 軟件開發(fā)中最大的浪費就是你花時間設計出來東西后被告知不需要了，或者是你的設計一開始就建立在錯誤的假設上。
• 軟件是可塑的。 軟件不像蓋房子，我們可以輕易的改的面目全非。 無數(shù)事實表明軟件比它的規(guī)格說明書善變的多。 而且，軟件產(chǎn)品和設計之間的互動明顯比規(guī)格說明書有效率。 所以，你應該直接實現(xiàn)你的設計，這樣客戶就能很容易明白你的設計細節(jié)。 當發(fā)現(xiàn)有問題、要改變設計時，修改軟件要比修改文檔容易的多。 更重要的是，當客戶看到了能運行的程序后，你也就更能搞清客戶的需求是什么了。
• 對被檢測到的和被報告的異常情況請多花一點時間對其進行詳細描述。 程序員一般都非常的懶，拋出異常時只描述錯誤的表面現(xiàn)象。 設想如果只是作者自己會遇到這種錯誤，他會記得這種一直使用的錯誤描述信息是什么意思。 但站在客服技術(shù)支持的處境，他們因為這種不準確的、不完整的錯誤描述浪費了大量時間。 這些信息應該達到讓一個剛走進屋里沒有任何經(jīng)驗的人能看明白的程度。 客戶和客服基本都是對編程不懂的人。

　　上面這些條目沒有特別的順序。 歡迎對這些我匯總的指導原則進行評論，也許你并不認可其中的幾條，也請發(fā)表你們意見。

　　【英文出處】：26 Hints for Agile Software Development

it知識庫：關(guān)于敏捷開發(fā)的26個心得，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。