成功實踐敏捷開發(fā)的26條“軍規(guī)”
當前位置：點晴教程→知識管理交流
→『 技術(shù)文檔交流 』
如何才能成功實踐敏捷開發(fā)是一個課題。最近keith swenson一直在考慮這個問題，并最終總結(jié)出26條重要原則，以指導敏捷軟件開發(fā)團隊更好地工作。
原則1：第1個用例完全處理好后再開始處理第2個用例。打個比方說，好比“先上這道菜，再開始做下一道菜”。軟件開發(fā)方面的最大問題是同時開始處理一堆任務，因為免不了會出現(xiàn)部分工作后來被丟棄的結(jié)果，而這意味著浪費工作。先處理好某個用例，確保它完全可以使用，進行測試，編寫說明文檔，簽入所有代碼，作為一件完成的工作，之后開始處理下一個用例。 原則2：千萬不要破壞編譯版本。這一條原則顯而易見，但必須包括在任何軟件開發(fā)忠告清單當中。如果程序員在簽入代碼之前采取了所有相應的防范措施進行測試，就永遠不會破壞編譯版本（build）。如果編譯版本被破壞，十有八九是因為有人在抄捷徑。 原則3：除非用例確實需要，否則不要實現(xiàn)例行程序。實現(xiàn)某個特定的類時，你應該想好了某個特定的用例，而且應該只實現(xiàn)該用例需要的那些方法。你可能會考慮該類可能具有的其他功能，不妨把這寫入到注釋中，但應該等到用例實際需要時，再去實現(xiàn)。 原則4：除非用例確實需要，否則不要添加數(shù)據(jù)成員。與上面這條原則如出一轍，只不過涉及的是類的數(shù)據(jù)成員?！翱蛻簟庇涗浰坪躏@然需要“送貨地址”，但直到有一個用例明確需要送貨地址，才應該實現(xiàn)它。 原則5：不要害怕做決定；也不要害怕改變之前所做的決定。敏捷開發(fā)的本質(zhì)就是遇到不確定狀況后，迅速響應。在開發(fā)的早期階段，你沒有完整信息。應當盡可能推遲決定，但到時候終究需要做決定，才能開展進一步工作。你可以推遲決定，直到擁有了相應的信息。應當根據(jù)現(xiàn)有信息，做出最合理的決定。以后等有了新的信息，不要害怕改變之前所做的那個決定。（有些老派的人稱之為朝令夕改，但我稱之為是應對不斷變化的環(huán)境。） 原則6：不斷學習如何改善質(zhì)量。這項工作永遠不會結(jié)束，所以你應該不斷留意哪些方面可以改善，并收集如何確認及處理質(zhì)量問題的實際方法。 原則7：重視度量。敏捷開發(fā)是為了幫助處理將來不確定的問題，但過去毫無不確定性可言。應該不斷進行測試。應該度量并記錄每次測試所得到的性能。 原則8：奉行以人為本、而不是以系統(tǒng)為本的設計理念。開發(fā)人員常常會走入為技術(shù)而設計的誤區(qū)。我們絕不能忘了軟件的最終目的，即軟件是用來幫助人完成工作的。 原則9：測試是產(chǎn)品的一部分。許多開發(fā)人員和經(jīng)理認為產(chǎn)品就是交付給客戶的東西，其他一概都不那么重要。其實，應該把測試看作是產(chǎn)品的一個實際部分，值得在設計階段予以全面考慮；甚至在許多情況下，要與產(chǎn)品一同交付給客戶。（這后一種做法頗有爭議，但是內(nèi)建自測作為交付軟件的一部分占用的空間微不足道，卻在必要時提供了顯著效益。所以，這種方法值得考慮。） 原則10：先編寫測試用例，后編寫代碼。測試本身可以用來讓設計體系清楚到底需要什么樣的代碼。在執(zhí)行測試用例時，往往可以發(fā)現(xiàn)設計方法存在的缺陷。想一想在編寫代碼之前執(zhí)行測試用例可以省下多少時間。但要注意：先編寫第1個測試用例，并編寫代碼，然后開始處理第2個用例。 原則11：消除浪費。坦率地說，這是另一條老生常談的普遍原則；因為它實在太重要了，所以任何開發(fā)原則清單中都少不了它。一旦發(fā)現(xiàn)浪費，就要消除，這項工作要堅持不懈。消除無法為客戶增添價值的任何代碼。如果你發(fā)現(xiàn)代碼無法為客戶帶來價值，那么可能不需要該代碼。 原則12：營造發(fā)現(xiàn)編譯版本被破壞、立即采取對策的文化氛圍。要明白當編譯版本被破壞時，它會影響參與項目的每個人；因此，沒有什么比確保核心代碼進行合理編譯及測試更重要的了。我見過有些團隊任由不完整的測試持續(xù)數(shù)個月，因為他們覺得那是別人的工作，不關(guān)自己的事。每個人都受到了不利影響，卻沒有人采取行動。而是需要達到一種共識：自己多做一點工作，就有望為整個團隊帶來很大的回報。 原則13：團隊的每個成員都要了解客戶需求。大型的復雜項目必須進行劃分，交給不同團隊；這些任務需要進一步細分，分派給開發(fā)人員。但是在這么做的同時，要確保開發(fā)人員了解使用最終產(chǎn)品的實際用戶的需求和目標。 原則14：把相關(guān)的定義放在一起。設計代碼結(jié)構(gòu)時，確保高度相關(guān)的部分放在一起，有可能放在同一個類中。這是面向?qū)ο笤O計方法在封裝方面的一條標準原則。理想情況下，某個類之外的所有代碼不需要知道內(nèi)部運行的細節(jié)。有些開發(fā)人員喜歡將細節(jié)分散在多個文件中，以便按不同方式加以組織：比如為了把所有相同的數(shù)據(jù)類型放在一起，或者按字母順序進行組織。比方說，把一個類中所有常量放在與使用它們的包不同的另一個包當中，就會增加不必要的程序復雜性。指導原則應該是按相關(guān)性進行分組，那樣可以隱藏復雜性。 原則15：始終在簽入代碼之前運行測試。這條準則會幫助你滿足“千萬不要破壞編譯版本”的準則。 原則16：倉促優(yōu)化是萬惡之源。程序教父don knuth的這句名言今天依然適用。應當精心編寫代碼，避免微觀層面出現(xiàn)不必要的浪費，但應該等到基于實際的最終用戶用例對整個程序進行壓力測試，再進行單個方法層面之外的優(yōu)化。要是僅僅基于對代碼的靜態(tài)了解，就憑直覺判斷什么對整體性能來說很重要，幾乎肯定出錯。相反，要度量整個系統(tǒng)的行為，找出真正影響性能的那1%的代碼，并關(guān)注這部分代碼。 原則17：盡量減少積壓下來的沒有完成的編碼任務。開發(fā)人員開始編寫某個用例時，所有已被修改、但沒有完成及測試的代碼會發(fā)生成本。沒有完成的變更積壓幾天或幾周，會大大增加因改寫而導致浪費的風險。設想一下有三個任務，每個任務估計需要一天。同時開始這三個任務，同時工作三天就需要累計9個“單位”的成本。但如果按順序處理每個任務，一個任務完成后開始下一個，那么只需要3個“單位”的成本。這并不直觀。直覺告訴我們：我們在處理任務時，最好還是同時做三件事。但軟件不像實體構(gòu)造。短小、快速、完整的任務不但可以減輕認知負荷，還能減小未完成工作與另一個人的未完成工作發(fā)生沖突的可能性。 原則18：千萬不要過于強調(diào)代碼的通用性。這就是有名的yagni，即“你不會需要它”。程序員在編寫某個特定類時，喜歡認為：只要稍加改動，該類可用于另外幾個用途。如果當前用例需要這些用途，那很好；但是程序員通常會考慮還沒有發(fā)明出來的用途，或者是實際上根本不需要的用途。（這個話題老是讓我想到宣傳某款產(chǎn)品既是地板蠟、又是甜食配料的搞笑電視節(jié)目。） 原則19：能用兩行代碼，就堅決不要用三行。每當別人要讀代碼時，簡單的代碼總是一目了然。但也不要把代碼簡化到人家很難讀懂的地步。與冗長代碼相比，簡潔代碼更容易維護，也更容易發(fā)現(xiàn)其中的錯誤。始終要盡量簡化，但避免簡化過頭。 原則20：千萬不要用行數(shù)來度量代碼。就完成特定任務所需的代碼行數(shù)而言，不同的程序員和編程風格會造成很大的差異。代碼行數(shù)說明不了代碼有多全面、質(zhì)量有多好。代碼質(zhì)量有可能千差萬別；與代碼質(zhì)量相比，代碼行數(shù)顯得沒有太大的意義。而是應統(tǒng)計切實可行的用例有多少。 原則21：持續(xù)不斷地重新設計和重構(gòu)。運用這條原則要慎重，因為有些代碼很脆弱、很難改變，但一般而言，你用不著害怕更改代碼以符合實際用例。某個數(shù)據(jù)成員過去可能是整數(shù)，但是當用例要求它是浮點數(shù)時，不要害怕更改。 原則22：刪除無用代碼。說到并不完全了解的大段代碼，人們往往采取“別惹事生非”的做法。一個例子就是，為某個類增加一種新方法以替換另一種舊方法，而開發(fā)人員往往讓舊方法留在那里，僅僅為了“以防萬一”。應當花一番工夫，看看需不需要該方法；如果沒有證據(jù)表明需要它，就刪除。最糟糕的做法莫過于注釋掉了大段代碼，卻任由這些注釋代碼留在原處。一旦你知道測試完畢，就應當刪除注釋代碼，當然要在簽入之前。隨時添加代碼很容易，隨時刪除代碼卻很難。因此，如果你清楚不需要某部分代碼，那么只需下一點力氣，核實并消除此代碼就能讓代碼庫維護起來更容易。 原則23：不要發(fā)明新語言。程序員喜歡讓驅(qū)動功能的文本文件在運行時可以靈活配置。有好多配置文件在不重新編譯的情況下能夠改變程序的行為。xml的出現(xiàn)讓一批專門定制的“腳本語言”層出不窮：有了這些語言，最終用戶不必編譯，就能夠“編程”以實現(xiàn)功能。這種推論的缺陷在于，要是離開了具體實現(xiàn)的環(huán)境，就幾乎根本無法明確規(guī)定操作行為的精確定義；而這些類型的腳本語言主要只適用于那些對相應代碼的內(nèi)部運行有深入了解的人。因此，并不詳細了解內(nèi)部運行的實際最終用戶永遠不可能知道如何才能預料到復雜的命令組合會帶來什么影響。腳本語言是有用，也不能被抹殺，但是設計者必須采取一種極其保守的態(tài)度，盡可能使用現(xiàn)有語言，避免發(fā)明新的語言。 原則24：等準備好了實現(xiàn)并測試實現(xiàn)代碼，再進行設計。你應該總體上對工作方向有一些了解，并大致了解爭取建立的系統(tǒng)架構(gòu)。但在進入到可以實現(xiàn)及測試該設計的開發(fā)迭代階段之前，不要做詳細設計，也不要編寫功能實現(xiàn)的詳細描述。詳細設計應當只涉及處理當前用例所需的那部分。軟件開發(fā)中造成浪費的最主要根源在于，把時間花在設計不需要、或者因為設計方面某些錯誤的假定而需要重新設計的部分上。 原則25：設計是可塑的。不像實體構(gòu)造，軟件可以輕而易舉地進行重大改變。事實上，有許多證據(jù)可以證明：軟件比描述軟件的設計規(guī)格更容易改變。此外，軟件比規(guī)格更有效地傳達了設計思想。因此，你應當把時間花在直接實現(xiàn)設計上，以便客戶能看到設計的具體細節(jié)。如果你缺少某些功能、因而要改變設計，改變軟件會比改變規(guī)格來得容易。但最重要的是，客戶看到代碼運行后，你就能非常清楚地知道客戶想要什么。 原則26：花些時間編寫代碼來完整描述發(fā)現(xiàn)和報告異常情況的代碼中的問題。程序員往往很懶惰，對拋出的異常情況只給出簡單膚淺的描述，說明哪里出了錯。以為只有他們自己才會看到這個問題；只要借助含糊籠統(tǒng)的描述，就會記得該問題的意思。但實際上，因錯誤報告不準確或不完整而浪費在客戶支持情景上的時間比其他任何原因都要多。要編寫每一個錯誤消息，就好像你向剛走入房間、對代碼毫無經(jīng)驗的某個人說明情況。畢竟，客戶以及客戶支持團隊對代碼是毫無經(jīng)驗的。 該文章在 2010/7/25 2:28:06 編輯過 |
關(guān)鍵字查詢
相關(guān)文章
正在查詢... 
|
400 186 1886
