關(guān)于敏捷開(kāi)發(fā)的26個(gè)心得

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

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

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