技術(shù)債務(wù) (TD) 是一個概念，描述了系統(tǒng)新功能或維護(hù)的成本和/或額外工作。把它想象成汽車中的摩擦。您選擇忽略它的時間越長，您以后修復(fù)它所需的費用就越多。它對開發(fā)團(tuán)隊以外的人來說大多是不可見的，但它以兩種方式表現(xiàn)出來：

• 進(jìn)化系統(tǒng)的難度和額外成本；

• 維護(hù)系統(tǒng)的難度和額外成本。

圖片

專家經(jīng)常將技術(shù)債務(wù)描述為錯誤或次優(yōu)技術(shù)決策的結(jié)果，這些決策后來導(dǎo)致系統(tǒng)維護(hù)和擴(kuò)展問題。
技術(shù)債務(wù)是不可避免的。Martin Fowler曾建議使用技術(shù)債務(wù)象限來解釋技術(shù)債務(wù)的性質(zhì)。他建議有四種類型的TD

故意和謹(jǐn)慎的技術(shù)債務(wù)是最無害的。當(dāng)您必須將 MVP 交付給用戶以獲得進(jìn)一步開發(fā)的資金并選擇稍后處理后果時，就會發(fā)生這種情況。在其他情況下，開發(fā)人員可能不知道一些最佳實踐，也不知道所選擇的方法不是最佳決策（無意和謹(jǐn)慎的技術(shù)債務(wù)）。當(dāng)您忽略解決方案的設(shè)計或規(guī)劃時，事情會變得相當(dāng)混亂，這會導(dǎo)致魯莽但故意的技術(shù)債務(wù)。最壞的情況是工程師不關(guān)心或不稱職，因此不遵守開發(fā)中的最佳標(biāo)準(zhǔn)（疏忽和魯莽）。但是是什么導(dǎo)致了這些決定？讓我們深入挖掘技術(shù)債務(wù)的原因。

什么導(dǎo)致技術(shù)債務(wù)？

現(xiàn)在我們已經(jīng)看到了技術(shù)債務(wù)的癥狀，讓我們更深入地研究這種現(xiàn)象的原因。

通常，我們看到的只是冰山一角。為了將后果與原因分開，我們需要解決導(dǎo)致技術(shù)債務(wù)的原因和情況。通常，技術(shù)債務(wù)有四個根本原因：

• 業(yè)務(wù)。通常，業(yè)務(wù)需求會阻礙軟件開發(fā)中的最佳實踐。團(tuán)隊被迫更快地或以更少的錢發(fā)布產(chǎn)品。有時需求會在中途發(fā)生變化。公司需要削減成本。

• 上下文的變化。通常情況下，對初始系統(tǒng)有意義的需求不再適合。您可能需要更改技術(shù)堆棧/工具，或者只是您使用的技術(shù)已經(jīng)過時。

• 開發(fā)過程。當(dāng)最初的概念沒有得到適當(dāng)?shù)挠涗洉r，也會發(fā)生技術(shù)債務(wù)。人們對應(yīng)該做什么以及為什么這樣做感到困惑。如果在此等式中添加不足的資源和缺乏測試自動化，就會出現(xiàn)技術(shù)債務(wù)。

• 團(tuán)隊/人。這是技術(shù)債務(wù)最復(fù)雜的原因。這不是責(zé)備人或指責(zé)，而是了解在人力資源方面可以做得更好。如果缺乏有經(jīng)驗的開發(fā)人員，分布式團(tuán)隊之間的溝通效率低下，或者資源從一個項目轉(zhuǎn)移到另一個項目——你肯定會遇到技術(shù)債務(wù)的麻煩。

那么公司如何減少現(xiàn)有的技術(shù)債務(wù)呢？不幸的是，沒有減少技術(shù)債務(wù)的通用方法。一切都取決于你的環(huán)境，系統(tǒng)有多大，它有多老，你依賴什么商業(yè)模式，誰做決定等等。

對擁有 5 名工程師的小型初創(chuàng)公司有效的東西，很可能不適用于支持企業(yè)級的遺留系統(tǒng)的 100 多人的團(tuán)隊。但是，有一些一般性建議可以幫助您減少技術(shù)債務(wù)或減少獲取技術(shù)債務(wù)的頻率。

減少技術(shù)債務(wù)的最佳實踐

根據(jù)您的情況，您可能需要跳過一個步驟或一個額外的步驟，但所有公司通常都從同一個地方開始。

1. 承認(rèn)技術(shù)債務(wù)

經(jīng)常發(fā)生的是，公司在沒有意識到甚至從中受益的情況下獲得了技術(shù)債務(wù)。然而，當(dāng)技術(shù)債務(wù)不再是一個好處而是一個會導(dǎo)致很多麻煩的痛苦問題時，就會出現(xiàn)一個轉(zhuǎn)折點。你越早承認(rèn)它，你就越容易減少技術(shù)債務(wù)。

圖片

2. 了解您的技術(shù)采用階段并確定解決技術(shù)債務(wù)的最佳方法

根據(jù)技術(shù)債務(wù)的數(shù)量，您可能需要進(jìn)入技術(shù)采用階段。最有可能的是，它將定義償還技術(shù)債務(wù)的方法。

圖片

Ozkaya 提出了管理技術(shù)債務(wù)的三種策略：

• 沒做什么。有時，如果技術(shù)債務(wù)允許您實現(xiàn)業(yè)務(wù)目標(biāo)，那么它并不是一件壞事。但是，重要的是要了解不處理此問題的后果。

• 更換整個系統(tǒng)。有時遺留系統(tǒng)過于復(fù)雜，您無法通過添加補(bǔ)丁或僅解決特定問題來修復(fù)它們。這是一個漫長而昂貴的過程，但有時它是唯一明智的出路。

• 增量重構(gòu)（投資承諾）。這種方法允許您通過關(guān)注每個沖刺來減少技術(shù)債務(wù)。它可能很貴，但從長遠(yuǎn)來看肯定會得到回報。

3. 分類和記錄技術(shù)債務(wù)

第三步是了解您的債務(wù)類型并正確記錄。您需要說明問題的類型、補(bǔ)救方法、負(fù)責(zé)人，并說明不償還這筆債務(wù)的后果。

確保衡量您的團(tuán)隊何時以及如何因技術(shù)債務(wù)而放緩。它將幫助您識別業(yè)務(wù)影響并將抽象概念轉(zhuǎn)化為可衡量的任務(wù)。

4. 調(diào)整您的積壓工作并跟蹤技術(shù)債務(wù)

嘗試定期償還您的技術(shù)債務(wù)。技術(shù)領(lǐng)導(dǎo)者必須不斷與利益相關(guān)者合作，將技術(shù)債務(wù)審查納入待辦事項并在必要時安排維護(hù)沖刺。Wolpers 說，Scrum 團(tuán)隊?wèi)?yīng)該考慮將 15-20% 的資源分配給每個 sprint 周期的重構(gòu)代碼和修復(fù)錯誤。確保您將相關(guān)任務(wù)包含在您的待辦事項中，并防止它掉入裂縫并被遺忘。

技術(shù)債務(wù)在持續(xù)測量時得到最好的控制。像 SonarQube 這樣的工具允許用戶使用指標(biāo)和規(guī)則及時觀察技術(shù)債務(wù)。

麥肯錫 2020 年的研究表明，大多數(shù)公司將其技術(shù)預(yù)算的 20% 以下用于支付技術(shù)債務(wù)。

5. 堅持最佳實踐

發(fā)展通常是在“什么是正確的”和“什么是有效的”之間找到平衡。是的，我們都聽說過 GRASP 或 KISS 原則，以及好的代碼的特點。但是，對遺留應(yīng)用程序進(jìn)行現(xiàn)代化改造意味著您需要與現(xiàn)有方法保持一致。因此，您需要找到平衡點并采用最適合您的案例的最佳實踐

您還應(yīng)該調(diào)整“完成”的定義。每個團(tuán)隊成員都需要了解任務(wù)何時準(zhǔn)備就緒，并且它符合可接受和可管理的技術(shù)債務(wù)標(biāo)準(zhǔn)。

6. 教育非技術(shù)利益相關(guān)者

管理技術(shù)債務(wù)的關(guān)鍵方面之一是確保決策人員了解減少技術(shù)債務(wù)的重要性。你越解釋為什么會出現(xiàn)技術(shù)債務(wù)以及為什么必須償還它，就越容易讓他們站在你這邊。 現(xiàn)在我們已經(jīng)了解了原因，讓我們放大特定類型的技術(shù)債務(wù)。

4種主要類型的技術(shù)債務(wù)以及如何減少它們

早在 2014 年，一群學(xué)者就擔(dān)心現(xiàn)有的技術(shù)債務(wù)等級與債務(wù)的性質(zhì)無關(guān)。這些專家駁斥了戰(zhàn)略債務(wù)與非戰(zhàn)略債務(wù)的傳統(tǒng)劃分，并提出了不同的方法。他們的努力產(chǎn)生了一個分類，由軟件工程研究所發(fā)布為Towards an Ontology on Technical Debt。我們根據(jù)他們工作的反思建立了我們的清單，主要關(guān)注技術(shù)和代碼相關(guān)問題。

架構(gòu)技術(shù)債

這種類型的債務(wù)與整個系統(tǒng)的設(shè)計有關(guān)。它通常會影響關(guān)鍵的架構(gòu)要求，如性能指標(biāo)、健壯性等。為什么會發(fā)生這種情況？諸如對軟件架構(gòu)理解不足、軟件系統(tǒng)的復(fù)雜性、架構(gòu)侵蝕以及對軟件開發(fā)生命周期 (SDLC) 缺乏了解等因素都會造成架構(gòu)債務(wù)。

如何解決建筑債務(wù)？首先，您需要評估現(xiàn)有架構(gòu)。您甚至可以進(jìn)行外部審計，以便更好地了解情況。專家將分析系統(tǒng)的當(dāng)前狀態(tài)，定義轉(zhuǎn)換范圍，概述潛在的瓶頸和風(fēng)險，并找到解決它們的方法。

如果您正在處理遺留系統(tǒng)并且難以擴(kuò)展您的產(chǎn)品，您還可以從采用微服務(wù)中受益。

代碼債務(wù)

這種形式的債務(wù)是指在源代碼中發(fā)現(xiàn)的問題。一些最常見的屬性是所謂的“代碼異味”，即長方法、代碼重復(fù)和其他類似癥狀。當(dāng)缺乏代碼審查、標(biāo)準(zhǔn)化指南或 lint 時，它通常會出現(xiàn)。

重構(gòu)是解決代碼債務(wù)的主要方法。它可以幫助您在不改變應(yīng)用程序行為的情況下實現(xiàn)系統(tǒng)現(xiàn)代化。您還可以改進(jìn)代碼審查程序并在代碼審查期間和推送之前介紹 lint 的使用。

基礎(chǔ)設(shè)施債務(wù)

基礎(chǔ)設(shè)施債務(wù)主要與運營環(huán)境有關(guān)。它在基礎(chǔ)設(shè)施代碼中偽裝自己，導(dǎo)致許多問題，如缺乏可觀察性（也稱為監(jiān)控債務(wù)）、部署問題、CI/CD 管道中斷等。

DevOps來救援。DevOps 不僅可以幫助您降低運營成本，而且通過確保開發(fā)、測試和生產(chǎn)環(huán)境的一致性，DevOps 還可以最大限度地降低風(fēng)險。

測試債務(wù)

這種類型的技術(shù)債務(wù)包括一般測試債務(wù)、缺乏測試自動化和缺陷債務(wù)。它包括缺乏測試覆蓋率、測試和實際代碼之間的一致性差、測試用例設(shè)計不明確或不成熟等。

為了成功減少測試債務(wù)，至關(guān)重要的是 a) 增加測試覆蓋率，b) 測試正面和負(fù)面場景，c) 引入自動化測試，以及 d)盡快開始測試。

概括來講

無論您擁有遺留系統(tǒng)還是從頭開始構(gòu)建新系統(tǒng)，獲得技術(shù)債務(wù)都是不可避免的。這是每個公司都面臨的復(fù)雜問題。盡管它的性質(zhì)，重要的是承認(rèn)它的存在，記錄它并支付它。確保您對開發(fā)團(tuán)隊和利益相關(guān)者都誠實并直言不諱。