南寧達(dá)內(nèi)：敏捷開發(fā)的26條至理名言

1、完整地干完一件事后在開始另一件事：用廚房比喻來說就是：“先上這道菜，再開始做下一道”。軟件開發(fā)的最大問題就是同時(shí)開始幾件事情，這將不可避免的造成某些工作被廢棄，從而造成浪費(fèi)。專注于一件事；完整地實(shí)現(xiàn)其功能；運(yùn)行測試；編寫文檔；簽入所有，把這當(dāng)做一項(xiàng)工作完成，然后再開始下一件事。

2、不要破壞構(gòu)建：非常明顯，但必須被包含在任何軟件開發(fā)建議清單中。程序員在簽入之前采取所有合適的預(yù)防措施進(jìn)行測試，則永遠(yuǎn)不會(huì)破壞構(gòu)建。如果構(gòu)建被破壞，通常是因?yàn)橛腥送祽辛恕?/p>

3、在用例需要之前，不要實(shí)現(xiàn)程序：當(dāng)你實(shí)現(xiàn)一個(gè)特定的類，你應(yīng)該在腦海中有一個(gè)特定的用例，同時(shí)應(yīng)該只實(shí)現(xiàn)用例需要的方法。你可以考慮該類潛在的功能，寫入注釋之中，但直到用例真正需要時(shí)，才應(yīng)去實(shí)現(xiàn)它。

4、在用例需要之前，不要添加數(shù)據(jù)成員：同上一條，不過這是從類的數(shù)據(jù)成員角度考慮的。似乎顯而易見地，“客戶”記錄需要“送貨地址”，但直到有用例明確需要送貨地址，才應(yīng)該實(shí)現(xiàn)它。

5、不要害怕做決定，不要害怕改變先前的決定：敏捷開發(fā)是關(guān)于相應(yīng)變化和快速相應(yīng)的。開發(fā)初期，你沒有完整的信息。你應(yīng)該盡可能的推遲決策，直到你必須做出決策的時(shí)候。沒有信息，無法支持你的決定，相反，在有效信息的基礎(chǔ)上做出最佳決定。有了新的信息，不要害怕改變先前的決定。（某些“恐龍”稱之為搖擺不定，但我稱之為響應(yīng)變化的環(huán)境）

6、持續(xù)學(xué)習(xí)如何改善質(zhì)量：這項(xiàng)工作永不會(huì)結(jié)束，因此你應(yīng)經(jīng)常留意可以改善的事情，并收集質(zhì)量問題被確認(rèn)和處理的案例。

7、度量、度量、度量：敏捷開發(fā)幫助處理未來不確定性問題，但對(duì)于過去應(yīng)沒有不確定性。測試應(yīng)持續(xù)運(yùn)行，每次運(yùn)行的性能表現(xiàn)應(yīng)被度量和記錄。

8、為人而設(shè)計(jì)，而不是系統(tǒng)：開發(fā)者常常因技術(shù)而使設(shè)計(jì)誤入歧途。絕不要忘記設(shè)計(jì)的最終目標(biāo)，那就是幫助人們完成工作。

9、測試是產(chǎn)品的一部分：很多開發(fā)者和經(jīng)理認(rèn)為產(chǎn)品就是交付給客戶的東西，而其它所有東西都不那么重要。測試應(yīng)被認(rèn)為是產(chǎn)品實(shí)實(shí)在在的一個(gè)部分，值得在設(shè)計(jì)時(shí)仔細(xì)考慮，甚至，在很多情況下，和產(chǎn)品一起交付給客戶。（后半部分有爭議，但是內(nèi)建測試作為軟件交付的一部分僅僅占用無關(guān)緊要的空間，卻在必要時(shí)提供顯而易見的好處，這種方式應(yīng)該被考慮。）

10、在代碼之前編寫測試：測試本身可以用來闡釋真正需要的設(shè)計(jì)。設(shè)計(jì)的缺陷常常是通過測試用例被發(fā)現(xiàn)的。想想看，編碼之前，通過這些用例，可以節(jié)約多少時(shí)間。但是，為用例1編寫測試，然后編碼，然后再開始用例2。

11、消除浪費(fèi)：坦率的說，這是另一個(gè)必須包含在任何開發(fā)原則清單中的陳詞濫調(diào)，因?yàn)樗匾?。發(fā)現(xiàn)浪費(fèi)并消除它，這項(xiàng)工作沒有盡頭。消除任何不能增加客戶價(jià)值的東西。如果你不能確認(rèn)客戶價(jià)值，那很可能你并不需要它。

12、建立對(duì)構(gòu)建破壞立即響應(yīng)的文化：要明白當(dāng)構(gòu)建被破壞，會(huì)影響項(xiàng)目中的每一個(gè)人，因此，最重要的是確認(rèn)核心代碼被構(gòu)建并合理測試。我曾見過有些團(tuán)隊(duì)放任失敗測試持續(xù)數(shù)月，因?yàn)槟鞘瞧渌说墓ぷ?。每個(gè)人都痛苦，但沒人采取行動(dòng)。想反，必須形成共識(shí)，那就是小工作能為團(tuán)隊(duì)獲得大的回報(bào)。

13、所有團(tuán)隊(duì)成員應(yīng)理解客戶需要：大型的復(fù)雜項(xiàng)目定然被分解為獨(dú)立的團(tuán)隊(duì)，進(jìn)而被分派給開發(fā)人員。但是，不應(yīng)在此范圍內(nèi)做的是，失去關(guān)注最終項(xiàng)目真正用戶的期望和目標(biāo)。

14、把相關(guān)定義放在一起：組織代碼以使高度相關(guān)的事情在一起，或在一個(gè)類中。這是標(biāo)準(zhǔn)面向?qū)ο笤O(shè)計(jì)封裝原則。理想情況下，所有的類外的代碼不需要知道內(nèi)部工作細(xì)節(jié)。一些開發(fā)者樂于將細(xì)節(jié)擴(kuò)散到多個(gè)文件中以便按不同方式組織，如所有相同的數(shù)據(jù)類型放在一起，或者按字母順序組織。例如，在他們要用的不同包中，將所有常量放在一個(gè)類里，這增加了不必要的程序復(fù)雜性。指導(dǎo)原則應(yīng)該是按相關(guān)性分組從而隱藏復(fù)雜性。

15、始終在簽入之前運(yùn)行測試：這條準(zhǔn)則幫助你滿足“不要破壞構(gòu)建”準(zhǔn)則。

16、過早的優(yōu)化時(shí)萬惡之源：引用高德納被證實(shí)的話：代碼應(yīng)編寫良好以避免微觀層面的浪費(fèi)，但獨(dú)立方法層次以外的優(yōu)化應(yīng)等待整個(gè)程序基于真實(shí)的最終用戶使用情景的壓力測試的進(jìn)行。僅僅基于對(duì)代碼的靜態(tài)理解，直覺地判斷對(duì)整體性能什么是重要的，結(jié)論幾乎總是錯(cuò)誤的。相反，度量整個(gè)系統(tǒng)的行為，辨別1%真正影響性能的代碼，并專注于此。

17、減少積壓未完成的編碼任務(wù)：當(dāng)開發(fā)人員開始一個(gè)用例，會(huì)發(fā)生成本，跟已修改卻未完成和測試的代碼相關(guān)聯(lián)。留著未完成的變化幾天或幾個(gè)星期會(huì)累積成巨大的重做風(fēng)險(xiǎn)?？紤]每個(gè)估算需要一天的三個(gè)任務(wù)，同時(shí)開始這三個(gè)任務(wù)，并在3天內(nèi)同時(shí)進(jìn)行，意味著9個(gè)單位的累計(jì)成本。但是順序進(jìn)行每個(gè)任務(wù)，完成一個(gè)再開始下一個(gè)，意味著只有3個(gè)單位的成本。這個(gè)不是直覺，直覺告訴我們，在工作完成之前，我們不妨同時(shí)做三件事情。但軟件不像物理構(gòu)造。短小，快速和完整的工作不僅減少認(rèn)知的負(fù)擔(dān)，而且減少未完成工作與他人未完成工作之間沖突的可能。

18、不要過度強(qiáng)調(diào)代碼的通用性：這就是著名的“YAGNI-你不會(huì)需要它”。當(dāng)編寫一個(gè)特定類的時(shí)候，程序員總喜歡認(rèn)為該類可能用于其它用途。如果現(xiàn)在的用例需要這些用途，這很好，但是，程序員經(jīng)?？紤]未被提及的用途，或者那些實(shí)際上永遠(yuǎn)不需要的。（這常常讓我聯(lián)想到經(jīng)典的周六現(xiàn)場滑稽短劇，關(guān)于某產(chǎn)品既是地板蠟，也是糕點(diǎn)上的甜食。）

19、兩行代碼能行，就不要用三行：有人閱讀時(shí)，簡潔的代碼總能獲得回報(bào)。但不要將代碼壓縮到難以閱讀。更小的，編寫良好的代碼比之冗長的，編寫華麗的代碼更容易維護(hù)，也更容易發(fā)現(xiàn)錯(cuò)誤。始終盡可能簡化，但別過分。

20、不要用行數(shù)來度量代碼：完成特定任務(wù)所需的代碼行數(shù)，不同的程序員之間和編碼風(fēng)格之間差異很大。代碼行數(shù)不能告訴你代碼完成和質(zhì)量的些許東西。代碼質(zhì)量可以相差200倍，這足以抵消代碼行數(shù)的作用。應(yīng)該統(tǒng)計(jì)功能用例的數(shù)目。

21、持續(xù)地重新設(shè)計(jì)和重構(gòu)：謹(jǐn)慎地使用這條準(zhǔn)則，因?yàn)橛行┐a脆弱而難以改變，但通常你不應(yīng)害怕更改代碼以符合實(shí)際使用情況。一個(gè)數(shù)據(jù)成員過去可能是整數(shù)，但是當(dāng)一個(gè)用例要求它是一個(gè)浮點(diǎn)數(shù)時(shí)不要害怕去改變它。

22、刪除死代碼：涉及到大量不能很好理解的代碼是，有個(gè)傾向是不自找麻煩。一個(gè)例子就是往類中增加新的方法去替換另一個(gè)，開發(fā)人員常常會(huì)留下舊的方法以防萬一。必須努力檢查方法是否必須，如果沒有證據(jù)表明它是必須的，那就刪除它。最糟糕的就是注釋掉大量的代碼，并把它留在那兒。注釋掉的代碼應(yīng)在測試通過后盡快刪除，當(dāng)然應(yīng)在簽入之前。因此，某個(gè)時(shí)候你發(fā)現(xiàn)一些東西可能并不需要，付出小小的努力去驗(yàn)證并消除此代碼能讓代碼基線更易維護(hù)。

23、不要發(fā)明新語言：程序員喜愛使用文本文件配置在運(yùn)行時(shí)驅(qū)動(dòng)功能。沒有配置文件能夠不編譯而改變程序的行為。XML的出現(xiàn)推動(dòng)了無休止的專門定制“腳本語言”的浪潮，以使功能能被最終用戶定制而不需要編譯。這種推理的缺陷在于，離開某個(gè)特定實(shí)施的環(huán)境，操作行為幾乎從來沒能很好地精確定義，同時(shí)，那些腳本語言只對(duì)那些對(duì)問題領(lǐng)域代碼的內(nèi)部運(yùn)行有深入了解的人有用。因此，不具備詳盡內(nèi)部知識(shí)的真實(shí)最終用戶永遠(yuǎn)不可能知道預(yù)料復(fù)雜的命令組合的效果需要什么。腳本語言有用，也不能被消除，但是設(shè)計(jì)者必須采取非常非常保守的態(tài)度，盡可能使用現(xiàn)有的語言，避免新的發(fā)明。

24、在你準(zhǔn)備實(shí)現(xiàn)并測試前，別做設(shè)計(jì)：你應(yīng)該有行進(jìn)的總體思路和對(duì)系統(tǒng)架構(gòu)的概覽，但是，直到開發(fā)迭代允許設(shè)計(jì)被實(shí)現(xiàn)和測試前，不要做詳細(xì)設(shè)計(jì)，不要編寫功能實(shí)現(xiàn)的詳細(xì)說明。詳細(xì)設(shè)計(jì)應(yīng)當(dāng)只涉及到處理目前的用例。軟件開發(fā)中最大的浪費(fèi)源于將時(shí)間花在設(shè)計(jì)那些不需要，或者因?yàn)槟承╁e(cuò)誤的設(shè)計(jì)假定而需要重新設(shè)計(jì)的事情之上。

25、設(shè)計(jì)是可塑的：不像物理制造，軟件可以很容易地獲得顯著改變。事實(shí)上，有大量證據(jù)證明軟件本身比描述軟件的設(shè)計(jì)說明書更容易改變。此外，軟件比說明書更有效地傳達(dá)設(shè)計(jì)。因此，你應(yīng)該把時(shí)間用于直接實(shí)現(xiàn)設(shè)計(jì)，讓客戶能看見設(shè)計(jì)的細(xì)節(jié)。如果你犯錯(cuò)并改變設(shè)計(jì)，改變軟件比改變規(guī)格更容易。但最重要的是，客戶看到代碼運(yùn)行后，你關(guān)于客戶想要什么的信息大為完善。

26、花時(shí)間編寫發(fā)現(xiàn)和報(bào)告異常情況的代碼中的問題的完整描述：程序員往往很懶惰，拋出粗淺描述錯(cuò)誤的異常。認(rèn)為他們永遠(yuǎn)是唯一會(huì)看到這個(gè)問題的人，并且他們從含糊的描述會(huì)記得這個(gè)問題的意思。但實(shí)際上，在客戶支持環(huán)境，不準(zhǔn)確或者不完整的錯(cuò)誤報(bào)告比其它原因浪費(fèi)更多的時(shí)間。編寫每個(gè)錯(cuò)誤消息，就好像你正向某個(gè)正好走進(jìn)房間并且沒有此代碼經(jīng)驗(yàn)的人解釋狀況?？蛻艉涂蛻糁С謭F(tuán)隊(duì)畢竟沒有此代碼的經(jīng)驗(yàn)。

這些介紹沒有特定的順序，歡迎討論我忽略的原則，或者（如果是這種情況）你不認(rèn)同的敏捷開發(fā)原則。