本文章是由機器翻譯。

清除程式碼

9 項清償技術負債的實用要訣

David Laribee

十二月 2009年問題的 MSDN Magazine 我用來識別及建置大小寫，以應付技術負債給定的建議。 在摘要，我相信 ’s 重要識別 ’s 可能在不久的將來會傷害您的負債。 介紹您的程式碼基底的很少 touched 部分的技術卓越 won’t 幫助您明天實現產能提升。

而且，我希望您瞭解取得授權的重要性和購買回從管理上重要性的支付負債及擁有一些基本的工具來開始建置穩固的情況下的相同。

現在 let’s 開啟我們注意到可能會有幫助您支付高利息技術負債的戰術。 處理技術負債中有許多經證實的戰術。 完整的類別目錄的模式、 工具和 wrangling 困難的程式碼的技巧是遠超過本文的範圍。 而是，我提供一些我多年來新增到我 repertoire 更適用的墩數。

學習、 了解、 學習

如果知道您有問題，但是您 ’re 不確定如何修復這些可能會取得新的知識和技術，可協助您提高您的程式碼超出淤泥的時間。 學習如他們說是基本的。

學習可以許多形式。 您可能需要外部顧問或教室訓練的形式的說明。 您可能可以取得，請以書籍。

請試著牽涉到您的小組的學習過程中。 也許您可以開始書籍俱樂部內您的小組。 也許您可以帶回課程或會議的指示簡報形式的優點。

涉及整個小組一個協同作業和實際操作的技巧會編碼 Dojo。 基本的程式碼撰寫 Dojo 涉及挑選程式設計挑戰和處理，以群組。 我 experimented 以旋轉組 peanut 圖庫保存。 這個方法中兩個小組成員共同處理與 「 標記 」 讓小組的其他成員輸入 dojo 另一個人離開的時間間隔的一個程式設計工作。

如果您自己的步調學習最佳，或者想要啟動活頁簿俱樂部，有幾個良好我可以建議的改善的舊版程式碼可維護性主題的文字。

Michael Feathers ’ 適時其標題為磁碟區，有效率工作地與傳統的程式碼 (Prentice 大廳 2004) 提供模式為主的方法 teasing 出傳統的程式碼。 作者使舊版程式碼是未經測試的程式碼陳述式。 它難以變更，並 can’t 先確定您所做的變更 aren’t 引入迴歸分析的缺失。 這個活頁簿中您降低結合性程式碼中，以及製作更可測試的尋找數目專注的策略和策略。

Kyle Baley 及Donald Belcham 有一個 Brownfield 應用程式開發中.NE T Manning 出版物，2010年場景上最新的活頁簿。 它們採用系統的方法，向改善所謂 brownfield (相對於新的開發。 或 greenfield) 程式碼基底。 這本書的好處之一是，它們所建議的方法在廣泛適用時, 他們的程式碼範例中心來設計 Microsoft.NET Framework 到本文的讀者可能好處。 我很喜歡它們採取一小組實務方法的方式。 也就是您勇闖的程式碼基底中進行變更時, 從實作持續整合等一些基本概念取得信心並版本控制值得其重量以枚金幣。

外交

有 ’s 雜亂必須應付的程式碼撰寫人目前您小組的高可能性。 它 ’s 重要您這時考慮原因關於程式碼以其目前的狀態。 hurt 的情感導致 defensiveness，依序會導致緩慢的改進火車上移。

請試著 defusing 趣聞與您做在過去的錯誤狀況。 保持專業、 避免個人的攻擊，並鼓勵原來的程式碼的作者以提出關於如何您可能會進入關於改善它的建議。

然後再次 ’s 很有可能以您混亂 ’re 其中一個提供開發人員。 我想您重複後我:「 我不是我的程式碼。 我正在學習每一天，專門用來尋找更好的方式向前移動。 我不會讓我同事 ’ critiques] 或 [我的小組 ’s 努力以改善的方式突顯我自己 ego 」

說實話，在花時間來取得對這些問題。 我發現原因和談改良最好是將焦點放在禮物和附近未來而不是過去。 這個程式碼是什麼可能？ 您要查看它發展成?

有點外交和其他人 ’s 感情投資在已經被認可的精神的工作中的考量移一個長時間長的方式向向前移動。

引入圖形

某些程式碼是 horrendous ’s 難了解什麼根本將要。 也許是所有的類別是單一命名空間中。 或許程式碼基底是這類盤 Web 中的相依性，遵循堆疊大幅超過短期記憶體 ’s 能力保持您的位置。

這些徵狀通常暗示診斷負債在架構和設計層級，而非在實作層級。 這，我 ’m 擔心，就是最陰險負債的種類，通常會導致變更的最大的成本。

Brian Foote 和約瑟夫 Yoder 呼叫的架構與沒有 discernible 圖形的所有項目相依於其他項目，「 大球的泥漿 」 ( laputan.org/mud )：

「 大球的泥漿是一個 casually、 甚至 haphazardly 化系統。 其組織如果其中一個可以呼叫它的的取決於多 expediency 比設計。 還，其 enduring 人氣指數只是無法表示為架構的一般 disregard 」。

我當然我最後一個錢幣今天生產環境中的大部分軟體應用程式是泥漿的大法界聖骸。 這一定是 isn’t 值 judgement。 有數十億那裡在世界中讓人許多錢可怕的程式碼的行。 它代表原因泥漿的大法界聖骸會滿足 champagne 夢想並 caviar 祝福許多的企業擁有者和股東。

問題在於泥漿法界聖骸應用程式變得越來越高成本變更。 商業環境保持動態時, 軟體變得不夠彈性。 一般的策略來處理這是軟體相等的核子炸彈 (E-Mail Bomb)：大的重新寫入。 有許多大 rewrites 相關聯的風險和 ’s 通常更好，請試著改善目前系統的設計。

才能您開始採用較低層技術的某些 ’s 通常寶貴引入圖形到您的系統。 典型的範例是，分層架構。 classically 這表示 UI 談的服務和服務和說話某種的模型，此模型依序交談保存層。

外形向上插入圖層程式碼可以是非常低精確度活動。 開始組織成命名您的架構圖層的命名空間的程式碼。

現在您有 marching 訂單：強制執行較高層級的層級 (使用者介面層級) 可能只取決向上 (服務層) 下一層級規則。 為簡單的強制執行規則的方式是將您的圖層移入 Visual Studio 中的個別專案。 如果您違反規則，won’t 編譯解決方案。

藉規則傳遞已降低結合性。 模型不再結合到您的應用程式 ’s 檢視。 藉由引入一個圖案有增加一致性。 您層內的類別所有工作以相同的目的是否也是以一般使用者資料或封裝商業行為。

介紹 facades 圖層之間，並讓較高層次的圖層，例如您的 UI 定 facades 較低層級的圖層，而不是在圖層內的細微類別所提供。 您可以將這項技術套用這個處理程序，以累加方式和 opportunistically。

您現在可以開始識別目標的機會更付技術負債已經意圖案的泥漿整合型大球的電源。 也就是如果您進行中，工時一大堆說，CompanyX.ProductY.Model，您可能會深入以尋找最聯繫或複雜的類別的靜態分析工具。

關閉空中支援與測試

進行變更，而不變更系統行為的處理程序就稱為重整。 有整個重整圖樣語言專供兩個物件導向的 ( refactoring.com ) 和關聯式資料庫 ( agiledata.org/essays/databaseRefactoringCatalog.html ) 程式碼：擷取方法、 依此類推分割資料表。 事務事實是，’s 難套用這些細微且安全的方法，當您 don’t 完全瞭解程式碼基底。

因此您如何啟動傳統的專案中進行變更? 必須注意第一件事情是，給定選擇，它永遠具有您所做的變更周圍的測試更安全。 當您變更程式碼時，您可以會導致發生錯誤。 但是當之前變更程式碼，您可以涵蓋與測試的程式碼，您 ’re 比較可能會攔截任何錯誤。

一個快速 surgery 練習，plunging headlong 成沒有任何真實的信心引入的變更也 aren’t 的程式碼引入危險缺失 isn’t 強制變更唯一的方法。

開始變更程式碼之前先決定是否有 ’s 硬介面對其中您可以撰寫測試系統中。 這些測試是黑箱各種不同。 也就是您餵食系統的輸入，並檢查輸出。 當您以進行持續執行測試，以確認您所做的變更的您變更 haven’t 中斷現有的行為。

當處理您的系統的緊密結合的部分時，應用程式的這個 tactic 可以具挑戰性。 測試的成本可能非常好超過移除負債的好處。 這個常數的成本利益分析 permeates 開啟程式碼基底的程序，而且有時候，’s 更符合成本效益直接向上重寫應用程式或大型的應用程式 ’s 程式碼基底的區段。

量值可觀察效果

建置改進的程式碼區域的四周的度量單位。 這是因為的引數，let’s 說您嘗試更好的方式組織應用程式的核心商業邏輯。 有很多的透過此命名空間的型別中成員的路徑：切換如果巢狀化的陳述式的陳述式及類似。 例如循環複雜度的測量可以提供概略的有意義的改進，盡最大努力是否會簡化您的程式碼。

您可以取得非常特定的度量單位的特定部份的您程式碼基底以 NDepend 程式碼分析工具 ( ndepend.com )。 NDepend 提供功能強大的 「 程式碼查詢語言 (CQL) 對命名空間、 型別和.NET 組件中的成員。

請考慮 CQL 陳述式中 圖 1請注意我探查結合性及特定命名空間內的複雜性 (只是幾個許多計量 NDepend 讓可用) 等的度量單位。 這意味著我已經介紹圖形讓我可以把重點放在我的程式碼的可定義部分的努力。 如果我 ’m 成功中引入正變更，我應該會看到像是結合性和複雜性降低經過一段時間的度量單位。

圖 1 NDepend CQL

-- Efferent coupling outside a namespace
SELECT TYPES 
WHERE TypeCe > 0 
      AND (FullNameLike "MyCompany.MyProduct.Web")

-- Afferent coupling inside a namespace
SELECT TYPES 
WHERE TypeCa > 0 
      AND (FullNameLike "MyCompany.MyProduct.Web") 

-- Top 20 most complicated methods
SELECT TOP 20 METHODS 
WHERE CyclomaticComplexity > 4 
      AND FullNameLike "MyCompany.MyProduct.Web"

一個好-的副作用這個 tactic 是度量，可協助您保存線條，以及維護所謂的法則，一旦負債已被移除。它們會提供您向組成已經改善區域的新負債 reintroduction 一個 early 警告系統。

專用的改進資料流

您 don’t 住在一個真空。在您的改進努力期間機會是您被要求繼續傳送新的功能和修改現有的功能。傳遞壓力會造成的被下武器的感覺。但維護的生命應該服從，而不是嘗試略過事實。

應付這的方法之一是安全的企業在提供資源的核准 — 個人、 一組或整個小組 — 若要改善負債同時具有傳遞新功能的項目。

這可以是非常有效的策略，但最適合時整個小組 (所有開發人員和修改程式碼基底的人員) 中所做的改進採用一部分。請試著定期旋轉為配對的個人。開發者所被改進資料流中最長旋轉出，並保留其他開發人員簡短上什麼發生新的組。

透過深壓淺知識您取得集合的擁有權比較接近藉此降低風險，並改進的設計。有時您尋找介於直接在嘗試將傳遞一些新功能的方式改進的機會。每當您新的或已修改 」 功能啟動工作，它 ’s 檢閱清單以決定是否小組 hasn’t 已識別為改進交集 ’re 即將執行的工作區域非常好的作法。

改進的機會發生的時間，通常已識別上即時而達成差別下一次的幾個簡單 refactorings 一個隊友遇到程式碼。

有 ’s 常數的成本利益分析改善現有的程式碼基底 (Code Base 時傳遞新功能時就會執行。如果改進似乎太昂貴，將它加回您的清單，並討論您改進規劃中。

逐一查看、 重複、 逐一查看

某些負債 ’ve payed 後。請回到步驟一，並識別、 制定優先順序並建立共識需要修正，右邊的下一個項目上的時間？

[是]，但那里稍微它比 mindlessly plowing 透過您的清單。您一定要確定您不造成更多負債比您修正。您應該也會定期併入您 
learnings 未來的努力，在新的開發過程中，並改進努力攤。

定期變更以改善程式碼基底的機會。它們浮現和其重要性 ebbs 和流程。高感興趣負債的動態性質的理由變更發行到發行版本。

什麼工作對我排程每週會議與檢閱負債的新項目，並按照優先順序排列現有負債項目積存的開發人員一個簡短。這會讓建置的共識活著和全新清單。再次，我提供優先權以修正 ’s 可能會減慢您的目前版本或專案的負債。

開始會議檢閱新的項目。具有識別項俯仰其大小寫，並將其投票放置：與否，它有利用在積存中的包含不會吗？一旦您消失至新的項目，檢閱舊的項目。有的工作，不再適用嗎？有將會在完成此工作的即時運算值，也就是將它移除日常 impediments 嗎？上次，排定優先順序對其他人有機會 — 回覆陣序規範您的清單。在清單頂端的項目應該進行下一個非常改進。

按住 [線條]

雖然您和您的小組成員 merrily 付向高感興趣技術負債下，您可能也會傳遞新軟體。深入了解穩固的程式設計技巧，並會在您的程式碼中產生新的模式，套用往此知識。它 ’s 可能加法類工作將 pile 上建立 inescapable 慣性的現有技術負債。

它 ’s 重要您設定為新的工作您業務關鍵人員的期望。較高品質花比 rushed get-它-完成-樣式的程式碼完成，所能獲得更多的時間。此事實話題回到我十二月 2009年文章回所引進的系統思考概念。對我而言，此為文化特性的屬性。也就是組織可以認為 sustainably 長的詞彙或繼續執行一個購買現在，支付稍後 mentality — 喔的技術負債因此肥沃 breeding 地面。永遠不會忘記中央的問題如何做我們結束此一開始嗎？

雖然您學習如何改善程式碼基底，將很可能開發套用到新的程式碼有些小組規範。我建議擷取這些在像 Wiki 工具和持有小型、 非正式學習工作階段您共用您的發現與您的小組。您也將開發技術來處理類似的改進項目。當您注意到完成修正設計有缺陷或清理實作三或四次 codify 小組 ’s doctrine 中相同的動作。也就是它寫下在已知的地方，並非常只告訴人們它 ’s 那里。

放在一起的工作

技術負債是人的問題。透過缺乏的知識或不實際的期望的人建立混亂，而且現在處理的後果。然後它採取工作以群組的修正它的人。

提供像這樣的建議是所有康復個良好，而且我是如果您的專業且可能人 ’s 激情有關他們特殊功能的軟體 weren’t 完成協議中感到驚訝。

成功轉向需要牽涉到每一個人的值，系統中的基本變更 — 整個小組。品質經濟效益證明支付回到最後，但是您必須採取短期該步驟的信心。您有之內就贏得了 [傷心小棧和心智才能變更某個文化特性而且，可以是的確很難的工作。我可以製作最有用的建議是：don’t 移它單獨.取得背後努力小組，並確定每個人都有一個 stake 結果中。

設定像是 「 我們希望 90%的涵蓋範圍 」 或 「 我們想要測試導向開發 (TDD) 一直 」 的目標是相當無意義的。應付會減緩您目前在並在不久的將來的問題區域。這可能表示引入 TDD 和涵蓋範圍報告住 — 或它不可能。它可能是更基本像並確認您的小組知道物件導向分析及設計的基本概念的東西。

開始進行差異

雖然我希望我提供您一些工具和技術對於處理負債，或至少在做一些隱含的想法和有的經驗的明確，它 ’s 重要瞭解技術負債處理是十分產品產品問題。您，例如可能在環境中有 ’s 不大量的開發和商務合作對象和俯仰試用版的律師準備與您情況，您必須尋找之間的信任的地方。

有 ’s 告訴您，如何為驅使下負債，沒有現成的程序，但至於 時 和 位置 ，今天是美好的一天開始進行差異。三月朝技術卓越可以是緩慢及概略中開始。它 ’s 只能透過持續的努力、 學習和，上述所有的常數、 提取時間，將負債行走的程式碼帶回成黑色 tough 透過一個 earnest 態度。我建議您停與程式。不只會增加您的客戶的值，您將會大幅擴充工匠 ’s 工具箱。

Dave Laribee coaches 產品開發小組在 VersionOne Inc.他 ’s 頻繁的演講者在本機和國家 (地區) 的開發人員的活動，並已被獎賞一Microsoft 架構 MVP 2007 和 2008年。他在 CodeBetter 部落格網路上將寫入 thebeelog.com。