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

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

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

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

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

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