作者 | Scott Carey 譯者 | 彎月

出品 | CSDN（ID：CSDNnews）

“債務就像陷阱，進去容易，想要脫身卻很難。”

—— Josh Billings，美國著名的幽默作家

技術債務是科技行業最令人頭疼的問題，就像生活中一提到債務就會讓人感到壓力重重。擺脫債務是一件苦差事。

特別是在軟件工程中，技術債務通常指的是頗有年頭且會占用大量工程師寶貴時間的系統。技術債務必須得到妥善地管理和維護，且應最小化。技術債務往往坐落在積壓事項的最底部，管理不善就會拖垮你。

然而，凡是技術債務就一定是這個樣子嗎？

工程組織中越來越多的人認為，技術債務應該是所有軟件開發人員工作的核心部分，積極管理技術債務不僅可以讓團隊免于被拖垮，而且還可以超越競爭對手。

什么是技術債務？

這個概念最初由計算機科學家Ward Cunningham于1992年提出，指的是技術系統因構建短期解決方案而引發的一系列權衡，這些欠下的債務將來必須以工程作業的形式償還。

正如軟件開發人員 Martin Fowler 在 2003 年所描述的那樣：

這個比喻說明，選擇快速的折中方案會導致我們背上技術債務，就好像金融債務一樣。技術債務與金融債務一樣也會產生利息，我們將不得不在未來的開發中付出額外的努力。

根據 Stripe 2018 年的開發人員指數報告，軟件開發人員平均每周需要花費13個小時以上的時間來解決技術債務問題。現如今，隨著應用程序變得越來越復雜，管理這些債務的重要性也達到了空前的高度。Stepsize 的首席執行官 Alexandre Omeyer表示：“所有你認為是負債的代碼都是技術債務。”

技術債務的形式多種多樣。InfoWorld 專欄作家 Isaac Sacolick 去年寫道：“就應用程序架構體系的底層來說，技術債務可能是一小部分需要重構的代碼、需要升級的庫或者修復的單元測試；而從高層來看，技術債務包括重新設計復雜的單體應用程序、移植過時的 Web 服務協議、將多個平臺整合成一個標準、清理數據債務問題、現代化基礎設施、引入可觀察性實踐或自動化積壓的手動測試用例。最糟糕的技術債務類型是‘著火的平臺’，意思是說”平臺經常突發影響業務的中斷和意外。

雖然相較于與“著火的平臺”苦苦糾纏，每個人更加希望發布閃亮的新功能，但只有團隊持續付出積極的努力來解決技術債務，開發人員才能避免長時間的痛苦。

Sacolick曾表示：“解決技術債務常常會被忽視，因為這些工作無法解決緊急的業務需求，尤其是在不怎么緊急的情況下，投資回報率不明確，因此被認為是可以推遲的。凡是長期的維護工作都會面臨這種遭遇，無論是代碼還是房屋。”

窺探技術債務的深淵

Mik Kersten是《Project to Product》一書的作者，也是Tasktop 的創始人，他表示：“我們需要將技術債務視為首要問題，需要主動解決。然而不幸的是，對于很多人來說，這是一個新穎的概念。”

對于許多工程團隊，尤其快速發展的組織中的團隊來說，技術債務似乎與推出新功能之間似乎勢同水火。但在Honeycomb的首席技術官與聯合創始人Charity Majors來看，技術債務是“成功的標志，它意味著你還活著。”他表示，“千里之堤毀于蟻穴，我們必須妥善處理小問題。”

雖然說起來容易，但是要想認真地對待技術債務，整個組織都需要進行文化轉變。

RedMonk 分析師 Rachel Stephens表示：“對于許多企業來說，能夠按照優先級分配待辦事項本身就是一個挑戰，尤其是很多公司都會獎勵推出新產品，但對于管理技術債務卻沒有任何特定的基于績效的激勵措施。”

Tasktop 的 Kersten也表示：“僅對推出新功能的工作提出獎勵，就會將自己置于技術債務死亡的漩渦之中。”

如何承擔技術債務

LaunchDarkly的首席技術官兼聯合創始人John Kodumal早些時候曾表示，雖然“技術債務在軟件開發中是不可避免的”，但主動減少債務總好過被堆積如山的債務壓垮并影響到其他工作。

為了能夠主動承擔技術債務，你必須將技術債務視為正常敏捷流程中的一項工作。

Sacolick 表示：“維護應用程序、避免或延緩系統進入遺留狀態的關鍵就在于，組織和團隊如何管理技術債務。”我們必須積極主動，“制定政策、約定和流程，將減少技術債務的工作視為一項長期的成本。”

許多團隊都會投入一定的人員和時間來解決技術債務，例如每個沖刺的20%。然而，Tasktop 的 Kersten 建議將項目的截止日期以及團隊的能力考慮在內，采取一種更加靈活的方法。他說：“你應該衡量業務成果和技術債務的投資，并確保二者的平衡。將技術債務擺到眼前，這樣你隨時都能看到還有多少債務需要償還。然后再設置一個目標交付百分比，當然這個比例必須隨時間動態變化。”

對于云存儲公司 Box 的首席技術官 Ben Kus 來說，償還技術債務必須出現在所有工程團隊的擠壓工作列表中。“當然，技術債務的償還會被推遲，但這是一項長期的任務，你必須持續投入時間和精力。”

但Kus不建議指派工程師專門解決技術債務，他表示：“千萬別這么干，這會迫使某些員工離職。沒有人愿意成天和技術債務、代碼重構或類似的任務打交道。”

在Box，他們會將開發的工作以及在沖刺的過程中、事后分析和值班期間涌現的問題，平均地分配給各個工程團隊。“我們有一個嚴格的事后分析流程，我們會找出有待解決的問題，以防止同樣的問題再次發生。雖然我們不會說放下手頭的一切工作，專門解決某個問題，但我們會明確表示，如果問題再次發生，就會追究責任。如果同樣的問題再次出現，那將是非常不愉快的經歷。”

輪流值守的重要性

由于工程團隊希望有效地挖掘和衡量導致團隊開發速度減慢的技術債務，隨時待命變得越來越重要。

Honeycomb的Majors支持讓從事開發新功能的工程師定期輪流值守，專門負責修復bug、重構代碼以及償還技術債務等工作。他表示：“有一個主要負責小問題的工程師很重要。工程師不應在值班期間從事產品開發工作。這樣可以增加系統開發的靈活性。”

Chris Evans 是 Incident.io 的創始人，該公司是一家專門從事應急響應的軟件初創公司。Evans告訴我們：“跟蹤并記錄一切的意義是減少那些‘不言自明’的知識。在輪流值守期間，你需要處理自己不太擅長的工作。”

雖然聽起來這項工作的壓力很大，但我們不僅可以解決問題，而且還可以在事后的分析中強調出現的問題，這樣解決技術債務的重要性也會變得更加明顯。

Evans曾在博客文章中寫道：“承擔運營的工作可以幫助我們收緊發布新功能與運行系統之間的反饋循環。這有助于我們做出務實的工程決策，并在發布新功能和支持與改進現有功能之間保持健康的張力。”

例如，Incident.io最近遇到了這樣一個問題：他們的一個數據庫交互出了問題，導致工程團隊的開發速度減慢。Evans說：“我們投入了一周的時間，建立了一種更好的與數據庫交互的方式，這對我們將來構建每個功能都產生了一定的影響。”

類似于這樣的改進值得慶祝，就像解決了某個重大問題或發布了某個新功能一樣，“償還技術債務的重要性不亞于贏得新客戶。”

《金融時報》對于技術債務的重新思考

在過去六年中，《金融時報》一直在重塑其處理技術債務的方法。早在 2015 年，這家英國報紙網站由一款名為 Falcon 的“大而全”的應用程序搭建。2016 年，該公司的開發人員將 Falcon 轉換成了一組微服務，總稱為Next。他們的 332 個代碼存儲庫由一組職責明確的團隊長期負責，從應用程序、內容發現和廣告到中央平臺，他們只需要負責 72 個代碼存儲庫。

《金融時報》的客戶產品技術總監 Anna Shipman 在 4 月于倫敦舉行的 QCon 會議上表示：“大約只過了一年，我們的系統就開始出問題了。”他們的技術團隊搞不清楚整體的技術戰略，以及哪些服務歸誰管。這導致技術負債越來越多，甚至出現了“鬧鬼的森林”——沒有人愿意接管的孤立代碼庫，而且愿意輪流值守的工程師數量也不斷減少。

Shipman的一位同事跟她說：“感覺這個系統不是我們的，我們根本駕馭不了。我們只是在不斷往里塞東西。”

為了戰勝這種困境，他們付出了巨大努力重建秩序，清除“鬧鬼的森林”，接受復雜性，并有效地管理整個系統。只有明確技術棧的所有權，組織才能更有意識地對付技術債務和鬧鬼的森林”。

Shipman表示：“這項工作不同于常規的功能交付，你需要留出適當的時間，并安排專人去解決。這項工作永無止境，不是說稍微整理一下就萬事大吉。”

雖然他們沒有統一決定分出20%的工程時間來清除“鬧鬼的森林”和管理技術債務，但 Shipman 認為如今團隊能夠更好地平衡功能交付與技術債務了。