最近看了<軟件調試修改之道>,看到最後一章<反模式>,覺得雖然有些地方太理想化了,但還是很有借鑑作用的,因此決定記錄下來,期間根據自己的體驗做了一些修改.
1 混亂的缺陷優先級
既然我們優先解決最高優先級的,那麼就有可能出現測試人員爲了優先解決自己的缺陷而故意誇大優先級的情況
1.1 解決方案
定期對缺陷進行審查,確保缺陷的優先級確實能夠反映出它們真正的優先級,並以此作爲對測試人員的信用評價
寫的越詳細的描述,優先完成.(問題描述作爲測試人員的成本,我們認爲,越捨得花費成本的,其需求越高)
2 人員更替
經常由於預算或其他項目需求等原因而發生項目團隊人員的更替. 然而人員更替往往存在交接雙方旋接不上的問題.
而且若被交接人被迫要去修復交接人產生的缺陷時,也容易對士氣產生影響
2.1 解決方案
任何人在仔細地完成當前工作之前,不允許任何人進入下一個任務.
採取自負自責的原則,誰造成了缺陷就由誰來修復它,即使他可能已經被分配到新的項目中了.
做好文檔的工作.
3 將軟件過程分成開發和維護兩個階段,由不同的團隊維護
這容易造成以下缺陷:
由代碼原始設計者/開發者修復缺陷實際上更加高效,而維護團隊需要重新學習,降低效率
若開發者不負責維護,則他就無法知道他在開發時犯了什麼錯誤,也就無法做出改進
維護團隊往往得不到完整的知識來修復缺陷,因爲軟件很多知識都是隱性的
維護團隊被淪爲二級團隊,容易打擊士氣
開發團隊由於沒有維護的壓力,沒有動力將軟件做的盡善盡美
3.1 解決方案
從最初的構思到最終佈局的整個過程乃至之後的維護都要讓一個團隊來完成,這樣能夠保持連續性,確保團隊成員的工作重點與組織的工作重點緊密關聯,並允許他們在軟件的生產過程中學習如何維護軟件.
4 救火模式
救火模式時一種行爲模式,在這種模式中,面對很多關鍵問題,我們應接不暇地解決一個個嚴重問題
長期或反覆地陷入救火模式會破壞代碼質量和團隊士氣.
4.1 解決方案
如果發現自己陷入了救火模式,不妨退一步,先找出問題產生的根本原因,再去解決問題.
不要因爲時間緊迫而只治標不治本,確保找出缺陷產生的真正原因並修復之. 不要將不理解的事情掩蓋過去,而將之當作缺陷.
這意味着,你要承擔一些短期的痛苦,以爲長遠打好堅實的基礎.
5 重寫
當面對一個麻煩的功能時,人們中有一種衝動丟棄現有的代碼重新寫新的代碼.
從心理學的觀點來看,開發新的代碼比修改舊代碼讓人更舒服. 我們天生的樂觀感是我們低估了複製舊功能所要付出的精力和時間.
然而,即使代碼事實上沒有很好的構建,沒有很好的測試或者沒有很好的記入文檔,但它的大部分時間是在工作的. 這意味着,它含有與問題相關的大量知識,而這些知識不能從其他任何地方獲得,除了這份源代碼.
5.1 解決方案
對任何重寫的建議都要報懷疑d態度. 進行以此非常細緻的成本/收益分析. 有時舊的代碼確實太爛,但應該花些時間來確認這一點.
若決定重寫,爲了儘可能減少風險. 試圖尋找一個方法來增量地重寫代碼,而不是徹頭徹尾地推到重來
對現有的代碼進行測試,並驗證得到了相同的結果. 要特別小心找出現有代碼能正確處理和你需要重做的邊界
6 代碼權限不明晰
極限編程中的一個做法就是集體代碼所有權,每個團隊對所有代碼都負有責任. 任何人都可以在任何地方修復任何缺陷而不必與原作者溝通.
然而極限編程中集體代碼有效,是因爲它由很多其他的極限編程方法的支持,比如結對編程,測試優先開發以及統一的編碼標準.
如果沒有極限編程的那些方法支持,採取集體代碼所有權就很危險,容易淪爲一種情況:由於任何人都可以在任何時間修改他們想要修改的任何東西,造成責任不明確,代碼來回被重構造成代碼質量惡劣.
6.1 解決方案
謹慎對來集體代碼所有權制,也許考慮採用一個傳統的模式,讓團隊成員中每個人擁有一個子模塊更好點.