什麼是技術債務 - 英國工程團隊指南

過去兩年中，「技術債務」的搜尋量增長超過35%，這在很大程度上是由英國工程團隊推動的，他們繼承了在截止日期壓力下構建的遺留系統，如今苦於維護或擴展這些系統。這個術語在Jira待辦清單和迭代回顧中被隨意使用，但大多數開發人員從未見過精確的定義，更別說系統性的應對策略了。

本指南涵蓋技術債務的真正含義、它的來源、如何衡量，以及在英國真實產品團隊中有效的實踐策略。它借鑑了Ward Cunningham的原始比喻和Martin Fowler的四象限模型，並將其與你在本次迭代中可以付諸實踐的日常決策相結合。

摘要

• 技術債務是選擇當下更快、更簡單的解決方案而非更好方案所產生的隱性返工成本。與金融債務一樣，它會隨著時間的推移累積利息。
• Fowler的四象限將債務分為魯莽與審慎、故意與無意，每個象限需要不同的應對方式。
• 透過靜態分析（SonarQube、CodeClimate）、測試覆蓋率、部署頻率、缺陷率趨勢和開發者痛苦調查來衡量債務。
• 最有效的策略不是「重構衝刺」，而是與功能開發相結合的持續改進：童子軍規則、針對遺留系統的Strangler Fig模式，以及用商業語言與利益相關者溝通。

技術債務的真正含義

Ward Cunningham在1992年開發金融軟體時創造了這個術語。他的比喻是有意為之的：發布不太正確的程式碼就像借款一樣。你現在得到了某些東西，代價是以後連本帶息償還。利息就是你在每個未來功能上花費的額外時間，因為程式碼庫比應有的更難工作。

這個比喻很有用，因為它重新界定了對話。債務並不總是壞的。一個快速發布MVP，在找到產品市場契合點後再償還債務的新創公司，做出了明智的取捨。一個有人十年沒有還清任何東西的銀行核心系統，則是完全不同的情況。

使技術債務特別昂貴的是複利效應。一個做太多事情的類別會使下一個功能稍微困難一些。那個下一個功能，在同樣的時間壓力下構建，會使再下一個更加困難。對成熟產品程式碼庫的研究一致表明，負債累累的系統交付速度降低20-40%，同時伴隨著更高的缺陷率和更長的新工程師入職時間。

Fowler的四象限

Martin Fowler將Cunningham的比喻擴展為一個二乘二的模型。座標軸分別是魯莽與審慎（你知道更好的做法嗎？）以及故意與無意（你知道自己在這樣做嗎？）。

魯莽且故意：「我們沒有時間做設計。」團隊知道取捨，卻在沒有應對計畫的情況下做出選擇。這是最有害的象限，因為利息累積最快，且沒有償還的意圖。在英國場景中，設想一個零售團隊，因為發布修復比做到位更重要，就將黑色星期五定價規則直接硬編碼到結帳流程中。

魯莽且無意：「什麼是分層？」團隊在不知情的情況下累積債務，通常是因為經驗不足。初級開發人員在各服務間複製貼上邏輯，或者一個團隊從未見過神類，沒有意識到他們正在創建一個。這在規模擴張較快、但沒有足夠早引進高級工程師的小型英國新創公司中很常見。

審慎且故意：「我們以後會重構。」團隊理解取捨，做出有意識的決定，並打算償還。當意圖是真實的時候，這是健康的。臨時新增一個功能旗標來解耦發布和後端遷移，就是審慎且故意的。當「我們會在上線後修復它」成為一個反覆出現的笑話時，它就滑向了魯莽。

審慎且無意：「現在我們知道應該怎麼做了。」團隊事後發現了更好的方法。這實際上是一個學習型團隊的標誌。你構建了REST API，然後意識到事件溯源才是正確的模型。債務是真實的，但它來自於對理解的真正成長，而不是疏忽。

了解你的債務所在的象限，可以告訴你如何應對。無意的債務通常需要教育和工具。故意的債務需要償還計畫和利益相關者的可見性。魯莽的債務需要在任何程式碼更改之前進行根本原因分析對話。

實踐中的技術債務類型

技術債務在真實程式碼庫中以多個維度出現。

架構債務是最深層的類型。系統層面的錯誤模式：需要拆分的單體應用、無法擴展的資料模型、在錯誤位置劃定的服務邊界。架構債務修復成本高昂，放任不管則風險極高。

程式碼債務是大多數開發人員首先想到的：複製貼上的邏輯、沒人敢刪除的死程式碼、做了十二件事的神類、不再與方法實際功能匹配的方法名稱。這是最明顯的類別，也是最容易逐步解決的。

測試債務被低估了。測試覆蓋率低的程式碼庫不僅脆弱：它是一種債務，因為每次重構都會變得更加昂貴，因為你無法驗證沒有破壞任何東西。與實作細節而非行為耦合的脆弱測試是同一問題的更微妙形式。

相依性債務帶有直接的安全成本。兩三年未更新的套件通常帶有已知的CVE。在英國金融服務和醫療保健領域，修補的監管要求很嚴格，過時的相依性既是合規風險，也是技術風險。

文件債務是讓一切都變得更糟的債務。當一位高級工程師離開並帶走他們對某個子系統的理解，而沒有任何文字記錄時，團隊其餘成員在每個涉及該區域的工單上都會累積無形的債務。

基礎設施債務包括手動部署流程、只有一個人知道如何配置的環境以及缺乏基礎設施即程式碼。每個手動步驟都是人為錯誤引入缺陷的地方，每個知識孤島都是交付風險。

如何衡量技術債務

你無法管理無法衡量的東西，「感覺不太對」不是可以帶給產品經理的指標。

SonarQube和CodeClimate等靜態分析工具會產生定量分數：程式碼複雜度、重複率、程式碼異味、安全熱點。SonarQube甚至會以小時為單位估算「技術債務比率」。絕對數字不是重點，隨時間的趨勢才是。如果你的債務比率迭代接迭代地上升，那就是訊號。

測試覆蓋率指標為你提供了測試債務的替代指標。分支覆蓋率為10%的模組是比80%的模組風險更高的重構目標。按模組追蹤覆蓋率，而不僅僅是作為整體百分比，因為高平均值可能會隱藏完全沒有測試的關鍵路徑。

部署時間指標揭示了基礎設施債務。如果將更改從合併到生產需要四個小時，涉及兩個手動步驟和給運維工程師發送Slack訊息，那就是可衡量的摩擦，具有可衡量的成本。

程式碼庫區域的缺陷率趨勢特別有用。如果特定服務或模組產生了不成比例的生產事故，這是集中債務的強烈訊號。Sentry和Datadog等工具使這種分析變得簡單直接。

開發者痛苦調查未被充分利用。一個簡單的季度性問題，「在程式碼庫的這個區域進行更改有多困難，從1到5評分？」，會浮現出工具遺漏的定性訊號。工程師知道龍住在哪裡。直接詢問他們並隨著時間追蹤答案是有價值的資料。

償還債務的策略

沒有單一正確的方法。正確的策略取決於債務的集中程度、它對當前交付的阻礙程度以及業務可以承受多少風險。

童子軍規則是最可持續的基線：讓你觸碰的每個檔案都比找到時略好。重新命名一個令人困惑的變數。提取一個方法。刪除死程式碼。這個別個來說幾乎沒有成本，隨時間正向累積。不需要利益相關者的認可，幾乎沒有風險。

在功能開發環境下的重構是大多數團隊最安全、最實用的方法。當你向模組新增功能時，將你需要更改的模組部分的重構作為同一工作的一部分。這使重構與業務價值掛鉤，保持範圍可管理，並避免安排沒有可見輸出的工作的政治問題。

專項減債衝刺在債務集中於某一區域且積極阻礙交付時很有用，但需要利益相關者的明確認可。宣傳必須以商業語言進行：「這個區域每個功能多花一天時間，負責我們40%的生產事故。一個專注衝刺將使這兩個數字都減半。」模糊地訴諸清潔是行不通的。

Strangler Fig模式是針對過於糾纏而無法逐步重構的遺留系統債務的正確方法。你在舊系統旁邊構建新系統，將流量一點一點地路由到新系統，直到舊系統不處理任何東西，可以被刪除。這個名字來自一種無花果樹，它圍繞宿主樹生長，直到宿主消失。這就是英國金融服務和醫療保健中大多數成功的遺留系統現代化專案的運作方式，因為在那裡，大規模重寫根本不是一個選項。

功能旗標將發布與部署解耦，降低了償債變更的風險。你可以在旗標後面重構支付服務，針對部分流量在生產中測試它，並逐步推出，而不是一次全部推出。

獲得利益相關者的認可

工程團隊犯的最大錯誤是將技術債務定性為技術問題。利益相關者並不抽象地關心程式碼品質。他們關心交付速度、可靠性、成本和風險。

將債務轉化為這些術語。「我們的結帳服務沒有自動化測試，這意味著每次更改都需要額外一天的手動回歸測試。本季度路線圖上還有三個結帳功能。這是三天可避免的延遲，加上季度末高峰期出現生產事故的風險。」

展示趨勢，而不是快照。單個資料點不能說明問題。一張顯示過去六個月支付領域功能交付平均時間從三天增加到六天的圖表，講述了一個產品經理或CTO可以採取行動的故事。

重構與重寫的決定

這在承擔大量架構債務的團隊中會定期出現。正確的預設做法幾乎總是漸進式重構。重寫幾乎總是比估計的花費更長時間。估計通常基於重建你現在所知道的東西需要多長時間，這忽略了嵌入在現有系統中的所有邊緣情況和機構知識。風險很高，在重寫過程中你還在為現有債務支付利息，同時沒有交付任何新內容。

只有當現有系統真正無法維護、語言或框架不再受支援，或者程式碼庫如此糾纏以至於Strangler Fig模式找不到立足點時，重寫才是合理的。即便如此，也應該最小化範圍，里程碑應該保持短暫。

英國背景：2026年債務集中在哪裡

2026年英國技術債務最多的行業是金融服務、醫療保健和零售。銀行的遺留大型機系統、NHS托管機構和私人醫療保健中的單體患者記錄系統以及已有十年歷史的電子商務平台都在推動對現代化服務的需求。共同點是，這些系統是在巨大的時間壓力下構建的，通常是由已經離開的承包商構建的，多年來一直在打補丁而不是重構。

如果你在這些行業之一工作，Strangler Fig模式和基於證據的利益相關者溝通方法不僅僅是良好實踐。它們往往是唯一政治上可行的前進道路。

關鍵要點

• 技術債務是一個有意為之的比喻：現在的捷徑以後成本更高，利息會複利增長。不是所有債務都是壞的，但未管理的債務會扼殺交付速度。
• Fowler的象限模型幫助你診斷債務的來源，選擇正確的應對方式：教育、工具或正式的償還計畫。
• 債務的真實成本不僅僅是開發速度變慢。還有更高的缺陷率、更長的入職時間、過時相依性帶來的安全風險增加以及組織知識的流失。
• 通過靜態分析、測試覆蓋率、部署指標、缺陷率趨勢和開發者痛苦調查來衡量債務。追蹤趨勢，而不僅僅是快照。
• 最可持續的減債策略是與功能開發相結合的持續改進：童子軍規則加上情境化重構，Strangler Fig模式保留用於遺留系統重寫。
• 利益相關者的認可需要將技術債務轉化為商業語言：交付速度、可靠性、成本和安全風險。展示趨勢。

常見問題

技術債務最簡單的定義是什麼？ 技術債務是你通過現在選擇快速解決方案而非更好方案，為未來的自己創造的額外工作。就像金融債務一樣，它會累積利息：放置越久，對程式碼庫該部分的每次更改就越昂貴。

所有的技術債務都是壞的嗎？ 不。審慎且故意的債務，團隊做出有意識的取捨，打算以後修復，可能是正確的選擇。一個在驗證產品市場契合點之前發布MVP的新創公司不應該過度工程化。問題是永遠不償還的債務，或者在沒有意識的情況下魯莽創造的債務。

英國團隊通常如何衡量技術債務？ 最常見的方法是SonarQube和CodeClimate等靜態分析工具、測試覆蓋率報告、部署時間追蹤、按程式碼庫區域的生產缺陷率分析，以及定期的開發者調查，詢問在系統特定部分工作有多痛苦。

Strangler Fig模式是什麼，什麼時候應該使用它？ Strangler Fig模式涉及在現有系統旁邊構建新系統，並逐步將流量路由到新系統，直到舊系統可以退役。它是大規模遺留系統現代化的首選方法，適用於現有系統過於糾纏而無法逐步重構，且完全重寫風險太高的情況。

如何說服非技術利益相關者優先考慮減少技術債務？ 用商業語言來闡述。計算當前缺陷率在交付天數上的成本、手動部署步驟損失的時間，或未修補相依性的安全風險。展示時間趨勢，而不是一次性的資料點。一張顯示六個月內功能交付時間翻倍的圖表，比任何程式碼品質解釋都更有說服力。

我們是否應該做完整的重寫而不是重構？ 很少。重寫幾乎總是比估計的花費更長時間，因為它們沒有考慮到嵌入在現有系統中的機構知識。預設應該是漸進式重構，理想情況下對大規模遷移使用Strangler Fig模式。只有當系統真正無法維護，或者其底層語言或框架不再受支援時，完整重寫才是合理的。