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