熱點推薦:
您现在的位置: 電腦知識網 >> 編程 >> Java編程 >> Java核心技術 >> 正文

如何在恰當的時間處理恰當的bug一(圖)

2013-11-23 19:09:46  來源: Java核心技術 

  通常關於處理bug的准則是修復bug使得結果盡可能的正確這個道理似乎是顯而易見的但是確實是這樣嗎?不不是這樣的我敢打賭在你使用過的那些存在很多bug性能極不可靠的軟件中大多數並不是因為開發者沒有時間改善它們而是因為他們只是簡單地修復了錯誤的bug想要修復正確的bug和知道如何修復是兩件不同的事情
  
  要做出准確的處理bug的決定需要回答兩個問題首先要明白如何才能做出一個好的修復bug的決定其次制定一個步驟要求這個步驟能夠在項目壓力大的情況下也能很容易得到執行並且執行這個步驟
  
  明智的領導者和有經驗的團隊知道每當項目快結束或者出現重大轉機或者項目重復循環中他們將非常容易疲憊不堪在這個過程中他們可能睡得更少更努力工作並且消耗無數的咖啡聰明的領導者如果提前考慮的話就會訂制簡單的規則在適當的位置預先放置急救裝置那麼當時間緊迫的時候就能很容易的定制快速簡單的bug修復方案
  
  這篇論文分為兩個部分簡單描述了上面說的定制的規則和那些預先放置的急救裝置更重要的是我將提供讓你制定自己的規則所需要的核心思想我們將這個建議分為四個等級從簡單急救(第一等級)到高性能計劃(第四等級)但是首先要避免那些看上去有趣但是完全沒有必要的方法
  
  十種最糟糕的處理方法
  
  只修復那些讓你的CEO苦惱的bug
  
  修復每一個bug(總也不交貨)
  
  不修復任何bug
  
  只修復那些讓CEO的配偶女兒或其寵物感覺煩惱的bug
  
  需要將每個決定讓團隊中最令人討厭最愚蠢的人批准(這點和第十點比較起來有點多余)
  
  沒有規律地開始修復一個bug當你做到一半的時候又轉向另一個bug一直重復循環如此
  
  看待bug就如同一個燙紅薯不修復它只是將你的bug委托給其他人
  
  給bug編號按照字母順序由A到Z跳過元音字母(如果你重新將它們適當的編號這一條和第八條是相同的)
  
  成立一個復雜的議會機構並從三分之二的主要成員中選舉出代表來起草一個規章制度作為小組委員會的正式文件使得將來與管理人員談論項目中的缺點時可以有緩沖的余地
  
  花費所有的時間來討論當前的操作是否在上面這些列表裡
  
  真心的希望你從來沒有在實際的工作中遇到這些行為現在你已經得到了警告所以你們在將來能夠避開它們如果你的上司建議你做上面所說的任何一條那麼你可以馬上站起來安靜地轉身然後跑得能有多快就跑多快
  
  第一等級急救
  
  在最好的網站和軟件開發公司bug管理就如同醫學上的優先治療選擇(譯者注將受傷人員按輕重緩急或立即治療的可能性進行分類的過程)一些人根據一些規則將收到的bug歸為三到四個基本的種類裡(這叫做治療等級選擇bug競爭或者叫做缺陷管理)就像那些你可能大量擁有的事物比如CD碟片書籍債務或者女朋友組織管理bug的唯一方式就是將它們歸結成更高一級的組群這將能使你更容易的了解到你得到的到底是什麼使你更加方便的同其他人討論它並且找到合適的處理它的專家一個普遍的規則是把事物歸為三到四個組群比成千上萬個獨立的個體更容易管理和工作
  
  當bug數量增加到嚴重影響工作的時候最好的急救是停下你手中的所有工作拿出一個下午來做修復歸類(如果你記不起來上一次做修復歸類工作是什麼時候那麼你現在應該停止閱讀這篇文章馬上去做這件事情)你無法使用魔法讓你的bug數據庫自動變得整齊規律必須要有某個人親自動手忙的滿頭大汗的將它們歸類整理好我向你保證在這件事情上沒有其他的路可走如果你曾經受過訓練你有能力非常有規律的將它們歸類直到整個工程結束沒有任何事情超出你的控制或者你能鼓勵每一個程序員經常對他們自己負責的bug進行歸類這非常的好但是無論你用什麼方式來處理這件任務是必須要完成的
  
  你跳過前面的這段並且說我知道歸類但是我從來不這麼做因為這樣做無聊透頂了要知道對於任何急救工作要想成功有效的話歸類是必須的無論是在醫學領域還是在技術領域如果病人的背部被射中十來支毒箭那麼你在他擦破的膝蓋上貼上邦迪創可貼是沒有任何意義的如果沒有歸類你沒有辦法知道如何讓你的團隊在最恰當的地方花費精力在受傷的人身上你能很明顯的看到那支箭還顫抖地插在他的肩頭上但是你的代碼是不同的代碼不會告訴你它的哪個部位受傷最嚴重你必須親自將它們查出來
  
  歸類還能導致一些其他有用的事情發生負責歸類的成員能夠通過通查所有的bug使得每個人都能夠更好的了解整個項目他將發現許多bug是重復出現的已經被修復的信息不完整的(這需要將這個bug返回給它的發現者)允許忽略的或者非常簡單可笑的比如有客戶抱怨這個網站不能預報下一期的樂透開獎號碼通常在初次歸類後bug的數量可以減少%很明顯這一點能大大的提高團隊的士氣但是你如果不做這些工作的話是無法這麼輕松的得到這樣的成果的
  
  最簡單的歸類
  
  在歸類的時候會有無數的方式來組織bug而每一個有經驗的人都有他自己認為是最佳方式的看法通常這個問題沒有唯一正確的答案使用一些簡單的方法並且計劃在下回改進要取決於在這期間你學到的東西和下一個項目是如何改變的
  
  最簡單的安排是劃分成三個類必須得到修復的可能需要修復的和不需要修復的當給每一個bug歸類的時候將它們放入這三類中的其中一類你放入後兩類的bug越多你歸類的效率就越高這些類的名稱已經很明顯的解釋了原因
  
  當然最糟糕的情況就是%的bug都被歸到必須被修復的那一類中這種行為被稱為膽小鬼的歸類如果每件事都是必須被修復的那就是說你認為所有的事情都有著完全相同的重要性這是沒有任何意義的因為過於膽小謹慎你這項工作是失敗的如果所有的bug的地位是相等的這表示沒有順序成功是不可能的
  
  如果你在做bug急救過程你的目標是將%的bug歸為必須修復而其他的歸為可能需要修復和不需要修復做個警戒標記讓自己認真嚴肅的對待你的bug在你做判斷的時候需要考慮到目前可以使用的資源(包括時間和人員)和你認為對於一個項目最重要的因素(客戶和業務)在一個項目的後期沒有其他的行為能比預先有效的bug管理和公開問題來的有效果將目標定為將%的bug歸為必須修復如果目標沒有達到%則需要尋找其他類中的bug歸入此類只有當你覺得這麼做令你痛苦的時候才能說明你所做的確實是bug歸類急診室中的醫生沒有辦法搖白旗說不干了也沒有叫暫停的時間他們只能不停的將一個接一個的病人區分病情的優先處理順序既然他們能夠為了人們的生命這麼做你也能夠為了你的bug這麼做所以不要做無用的畏首畏尾的膽小鬼的歸類認真起來強硬起來領導你的團隊做的更好
  
  最簡單的歸類的規則
  
  三類歸類法的基本規則是
  
  如果一個bug要歸為必須修復類那麼它必須比其他兩類中的bug更重要
  
  如果一個bug歸為了可能需要修復類那麼它必須比不需要修復類中的bug更重要
  
  如果一個bug歸為了不需要修復類那麼它必須比其他兩類中的bug更不重要
  
  所有的bug修復決定都是相關的沒有例外定義bug的重要性需要考慮許多因素這些因素會影響到把bug歸為三類中的不同的類聰明的團隊會設置一些明確的標記稱為退出標准(exit criteria)使得做修復決定變得很簡單(我會在以後的第二部分的第三等級中解釋退出標准)但是如果爭論時常發生不用著急我保證每個分類中的只有很少一部分會引起異議讓大家把焦點放在那些確定的大家都同意的bug上比如在必須修復類中有個bug屬於大家都已經認定的在其他的那些需要討論的bug提到議事日程前個bug會花費大家幾天到幾個禮拜的工作時間
  
  必須修復類是程序員們工作的起始入口如果可能需要修復類中的bug對歸類工作沒有幫助則沒有必要理會它們原因是非常簡單的不用擔心那些可能需要的東西直到你確定你已經得到了所有你知道的必須得到的東西(比如沒有必要考慮餐後的甜點除非你已經吃飽了)
  
  從可能需要修復類中偷點bug出來一直都是很誘惑人的事情因為這些bug中可能會有一些很誘惑你的包括那些使你的團隊覺得苦惱的bug那些影響到項目中你喜愛的一些性能的bug或者只是因為修復這些bug修復起來很有意思但是工作的優先級別標准是修復那些對於項目和客戶來說最重要的bug一個團隊對一個項目的服務結果是經常隨著有質量的工作和無效的工作而改變
  
  何時開始歸類
  
  通常一個禮拜一次歸類已經足夠了每個禮拜一早晨你招呼相應的人員來進行歸類然後得出這個星期中使你的團隊工作最有效率的工作計劃必須修復類中的問題應該合理地分配給整個團隊——無論他們是自願的或者被指派為特定模塊的程序員並且很樂意做這個工作如果必須修復類過於龐大那麼需要對它進行進一步歸類這個禮拜必須修復的和最終必須被修復的根據bug報告的速度和客戶或者管理者決定的變化你可能需要更加經常的進行你的bug歸類工作
  
  第二等級更加巧妙的歸類
  
  除非你一邊編程一邊修復你的bug(很不錯但很奇怪這是不普遍的策略)大多數bug修復都是在項目工作壓力很大的時候進行的要知道對於每一個bug你需要很恰當的數據來讓你
From:http://tw.wingwit.com/Article/program/Java/hx/201311/26370.html
    推薦文章
    Copyright © 2005-2013 電腦知識網 Computer Knowledge   All rights reserved.