英文原文：
我們曾遇到過最后期限即將到來、時間非常緊迫的情況。當時，我們必須盡快修復Bug，然而其中的一個Bug特別堅韌，任我們百般努力也無可奈何！隨后，我的某個同事接手了調試工作。他強行寫入了一些應該從數據庫中檢索來獲取的值——它們在系統運營的最初幾個月里不會發生變化——隨后……系統神奇地正常工作了！
對于這類“莫名其妙的代碼”，我的這位同事以非常風趣的埃及俚語稱之為“Habya’a”，意即臨時拼湊的組件。
我同事和他的創造性俚語相仿，Ward Cunningham在1992年把這種糟糕的代碼稱之為“技術債務”——在Wiki百科上對技術債務的定義是“在判定某項任務完成之前，需要先完成的工作”，而Steve McConnell將技術債務定義為“一種設計或構建的方法，它是一種短期內的權宜之計——因為它會產生這樣的一種技術環境：與現在動手完成相比，稍后完成同樣的工作需要更高的投入。”
如果從實用主義的角度來看待技術債務，我們會發現實際上它并不總是件壞事。當截止日期已過的時候，技術債務就相當于為了交付而付出的“高速公路的過路費”。我的另一個朋友曾經這樣對我說“技術債務就像在沒有停車區域的地方停車：亂停車是錯誤的行為，而且會導致我們吃罰單，但有時候我們為了趕上旁邊建筑里的一次重要約會，就不得不這樣鋌而走險！”
所以，有時候效益成本比決定了一切！然而技術債務必須及早解決，它與像金融上的債務相似的另一個地方，正是在于它們都會產生利息。
這里的利息是指在每次維護系統的過程中，我們面對以下狀況需要付出的努力：由于緊耦合、過大的類、未經測試的代碼或任何其他形式的技術債務，而導致代碼和/或設計的維護變得極其困難。
從我的觀察來看，技術債務的總利息并不固定，而是會隨著時間的推移而增長。我的意思是，在面對一個帶有技術債務的系統時，每一個Sprint中我們都需要在系統維護上花費比之前更多的精力。這個現象源自以下兩項因素：
- 維護時很有可能會引入額外的債務，這是因為當我們的系統中擁有一些混亂的代碼時，任何維護都會遵從相同的代碼和/或設計方法。這些新增的債務會在下一次維護時消耗更多的精力，而這一切將不斷重復。
- 隨著時間的流逝，由于沒有遵從設計模式以及缺乏文檔化，更多的開發者會從各自對代碼或設計片段如何工作的假設出發，給系統打上不同的補丁。毫無疑問，這將在系統中引入新的Bug。而修訂這些新Bug又會引入更多的Bug……
基于以上原因，每份利息都會對技術債務的增長“做出貢獻”，因此這里的利息實際上是復利計算方式。復利計算使用以下指數公式：
Yt = Y0(1+r)t
在這里，Yt是在第t個Sprint時的債務值，Y0是債務初始值，r代表增長率，而t代表Sprint序號。在敏捷項目環境中，“t”是一個整數，因此在這里我們可以說，技術債務將隨著時間的推移按幾何方式增長（因為幾何函數是指數函數的一個特定情況——當指數函數中的“t”永遠取整數值的時候）。
因此，隨著混亂的代碼庫不斷積累，系統將變得更加脆弱且難以維護。技術債務利息增長的另一個副作用則是，由于用在維護上的時間越來越多，導致團隊生產力遭到了抑制。
在某個項目中，我們在很長時間內都在忍受這樣的糟糕代碼實踐，當我們最終進入正式投入使用前的階段時，系統突然之間就崩潰了！我們不可能進行重構的同時，又能夠避免在系統中諸多部分帶來重大影響，因此我們決定一切推倒重來！
圖1：累計柱狀圖展現了技術債務的利息隨著時間推移呈現幾何增長的態勢。圖中所用的是假設值，而非真實項目數據。
下一節將簡要介紹一套用來管理技術債務的推薦流程。在初始假設中，我們認為技術債務是一種風險。這項假設基于對風險的定義：“可能會影響至少一項項目目標——范圍、計劃、成本或質量——的一件不確定事件。”技術債務非常符合這條定義，因為它對項目來說是一項潛在威脅，如果不能及時解決的話，可能會對項目造成負面影響。
作為敏捷愛好者，我將把這個流程放在Scrum項目中，來進行分析。實際上我發現，非常有必要管理敏捷項目的技術債務。因為與其他方法相比，敏捷方法中的快速交付節奏更加鼓勵快速且不干凈的代碼風格。而且在敏捷項目中，我們只進行恰到好處的設計和架構，并通過重構來跟上任何需求的調整；這樣的后果是，在某種程度上我們總會擁有技術債務，因為我們總是不得不在展開設計的過程中優化我們的代碼。
技術債務管理流程如下：
- 設定技術信用限額（TCL）——TCL是我們愿意借出的理想工作小時數或用戶故事點的最大總額。可以用總項目大小的百分比形式來計算該限額，例如10%。
- 識別技術債務因素——技術債務因素是指這樣的情況：某位團隊成員希望繞過一些良好的代碼、設計或測試實踐，以便實現快速交付。我們應該在每天Scrum會議通過小組討論來識別這些因素。
- 記錄技術債務任務——對于每項技術債務因素，需要在技術債務記錄里添加兩項任務，并使用立項工作小時或用戶故事點的方式來估算其大小。這兩項任務是：
- 選擇任務——在Sprint規劃會議中，選擇希望開拓的技術債務因素。技術債務因素的選擇應該基于產品所有者確定的優先級。
- 從TCL中減去償還型任務所關聯的技術債務的大小（限額扣減）。
- 在Sprint待辦事項列表中增加與開拓型任務相關的技術債務，并將其大小累加到項目總大小上。
如果我們發現TCL已經快要用光了，那么接下來我們需要：
- 在Sprint待辦事項列表中添加一項償還型任務。
- 在完成該償還型任務后，對TCL增加等量額度。
這樣，我們將TCL作為監視系統，以便在技術債務開始積聚的時候警告自己，以便我們努力使其恢復到健康水平。
圖 2：技術債務隨著開拓和償還任務發生的變化，以及與技術信用限額的對比。當開拓任務完成時，技術債務上升，而償還任務完成時則下降。
結語
將技術債務作為風險來進行管理，并使用技術信用限額，能夠有效地減少技術債務的負面影響，同時令收益最大化——特別是在敏捷方法中，我們很容易濫用技術債務，將其作為一種加速交付的手段，因此也就需要更加關注技術債務。
關于作者
Yaser Marey是來自埃及的軟件工程師、項目經理、PMP和Scrum大師。在過去14年間，他領導團隊為國家和區域客戶開發企業級軟件系統。他是敏捷、精益和持續改進的狂熱愛好者，他相信這些對埃及和中東的軟件產業來說必不可少。Yaser在他的博客中分享了軟件架構和項目管理方面的經驗。
it知識庫：Habya'a（臨時拼湊的組件）與技術債務，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
