敏捷開發的26條至理名言 快速迭代式開發使用方法總結
阿新 • • 發佈：2018-12-24
2、不要破壞構建：非常明顯，但必須被包含在任何軟體開發建議清單中。程式設計師在簽入之前採取所有合適的預防措施進行測試，則永遠不會破壞構建。如果構建被破壞，通常是因為有人偷懶了。
3、在用例需要之前，不要實現程式：當你實現一個特定的類，你應該在腦海中有一個特定的用例，同時應該只實現用例需要的方法。你可以考慮該類潛在的功能，寫入註釋之中，但直到用例真正需要時，才應去實現它。
4、在用例需要之前，不要新增資料成員：同上一條，不過這是從類的資料成員角度考慮的。似乎顯而易見地，“客戶”記錄需要“送貨地址”，但直到有用例明確需要送貨地址，才應該實現它。
5、不要害怕做決定，不要害怕改變先前的決定：敏捷開發是關於相應變化和快速相應的。開發初期，你沒有完整的資訊。你應該儘可能的推遲決策，直到你必須做出決策的時候。沒有資訊，無法支援你的決定，相反，在有效資訊的基礎上做出最佳決定。有了新的資訊，不要害怕改變先前的決定。（某些“恐龍”稱之為搖擺不定，但我稱之為響應變化的環境）
6、持續學習如何改善質量
7、度量、度量、度量：敏捷開發幫助處理未來不確定性問題，但對於過去應沒有不確定性。測試應持續執行，每次執行的效能表現應被度量和記錄。
8、為人而設計，而不是系統：開發者常常因技術而使設計誤入歧途。絕不要忘記設計的最終目標，那就是幫助人們完成工作。
9、測試是產品的一部分：很多開發者和經理認為產品就是交付給客戶的東西，而其它所有東西都不那麼重要。測試應被認為是產品實實在在的一個部分，值得在設計時仔細考慮，甚至，在很多情況下，和產品一起交付給客戶。（後半部分有爭議，但是內建測試作為軟體交付的一部分僅僅佔用無關緊要的空間，卻在必要時提供顯而易見的好處，這種方式應該被考慮。）
10、在程式碼之前編寫測試
11、消除浪費：坦率的說，這是另一個必須包含在任何開發原則清單中的陳詞濫調，因為它太重要了。發現浪費並消除它，這項工作沒有盡頭。消除任何不能增加客戶價值的東西。如果你不能確認客戶價值，那很可能你並不需要它。
12、建立對構建破壞立即響應的文化：要明白當構建被破壞，會影響專案中的每一個人，因此，最重要的是確認核心程式碼被構建併合理測試。我曾見過有些團隊放任失敗測試持續數月，因為那是其它人的工作。每個人都痛苦，但沒人採取行動。想反，必須形成共識，那就是小工作能為團隊獲得大的回報。
13、所有團隊成員應理解客戶需要
14、把相關定義放在一起：組織程式碼以使高度相關的事情在一起，或在一個類中。這是標準面向物件設計封裝原則。理想情況下，所有的類外的程式碼不需要知道內部工作細節。一些開發者樂於將細節擴散到多個檔案中以便按不同方式組織，如所有相同的資料型別放在一起，或者按字母順序組織。例如，在他們要用的不同包中，將所有常量放在一個類裡，這增加了不必要的程式複雜性。指導原則應該是按相關性分組從而隱藏複雜性。
15、始終在簽入之前執行測試：這條準則幫助你滿足“不要破壞構建”準則。
16、過早的優化時萬惡之源：引用高德納被證實的話：程式碼應編寫良好以避免微觀層面的浪費，但獨立方法層次以外的優化應等待整個程式基於真實的終端使用者使用情景的壓力測試的進行。僅僅基於對程式碼的靜態理解，直覺地判斷對整體效能什麼是重要的，結論幾乎總是錯誤的。相反，度量整個系統的行為，辨別1%真正影響效能的程式碼，並專注於此。
17、減少積壓未完成的編碼任務：當開發人員開始一個用例，會發生成本，跟已修改卻未完成和測試的程式碼相關聯。留著未完成的變化幾天或幾個星期會累積成巨大的重做風險。考慮每個估算需要一天的三個任務，同時開始這三個任務，並在3天內同時進行，意味著9個單位的累計成本。但是順序進行每個任務，完成一個再開始下一個，意味著只有3個單位的成本。這個不是直覺，直覺告訴我們，在工作完成之前，我們不妨同時做三件事情。但軟體不像物理構造。短小，快速和完整的工作不僅減少認知的負擔，而且減少未完成工作與他人未完成工作之間衝突的可能。
18、不要過度強調程式碼的通用性：這就是著名的“YAGNI-你不會需要它”。當編寫一個特定類的時候，程式設計師總喜歡認為該類可能用於其它用途。如果現在的用例需要這些用途，這很好，但是，程式設計師經常考慮未被提及的用途，或者那些實際上永遠不需要的。（這常常讓我聯想到經典的週六現場滑稽短劇，關於某產品既是地板蠟，也是糕點上的甜食。）
19、兩行程式碼能行，就不要用三行：有人閱讀時，簡潔的程式碼總能獲得回報。但不要將程式碼壓縮到難以閱讀。更小的，編寫良好的程式碼比之冗長的，編寫華麗的程式碼更容易維護，也更容易發現錯誤。始終儘可能簡化，但別過分。
20、不要用行數來度量程式碼：完成特定任務所需的程式碼行數，不同的程式設計師之間和編碼風格之間差異很大。程式碼行數不能告訴你程式碼完成和質量的些許東西。程式碼質量可以相差200倍，這足以抵消程式碼行數的作用。應該統計功能用例的數目。
21、持續地重新設計和重構：謹慎地使用這條準則，因為有些程式碼脆弱而難以改變，但通常你不應害怕更改程式碼以符合實際使用情況。一個數據成員過去可能是整數，但是當一個用例要求它是一個浮點數時不要害怕去改變它。
22、刪除死程式碼：涉及到大量不能很好理解的程式碼是，有個傾向是不自找麻煩。一個例子就是往類中增加新的方法去替換另一個，開發人員常常會留下舊的方法以防萬一。必須努力檢查方法是否必須，如果沒有證據表明它是必須的，那就刪除它。最糟糕的就是註釋掉大量的程式碼，並把它留在那兒。註釋掉的程式碼應在測試通過後儘快刪除，當然應在簽入之前。因此，某個時候你發現一些東西可能並不需要，付出小小的努力去驗證並消除此程式碼能讓程式碼基線更易維護。
23、不要發明新語言：程式設計師喜愛使用文字檔案配置在執行時驅動功能。沒有配置檔案能夠不編譯而改變程式的行為。XML的出現推動了無休止的專門定製“指令碼語言”的浪潮，以使功能能被終端使用者定製而不需要編譯。這種推理的缺陷在於，離開某個特定實施的環境，操作行為幾乎從來沒能很好地精確定義，同時，那些指令碼語言只對那些對問題領域程式碼的內部執行有深入瞭解的人有用。因此，不具備詳盡內部知識的真實終端使用者永遠不可能知道預料複雜的命令組合的效果需要什麼。指令碼語言有用，也不能被消除，但是設計者必須採取非常非常保守的態度，儘可能使用現有的語言，避免新的發明。
24、在你準備實現並測試前，別做設計：你應該有行進的總體思路和對系統架構的概覽，但是，直到開發迭代允許設計被實現和測試前，不要做詳細設計，不要編寫功能實現的詳細說明。詳細設計應當只涉及到處理目前的用例。軟體開發中最大的浪費源於將時間花在設計那些不需要，或者因為某些錯誤的設計假定而需要重新設計的事情之上。
25、設計是可塑的：不像物理製造，軟體可以很容易地獲得顯著改變。事實上，有大量證據證明軟體本身比描述軟體的設計說明書更容易改變。此外，軟體比說明書更有效地傳達設計。因此，你應該把時間用於直接實現設計，讓客戶能看見設計的細節。如果你犯錯並改變設計，改變軟體比改變規格更容易。但最重要的是，客戶看到程式碼執行後，你關於客戶想要什麼的資訊大為完善。
26、花時間編寫發現和報告異常情況的程式碼中的問題的完整描述：程式設計師往往很懶惰，丟擲粗淺描述錯誤的異常。認為他們永遠是唯一會看到這個問題的人，並且他們從含糊的描述會記得這個問題的意思。但實際上，在客戶支援環境，不準確或者不完整的錯誤報告比其它原因浪費更多的時間。編寫每個錯誤訊息，就好像你正向某個正好走進房間並且沒有此程式碼經驗的人解釋狀況。客戶和客戶支援團隊畢竟沒有此程式碼的經驗。
這些介紹沒有特定的順序，歡迎留言討論我忽略的原則，或者（如果是這種情況）你不認同的敏捷開發原則
3、在用例需要之前，不要實現程式：當你實現一個特定的類，你應該在腦海中有一個特定的用例，同時應該只實現用例需要的方法。你可以考慮該類潛在的功能，寫入註釋之中，但直到用例真正需要時，才應去實現它。
4、在用例需要之前，不要新增資料成員：同上一條，不過這是從類的資料成員角度考慮的。似乎顯而易見地，“客戶”記錄需要“送貨地址”，但直到有用例明確需要送貨地址，才應該實現它。
5、不要害怕做決定，不要害怕改變先前的決定：敏捷開發是關於相應變化和快速相應的。開發初期，你沒有完整的資訊。你應該儘可能的推遲決策，直到你必須做出決策的時候。沒有資訊，無法支援你的決定，相反，在有效資訊的基礎上做出最佳決定。有了新的資訊，不要害怕改變先前的決定。（某些“恐龍”稱之為搖擺不定，但我稱之為響應變化的環境）
6、持續學習如何改善質量
7、度量、度量、度量：敏捷開發幫助處理未來不確定性問題，但對於過去應沒有不確定性。測試應持續執行，每次執行的效能表現應被度量和記錄。
8、為人而設計，而不是系統：開發者常常因技術而使設計誤入歧途。絕不要忘記設計的最終目標，那就是幫助人們完成工作。
9、測試是產品的一部分：很多開發者和經理認為產品就是交付給客戶的東西，而其它所有東西都不那麼重要。測試應被認為是產品實實在在的一個部分，值得在設計時仔細考慮，甚至，在很多情況下，和產品一起交付給客戶。（後半部分有爭議，但是內建測試作為軟體交付的一部分僅僅佔用無關緊要的空間，卻在必要時提供顯而易見的好處，這種方式應該被考慮。）
10、在程式碼之前編寫測試
11、消除浪費：坦率的說，這是另一個必須包含在任何開發原則清單中的陳詞濫調，因為它太重要了。發現浪費並消除它，這項工作沒有盡頭。消除任何不能增加客戶價值的東西。如果你不能確認客戶價值，那很可能你並不需要它。
12、建立對構建破壞立即響應的文化：要明白當構建被破壞，會影響專案中的每一個人，因此，最重要的是確認核心程式碼被構建併合理測試。我曾見過有些團隊放任失敗測試持續數月，因為那是其它人的工作。每個人都痛苦，但沒人採取行動。想反，必須形成共識，那就是小工作能為團隊獲得大的回報。
13、所有團隊成員應理解客戶需要
14、把相關定義放在一起：組織程式碼以使高度相關的事情在一起，或在一個類中。這是標準面向物件設計封裝原則。理想情況下，所有的類外的程式碼不需要知道內部工作細節。一些開發者樂於將細節擴散到多個檔案中以便按不同方式組織，如所有相同的資料型別放在一起，或者按字母順序組織。例如，在他們要用的不同包中，將所有常量放在一個類裡，這增加了不必要的程式複雜性。指導原則應該是按相關性分組從而隱藏複雜性。
15、始終在簽入之前執行測試：這條準則幫助你滿足“不要破壞構建”準則。
16、過早的優化時萬惡之源：引用高德納被證實的話：程式碼應編寫良好以避免微觀層面的浪費，但獨立方法層次以外的優化應等待整個程式基於真實的終端使用者使用情景的壓力測試的進行。僅僅基於對程式碼的靜態理解，直覺地判斷對整體效能什麼是重要的，結論幾乎總是錯誤的。相反，度量整個系統的行為，辨別1%真正影響效能的程式碼，並專注於此。
17、減少積壓未完成的編碼任務：當開發人員開始一個用例，會發生成本，跟已修改卻未完成和測試的程式碼相關聯。留著未完成的變化幾天或幾個星期會累積成巨大的重做風險。考慮每個估算需要一天的三個任務，同時開始這三個任務，並在3天內同時進行，意味著9個單位的累計成本。但是順序進行每個任務，完成一個再開始下一個，意味著只有3個單位的成本。這個不是直覺，直覺告訴我們，在工作完成之前，我們不妨同時做三件事情。但軟體不像物理構造。短小，快速和完整的工作不僅減少認知的負擔，而且減少未完成工作與他人未完成工作之間衝突的可能。
18、不要過度強調程式碼的通用性：這就是著名的“YAGNI-你不會需要它”。當編寫一個特定類的時候，程式設計師總喜歡認為該類可能用於其它用途。如果現在的用例需要這些用途，這很好，但是，程式設計師經常考慮未被提及的用途，或者那些實際上永遠不需要的。（這常常讓我聯想到經典的週六現場滑稽短劇，關於某產品既是地板蠟，也是糕點上的甜食。）
19、兩行程式碼能行，就不要用三行：有人閱讀時，簡潔的程式碼總能獲得回報。但不要將程式碼壓縮到難以閱讀。更小的，編寫良好的程式碼比之冗長的，編寫華麗的程式碼更容易維護，也更容易發現錯誤。始終儘可能簡化，但別過分。
20、不要用行數來度量程式碼：完成特定任務所需的程式碼行數，不同的程式設計師之間和編碼風格之間差異很大。程式碼行數不能告訴你程式碼完成和質量的些許東西。程式碼質量可以相差200倍，這足以抵消程式碼行數的作用。應該統計功能用例的數目。
21、持續地重新設計和重構：謹慎地使用這條準則，因為有些程式碼脆弱而難以改變，但通常你不應害怕更改程式碼以符合實際使用情況。一個數據成員過去可能是整數，但是當一個用例要求它是一個浮點數時不要害怕去改變它。
22、刪除死程式碼：涉及到大量不能很好理解的程式碼是，有個傾向是不自找麻煩。一個例子就是往類中增加新的方法去替換另一個，開發人員常常會留下舊的方法以防萬一。必須努力檢查方法是否必須，如果沒有證據表明它是必須的，那就刪除它。最糟糕的就是註釋掉大量的程式碼，並把它留在那兒。註釋掉的程式碼應在測試通過後儘快刪除，當然應在簽入之前。因此，某個時候你發現一些東西可能並不需要，付出小小的努力去驗證並消除此程式碼能讓程式碼基線更易維護。
23、不要發明新語言：程式設計師喜愛使用文字檔案配置在執行時驅動功能。沒有配置檔案能夠不編譯而改變程式的行為。XML的出現推動了無休止的專門定製“指令碼語言”的浪潮，以使功能能被終端使用者定製而不需要編譯。這種推理的缺陷在於，離開某個特定實施的環境，操作行為幾乎從來沒能很好地精確定義，同時，那些指令碼語言只對那些對問題領域程式碼的內部執行有深入瞭解的人有用。因此，不具備詳盡內部知識的真實終端使用者永遠不可能知道預料複雜的命令組合的效果需要什麼。指令碼語言有用，也不能被消除，但是設計者必須採取非常非常保守的態度，儘可能使用現有的語言，避免新的發明。
24、在你準備實現並測試前，別做設計：你應該有行進的總體思路和對系統架構的概覽，但是，直到開發迭代允許設計被實現和測試前，不要做詳細設計，不要編寫功能實現的詳細說明。詳細設計應當只涉及到處理目前的用例。軟體開發中最大的浪費源於將時間花在設計那些不需要，或者因為某些錯誤的設計假定而需要重新設計的事情之上。
25、設計是可塑的：不像物理製造，軟體可以很容易地獲得顯著改變。事實上，有大量證據證明軟體本身比描述軟體的設計說明書更容易改變。此外，軟體比說明書更有效地傳達設計。因此，你應該把時間用於直接實現設計，讓客戶能看見設計的細節。如果你犯錯並改變設計，改變軟體比改變規格更容易。但最重要的是，客戶看到程式碼執行後，你關於客戶想要什麼的資訊大為完善。
26、花時間編寫發現和報告異常情況的程式碼中的問題的完整描述：程式設計師往往很懶惰，丟擲粗淺描述錯誤的異常。認為他們永遠是唯一會看到這個問題的人，並且他們從含糊的描述會記得這個問題的意思。但實際上，在客戶支援環境，不準確或者不完整的錯誤報告比其它原因浪費更多的時間。編寫每個錯誤訊息，就好像你正向某個正好走進房間並且沒有此程式碼經驗的人解釋狀況。客戶和客戶支援團隊畢竟沒有此程式碼的經驗。
這些介紹沒有特定的順序，歡迎留言討論我忽略的原則，或者（如果是這種情況）你不認同的敏捷開發原則