本文章是由機器翻譯。

清除程式碼

利用靈活的技術清償技術負債

David Laribee

在每個基礎碼有深色的邊角和 alleys 您怕。’s impossibly 脆弱的程式碼 ； bites 回迴歸錯誤 ； 當您嘗試將遵循，將您 mad 的磁碟機的程式碼的程式碼。

防衛盾 Cunningham 建立美麗隱喻硬變更、 容易出錯部分的程式碼時他 likened 到財務負債。技術負債防止您從 profiting 從 「 以黑色 」 保持向前，移動。為在真實世界有 ’s 廉價負債中，低於您興趣的負債都可讓低風險財務樂器。然後 ’s 昂貴的東西更多負債 pile 高利息的信用卡費用。

技術負債是一個拖曳。它可以消滅使維護令人討厭，很難，或，在某些情況下不可能的生產力。超過明顯的經濟缺點有 ’s 技術負債的真實心理成本。沒有開發人員喜歡坐向他的電腦在早上知道他有關 impossibly 脆弱的圖示複雜的原始程式碼。挫折和 helplessness 因此 engendered 通常是根本原因的更多的系統問題，例如開發人員的更換率 — 只是其中一個技術負債的真實經濟的成本。

每個程式碼基底我投入或檢閱包含技術負債的一些量值。一種負債的類別是相當無害的：您的系統的穩定、 很少修改 recesses 中 bizarrely 具名類型之間的 byzantine 相依性。另一個是 sloppy 的程式碼，是很容易地修正上特別色，但通常忽略中來解決高優先順序問題快攻。有許多的多個範例。

本文將概述工作流程並處理高感興趣負債的幾個戰術。程序和我詳細說明的作法 aren’t 新。它們就會採用從 Lean/Agile playbook 直線。

修正負債的大小寫

「 應該我們修正技術負債 」 問題是我的活頁簿中可想而知。您當然應該。針對您的目標的技術負債適用，因為會變慢您經過一段時間。有 ’s 知名的視覺效果稱為變更成本曲線 (請參閱 的 圖 1)，說明 100-百分比-品質-測試為導向] 方法和 cowboy-coder-hacking-with-duct-tape 方法差異。

圖 1 成本變更曲線的

變更曲線的成本會說明該高品質，簡單，且容易遵循設計可能更最初成本但會造成較不技術負債 — 後續的新增和修改程式碼會較不昂貴經過一段時間。在品質曲線 (藍色) 時，您可以看到初期成本較高，但是它 ’s 經過一段時間可預測。劈砍它曲線 (紅色) 取得一個較低的成本項目，但未來開發、 維護和擁有一個產品的總成本，而它的程式碼會變成以往較為昂貴。

來防衛盾 Cunningham ’s 第一次定律的程式設計 」 ( c2.com/cgi-bin/wiki?FirstLawOfProgramming ) 狀態，「 降低品質延長開發時間 」。

「 品質的軟體會採用最少的開發時間。如果您有盡量、 完整的測試和剛右適合的設計非常簡單的程式碼，新增及變更是以最快的可能方式因為影響是最低。因此，如果您劈砍東西出，劈越您砍最慢跳因為加法或變更的成本會隨著每一行程式碼 」。

只要 Put、 技術負債會經過一段時間減少您的小組的產能。

在軟體開發過程中我很棒 joys 之一 relishing 未經處理的產能的感覺。競爭和 converse 感覺，對我最少是痛苦。當我 ’m 不具生產力且它 ’s ’s 痛苦 robs 我潛在產能所謂 「 好日子上班 」 的痛苦。有許多來源的痛苦在軟體開發過程中，但無更明顯比嚴格和 chaotic 程式碼基底。此心理效果都會採用一個免付費它依序會使得延隔時間的產能的團隊士氣。

系統想：

若要修正技術負債，您需要建立購買-從中共同工作人員和小組成員攤。若要執行此動作，您需要啟動 systemically 考慮。系統想成是長程的思考。它是投資思考。’s 的努力置於今日會讓您的想法的步調一個可預測且持續在未來的進度。

或許它 ’s 最簡單的方式說明系統想到的比喻。我住在 downtown 亞特蘭大，喬治亞中稱為 Inman 公園的 quaint 小鄰居。我 ’m 大多是很高興有。我保留，但是，都市規劃的表面上完成忽略的相關部份 irritation。亞特蘭大街道是 byzantine]、 [梅茲類似]、 [瘋狂 provoking。當您錯過上場時，您 can’t 只是迴圈回。如果您這麼做您會傳送給誰-知道-何處 spiraling 路徑上。那里似乎是幾乎 rhyme 或規劃在世界的這個否則非常愉快角道路的理由。

對比這具有更有條理的街道和 Manhattan 中紐約市的途徑 (大部分的它，還是)。它 ’s Marine 團切入講師如同設計該城市。途徑伸展島北方向其長度下的南方和街道表單整理，latitudinal 資料標記的長度。此外，街道和途徑將會進行命名，以數字順序：第一個轉角，第二個轉角、 42nd 街名、 43rd 街名以及等等。您很少查核個以上的區塊以錯誤的方向。

什麼是根造成亞特蘭大和紐約市之間差異，在此維度中的比較?

亞特蘭大街道已形成牛穿著向路徑下。你聽說我右， 牛路徑 。某些需要訴訟經常都市中心和 suburbs 之間移動在它指向 [以為某些牛仔 「 golly，wouldn’t 它是最簡單的方式將這些這裡牛路徑變成道路？ 」

紐約狀態 Legislature 套用願景，以及 forethought 不斷] 和 [最大城市狀態中的設計。他們選擇 gridiron 計畫的整齊有序、 可預測的街道與途徑。它們被想成未來。

這篇報導取得系統想到的要素。慢速立法處理程序時，投資時間和願景的承諾中累積的最大的被除數為 系統的存留期 (Lifetime) 。為 True，則您必須應付古怪的封包的 Manhattan，平均街道上，但您可以認識您的工作環境在幾天。在亞特蘭大，被取得遺失的一年，我感謝負責的 [通用定位系統 (GPS) 的系統 thinkers 每一天]。

透過專案的產品

基本上漏洞是您有開發小組完成專案，然後就會擲回它透過牆維護小組的概念。沒有犯錯、 您正在處理某個產品，且如果它成功移至住一個長度、 長時間。

如果您甚至幾年的經驗作為專業開發人員可能遇到不斷增加的重力影響。開發 isn’t 是用來持續或會變得很複雜或變更的軟體的部分。和六個月後，您做什麼？修改它嗎?擴充它嗎?修正 Bug 吗？

有用的軟體有有時棘手習慣的 sticking 很長的時間。它 ’s 往上您要挑選您想要與回復執行重做的比喻。將傾向美麗目的地為美國加州 Redwoods 活實體 enduring 在數個世紀，並達到最高高度的樹系或將您允許殘酷 Kudzu 藤蔓来挨餓光線的樹系嗎?

基本工作流程

這個時候我希望我相信您技術負債可以採取恐怖的付費電話心理健康情況與客戶 ’s 下方線條上。我希望，也，接受需要採取建立一個 longer-range 檢視產品上。

現在 let’s 算出您如何可以挖掘自己超出這個漏洞。

無論該商店我有意義是，基本的工作流程的處理技術負債 — 的確任何種類的改進 — 是可重複。基本上，您想要四件事：

1. 識別您可在此有負債。多少負債的每個項目影響公司 ’s 底端列] 和 [小組 ’s 產能？
2. 建置商務實例和偽造共識優先順序與那些受負債小組和共同工作人員。
3. 修正的負債選擇頭上使用已證實的戰術。
4. 重複此動作。回到步驟 1 來識別額外負債，並按住線條上您所做的改進。

它 ’s 值得一提，對於軟體處理程序 nerds 出有此工作流程適應從稱為 [理論的限制 (目錄) Eliyahu Goldratt ( goldrattconsulting.com ) 所建立的商務管理方式。目錄是系統思考模型，提供的架構，以改善系統的整體產能。這是毛額簡化，但目錄 predicated 上系統 (一種製造設備，例如) 只是高生產力的為其最大的瓶頸的想法。值，例如功能要求或汽車或任何 sellable 的項目是 conceived 的、 設計、 產生，及部署。一項功能可能會要求的內部或外部，一個客戶，該功能流向您的業務 (系統) 轉換從了解有形的結果。當這些功能 pile 品質保證小組的前面，會發生什麼事？可以滿足有 ’s 開發比開發團隊的多個要求時，會發生什麼事？取得瓶頸，並在整個系統變慢。

’s 很可能會有負債的許多區域 — 許多瓶頸 — 在您的程式碼基底。尋找您減慢最的負債將會增加您輸送量最大淨影響。瞭解，然後處理負債並產生改進成小組 — 為系統 — 是最有效的方法進行正變更，因為更多的眼睛與程式碼上的指針等於較少的風險而且效果更好的設計。

識別區域負債

它 ’s 重要您可以點一下問題區域。如果您 haven’t 被追蹤它們在一個 Wiki] 或 [共用的清單或程式碼註解中，您第一項工作是找出負債。

如果您處理小組，我會建議呼叫來開發具體清單頂端區域負債程式碼中的會議。重要 isn’t 詳盡的清單。專注於擷取 big-ticket 項目。這個會議是您第一個機會，作為您的小組領導人啟動偽造共識。更多比簡單大部份的成員應該同意，並了解它使清單項目。

一旦清單使其持久。建立 Wiki 主題，請將它寫上 (與 「 DO NOT 清除 」 prominently 所撰寫的其中一個角落)，電子白板或任何文字在您的情況中運作。您選擇的媒體應該是可見、 永久且容易使用。它應該在定期您正面。您需要回到此清單並 groom 它。人類家園具有有限的短期的記憶體，因此我建議保留 5 到 9 最惱人的項目之間的清單。don’t 擔心這麼關於保持清查 — 重要項目會呈現一次如果他們真的 ’re，好，重要。

使用度量資訊來找出問題區域

有時候它 ’s 硬尋找負債，尤其是小組是新程式碼基底。萬一其中有 ’s 沒有集體記憶體或 oral 傳統上繪製，您可以使用靜態分析工具 (例如 NDepend ( ndepend.com ) 來探查程式碼為更麻煩的點。

工具，在最佳輔助或或許甚至是第二個選項。工具 won’t 告訴您該怎麼做。它們會但是，提供您決策的輸入。程式碼負債但中產品工作日的工作和天出可以一定指向造成大部分痛苦那些黑暗角落的人員沒有單一公制。靜態分析工具將會告訴您具有實作負債。sadly，它們會在不通知您您尚未負債由於至諸如不良命名、 可測知性、 效能，及其他更質化的設計和架構性考量的因素。

(如果您有測試)，了解測試涵蓋範圍可以是另一個有價值的工具，探索隱藏的負債。清楚地，如果有 ’s 大缺少實心測試涵蓋範圍您系統的一部份，方式您可以確定變更 won’t 有品質的下一版的明顯的影響？迴歸錯誤很可能會出現，建立瓶頸品質保證管理人員和潛在困窘和限於客戶找到缺失的營收的損失。

使用版本控制系統的記錄功能來透過上個月或兩個產生變更的報告。尋找收到大部份的活動、 變更或加入項目，您系統的部分並 scrutinize 的技術負債。這將會幫助您找出挑戰您今天的瓶頸 ； 有在中您的系統很少變更的那些部分修正負債 ’s 極少的值。

人類瓶頸

如果有 ’s 只有一個開發人員能夠處理元件、 子系統或整個應用程式，可能會遇到瓶頸。個別程式碼擁有權和知識筒倉 (其中 「 Dave 適用於帳戶應款關係人模組 」 — 現在有 ’s 痛苦的記憶體)，可以封鎖傳送，如果該人員離開小組或有一堆其他工作要做。您在個別的擁有權已發生可讓您專案中尋找的地方考慮優點及改善設計，讓其他人可以共用負載的範圍。消除瓶頸。

有極大的好處是衍生自極端的程式設計作法的整體擁有權 ( extremeprogramming.org/rules/collective.html )。整體擁有權與任何您小組的開發人員被允許變更任何的程式碼，在您的程式碼基底 「 來新增功能、 修正 Bug、 改善設計或重整。沒有一個人變成變更一個瓶頸 」。

唉呀，有 ’s 該字再次，「 bottleneck 」。藉由啟用集合的擁有權，消除您系統只有單一程式設計人員的深的部分 — 可能查核關閉工作或取得擊中匯流排的人員 — 所知。沒有與程式碼基底共同擁有較少風險。

我的經驗設計也是比較好。二、 三個，或四個讀寫頭會比一個幾乎可以確定可較快得到更好。在 [共同擁有程式碼基底，團隊設計 ethos emerges，然後 supplants 個別的特性和 quirks。

我呼叫集合的程式碼擁有權作法是，但整體擁有權真的是 emergent well-functioning 小組的屬性。想想它 — 多少你的顯示和工作對 「 您的程式碼 」 與整個小組共用的程式碼吗？什麼在軟體開發過程中通常稱為團隊其實是工作群組與程式設計工作 doled 的其中一個工作分派編輯器根據誰處理的特定功能、 子系統或 
module 在過去。

為一小組排定優先順序

我之前說過 ’s 重要在努力以改善涉及整個小組。為一個 Agile 的類似指導員我按住密切到真言 人員支援的世界，它們有助於建立 。如果您 don’t 的支援的重要大型，努力把促進持續改進的文化特性可能會非常困難以關閉地面更少 sustain 取得。

取得共識是索引鍵。您想要小組成員來支援選取目前的改進計劃的大部分。我搭配某些成功 Luke Hohmann ’s 「 購買功能 」 方法，從他書籍 創新遊戲 ( innovationgames.com )。我嘗試在遊戲的總 over-simplification 並催促您簽出活頁簿，如果它看起來像是在您的環境中工作的項目。

1. 產生您想要改善的作業的簡短清單 (5-9 項目)。在理想的情況下這些項目是短期路徑中。
2. 限定困難的項目。我喜歡使用 t 恤大小的抽象概念：小型，中型、 大型或 extra-large (估計的改進機會有關，請參閱資訊看板如需詳細資訊這種作法)。
3. 給予您功能價格，根據其大小。比方說小型項目可能成本為 $ 50、 $ 100 等等的媒體項目。
4. 給予每個人都一定數量的金錢。這些金鑰這裡是 scarcity 引入遊戲。您希望人員可以有共用區他們錢買 ’re 感興趣的功能。您想要單價，說，中型的功能，其代價其中沒有人個人可以購買。它 ’s 寶貴尋找超過單一個人後您看見優先順序嘗試要建立共識。
5. 執行短遊戲，也許 20 或 30 分鐘的人可以討論其中的長度 collude，並俯仰其大小寫。這可以是相當 chaotic 和也相當有趣，您看到影響座位是在您的小組。
6. 檢閱所購買的項目，並且他們購買由何邊界。您可以選擇依購買功能來分次序您的清單，或更好使用功能遊戲 [購買] 結果與其他技術如下一個版本計劃的認知組合。

估計的改進機會

我之前說過評估負債項目或調整的改進機會大約在 t 恤方面大小。這是常見的技術在 Agile 開發方法中使用。其概念是您收集在相對大小方面的事情。smalls 一起，做為執行作業移媒體、 larges，...等等。

它不 ’s super-important 將大量的正確性帶到這裡的資料表。請記住：這些都是相對的量值和不承諾。您想要粗略的了解它在困難，而且理論是之後的項目數目的估計事情將開始甚至縮小。即使一個媒體項目實際上一對開發人員的兩個星期完成所花費時另一個月，平均有媒體會花大約三週。

經過一段時間，但是，您開始收集大型或小型何種項目的的良好範例真的是，因為您有的比較基準這將協助您在未來的估計。我各種大小的幾個範例過去使用作為一個輔助工具的估計新的批次的工作很好的效果。

這可以是很難 pill 来抑制管理。它們一開始想要知道完全多久一事可能會和說實話被告知，投資更多的時間中精確、 以時間為主的估計值時，您可能需要。

銷售計劃

既然你有計劃，它 ’s 時間來進行通訊的消除負債專案贊助者值。在現實情況下，這個步驟可能會發生識別與平行。牽涉到您的客戶從最開始處。之後所有計劃的開發即將要花時間、 努力，及 (最後) 金錢。您想要避免，代價，關於其時間和 dime 您花開發凝聚力的計劃的問題。

任何成功和持續努力絕對移除大量負債需要專案 ’s financiers 和贊助者的支援。撰寫檢查需要了解投資同仁您進行。這可以是一項挑戰，詢問人認為長範圍中，在未來與現在，從購買開移動支付稍後 mentality。說明 「 只是因為 」 只是 doesn’t 剪它。

問題是無可避免會詢問行政人員，「 Aren’t 您專業人員嗎？ 」您可能會覺得 Put 對抗 ropes 時探查沿著這行程式碼。它們之後所有 weren’t 付您專業時間和預算內提供高品質產品嗎？

這是很難的引數 」 計數器。我說 don’t 造成困擾。有勇氣和 honesty 呈現和它們的事實。這似乎有風險的方法會向下 boils 責任和信任的非常人類的問題。

couch 您引數，就像這樣：您擁有在要求的時間內成功的軟體，提供的量的金錢。若要達到此目的必須在商務壓力的回應中進行一路的折衷。現在，向前移以可預測和穩定速率，您需要處理這些折衷的效果。整個組織已購買它們，它現在 ’s 回支付的時間。

下一個挑戰是要證明非技術的同仁負債造成大部分的傷害。我的經驗業務主管回應量化、 資料導向引數支援的 「 數字 」 和 「 事實 」。我將數字和事實置於引號因為我們所有真的知道我們住在相對的世界中並沒有單一數字 (循環複雜度、 efferent 聯繫性，什麼您有幾行程式碼測試涵蓋範圍) 銷售變更。複合這個困難度，您需要溝通的最大的水管區域在經濟方面：為什麼會這樣比 ’d 喜歡 ； 為什麼做這項功能較慢的成本這麼？

辨識項擊敗不確定

在建置您狀況時 ’s Dale Carnegie 管理訓練系統老鼠 pithy 片語中，從 「 辨識項擊敗懷疑 」 是十分有用工具。因為是常見與這類的管理系統 (和一般我們專業領域)，擊敗部分則是縮略字。我詳細說明一些這適用於軟體開發的方法。但是，注意我省略第二個 E 的代表展覽，因為它似乎重複的現實狀況，例如豬最喜歡在第一個 E。

D 是 的 示範。有 ’s 優於放映及 tell 執行任何動作，而且這是什麼示範是所有相關。如果您追蹤您速度，這應該是很容易。顯示 DIP 經過一段時間 (請參閱 的圖 2) 時繪圖連接至越來越不夠彈性和硬變更程式碼。一旦您出售您需要保留銷售。

圖 2 追蹤開發速度

如果您使用 Agile 程序如 Scrum 或極端的程式設計，客戶意見反應事件都是不可或缺的練習。反覆項目結尾示範要給客戶的新功能。而當您遇到技術性負債 tar pits 會大大功能的數量和品質，同時坡道向上改進努力應該要能夠示範可獲得經過一段時間。較少負債表示更大的輸出和更高的輸出可產生更多的東西，若要示範。

如之前批評某人在慣用語進入，查核一英里他們鞋中。如果您更多技術經理鼓勵她使用開發人員上一些開發 empathy 變更的困難度的程式碼基底更困難的部份。問她看看一些程式碼。她可以依照它嗎?它是可讀取嗎？有 ’s 贏得您優勝者沒有更快速的方法。

E 是 的 範例。有 ’s 不像是具體的範例。尋找某些故事或已任一不可能完成的技術負債因為或建立重大迴歸分析的需求。挑選 riddled 副作用 ’s 無法讀取、 byzantine 的程式碼區段。說明客戶找到的缺失或需要大量的精力的這些屬性的程式碼率領從品質保證管理人員如何。

另一個功能強大的工具，Agile 處理程序可讓您是回溯。選擇發生南方最後幾個反覆項目中的本文，並詢問問題 「 為什麼？ 」取得根造成的這個特定的故事 couldn’t 完成、 花兩次只要您平均的故事，或超過單一反覆項目合併的原因。通常，非彈性的軟體將會是發生錯誤之或也許有因為迴歸 Bug 已 insurmountable 回復變更。如果您發現最後一個 「 為什麼 」 最後會被技術相關的負債理由，擷取分析短而直接在表單中。它 ’s 另一個羽在您的端點您引數中的另一個點。

F 是 的 事實。事實是很容易藉由來自。您未準時放開專案吗？發行後的缺失速率是什麼？經過一段時間是小組 ’s 平均速度？當傳遞，客戶已滿足軟體嗎？這些是想帶到 [商務] 資料表的事實的種類，我相信 ’s 最直接對說話商務生這些事實。

共同作業是一個索引鍵的項目。身為開發人員可以更輕易地提供技術的事實。尋找擁有預算的人員以取得協助。機率是有更清楚的圖片和更容易存取商務事實示範技術負債造成的損害。

A 為 的 比喻。我發現這特別重要。令人困惑，甚至 esoteric 商務人員有時會發現軟體開發。如果您前往您的贊助者與聯繫性] 及 [一致性] 及 [單一責任主要的談話時，會突顯的失去它們極佳的機會。但是這些都是在專業軟體開發過程中非常重要的概念，最終，它 ’s 建置資料導向的案例，對於處理負債的方式。我建議是避免專業術語，並解釋的比喻這些項目。

您可以描述為一家] 的卡片，例如結合性。告訴您的贊助者您速度已卸除的原因是因為進行程式碼的變更就像一個已經建立和非常精緻屋] 的卡中加入牆、 天花板或故事：需要異常穩定手的形狀、 大量的時間以及耐心等候，在手術作業而最後是不確定和 anxiety provoking 事件。有時候房子的卡片摺疊。

當採用隱喻和 simile，它 ’s 狀態您會這樣是個不錯的作法。左右對齊您作比喻，您嘗試要傳達的更多技術概念的簡短描述。使用房屋的卡範例，您可能會說，「 這是在效果上我們回應變更和加入新功能的能力有結合性 」

T 是 的 證明。有時候聽到相同的訊息從協力廠商可以有一個功能更強大的效果。這個協力廠商可能業界領導者或顧問。他們字可能移得更遠比您自己的原因是察覺為客觀的專家。

如果您 don’t 僱用外部顧問金錢，請考慮蒐集趣聞和見解免費提供業界以為領袖。雖然泛型 testimonials 所謂的最佳作法的相關可能不密封將協定，它們會增加整體的引數 gestalt。

S 是 的 統計資料。數字是哪一個都無所謂。有 ’s 常用文句，在管理，「 如果 can’t 測量它，您 can’t 管理它 」。我 ’m 不確定此傳統智慧會完整地，套用，但您肯定可以展示的情況。結合性和複雜性是可以用來顯示遞減的輸送量 (正在傳遞多少工時) 和越來越 calcified 負債與程式碼的基底之間的根本原因關係的兩個度量資訊。

我發現複合的統計資料通常是最佳的選擇 ； ’s 更容易了解程式碼涵蓋範圍的重要性，如果因此 implying，如果沒有顯示關聯性，您可以覆疊速度的降低與經過一段時間會減少一個程式碼涵蓋範圍公制。

任命前置字元

您的努力修正技術負債的採購綠色燈號便會變成很長的時間與一個有效領導人優勝者誰可以在業務方面溝通及誰有您組織中的決策者的影響力。通常，這就是您的專案經理，她主管在 CTO 「 副總裁的工程，或某人認知的授權單位的類似的位置。

這可以叫出有趣的 chicken 及 egg 問題。如何出售此人？「 設定管理 」 的程序太是開發人員 ’s 責任。第一項挑戰是要賣出賣方。您如何確切做到這點？辨識項擊敗懷疑!

下一步

到目前為止，我涵蓋識別負債小組及建置修正該負債的情況。我重複：在您小組和購買入與客戶之間的共識是在這些步驟的關鍵因素。

請步驟小型及 don’t 投資不少時間。第一次識別負債，一定需要時間超過當您逐一查看新的機會，改進的但當您建置管理您狀況時，只包括您計劃在上運作的那些項目。動靜上產能，可以是龐大能源保護裝置。

在未來的問題我查看其餘的工作流程包括消除負債的戰術和我涵蓋如何讓這個程序反覆，並從先前負債移除努力擷取課程中學到。

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

多虧到下列的技術專家來檢閱這份文件： Donald Belcham