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