技術(shù)債務(wù) (TD) 是一個概念，描述了系統(tǒng)新功能或維護的成本和/或額外工作削葱。把它想象成汽車中的摩擦奖亚。您選擇忽略它的時間越長，您以后修復它所需的費用就越多析砸。它對開發(fā)團隊以外的人來說大多是不可見的昔字，但它以兩種方式表現(xiàn)出來：
進化系統(tǒng)的難度和額外成本；
維護系統(tǒng)的難度和額外成本首繁。
專家經(jīng)常將技術(shù)債務(wù)描述為錯誤或次優(yōu)技術(shù)決策的結(jié)果作郭，這些決策后來導致系統(tǒng)維護和擴展問題。
技術(shù)債務(wù)是不可避免的弦疮。Martin Fowler曾建議使用技術(shù)債務(wù)象限來解釋技術(shù)債務(wù)的性質(zhì)夹攒。他建議有四種類型的TD
故意和謹慎的技術(shù)債務(wù)是最無害的。當您必須將 MVP 交付給用戶以獲得進一步開發(fā)的資金并選擇稍后處理后果時挂捅，就會發(fā)生這種情況芹助。在其他情況下，開發(fā)人員可能不知道一些最佳實踐闲先，也不知道所選擇的方法不是最佳決策（無意和謹慎的技術(shù)債務(wù)）。當您忽略解決方案的設(shè)計或規(guī)劃時无蜂，事情會變得相當混亂伺糠，這會導致魯莽但故意的技術(shù)債務(wù)。最壞的情況是工程師不關(guān)心或不稱職斥季，因此不遵守開發(fā)中的最佳標準（疏忽和魯莽）训桶。但是是什么導致了這些決定累驮？讓我們深入挖掘技術(shù)債務(wù)的原因。
什么導致技術(shù)債務(wù)舵揭？
現(xiàn)在我們已經(jīng)看到了技術(shù)債務(wù)的癥狀谤专，讓我們更深入地研究這種現(xiàn)象的原因赡突。
通常怠噪，我們看到的只是冰山一角。為了將后果與原因分開沾乘，我們需要解決導致技術(shù)債務(wù)的原因和情況拦焚。通常蜡坊，技術(shù)債務(wù)有四個根本原因：
業(yè)務(wù)。通常赎败，業(yè)務(wù)需求會阻礙軟件開發(fā)中的最佳實踐秕衙。團隊被迫更快地或以更少的錢發(fā)布產(chǎn)品。有時需求會在中途發(fā)生變化僵刮。公司需要削減成本据忘。
上下文的變化。通常情況下搞糕，對初始系統(tǒng)有意義的需求不再適合若河。您可能需要更改技術(shù)堆棧/工具，或者只是您使用的技術(shù)已經(jīng)過時寞宫。
開發(fā)過程萧福。當最初的概念沒有得到適當?shù)挠涗洉r，也會發(fā)生技術(shù)債務(wù)辈赋。人們對應(yīng)該做什么以及為什么這樣做感到困惑鲫忍。如果在此等式中添加不足的資源和缺乏測試自動化，就會出現(xiàn)技術(shù)債務(wù)钥屈。
團隊/人悟民。這是技術(shù)債務(wù)最復雜的原因。這不是責備人或指責篷就，而是了解在人力資源方面可以做得更好射亏。如果缺乏有經(jīng)驗的開發(fā)人員，分布式團隊之間的溝通效率低下竭业，或者資源從一個項目轉(zhuǎn)移到另一個項目——你肯定會遇到技術(shù)債務(wù)的麻煩智润。
那么公司如何減少現(xiàn)有的技術(shù)債務(wù)呢？不幸的是未辆，沒有減少技術(shù)債務(wù)的通用方法窟绷。一切都取決于你的環(huán)境，系統(tǒng)有多大咐柜，它有多老兼蜈，你依賴什么商業(yè)模式攘残，誰做決定等等。
對擁有 5 名工程師的小型初創(chuàng)公司有效的東西为狸，很可能不適用于支持企業(yè)級的遺留系統(tǒng)的 100 多人的團隊歼郭。但是，有一些一般性建議可以幫助您減少技術(shù)債務(wù)或減少獲取技術(shù)債務(wù)的頻率辐棒。
減少技術(shù)債務(wù)的最佳實踐
根據(jù)您的情況病曾，您可能需要跳過一個步驟或一個額外的步驟，但所有公司通常都從同一個地方開始涉瘾。
-
承認技術(shù)債務(wù)
經(jīng)常發(fā)生的是知态，公司在沒有意識到甚至從中受益的情況下獲得了技術(shù)債務(wù)。然而立叛，當技術(shù)債務(wù)不再是一個好處而是一個會導致很多麻煩的痛苦問題時负敏，就會出現(xiàn)一個轉(zhuǎn)折點。你越早承認它秘蛇，你就越容易減少技術(shù)債務(wù)其做。
-
了解您的技術(shù)采用階段并確定解決技術(shù)債務(wù)的最佳方法
根據(jù)技術(shù)債務(wù)的數(shù)量，您可能需要進入技術(shù)采用階段赁还。最有可能的是妖泄，它將定義償還技術(shù)債務(wù)的方法。
Ozkaya 提出了管理技術(shù)債務(wù)的三種策略：
沒做什么艘策。有時蹈胡，如果技術(shù)債務(wù)允許您實現(xiàn)業(yè)務(wù)目標，那么它并不是一件壞事朋蔫。但是罚渐，重要的是要了解不處理此問題的后果。
更換整個系統(tǒng)驯妄。有時遺留系統(tǒng)過于復雜荷并，您無法通過添加補丁或僅解決特定問題來修復它們。這是一個漫長而昂貴的過程青扔，但有時它是唯一明智的出路源织。
增量重構(gòu)（投資承諾）。這種方法允許您通過關(guān)注每個沖刺來減少技術(shù)債務(wù)微猖。它可能很貴谈息，但從長遠來看肯定會得到回報。
-
分類和記錄技術(shù)債務(wù)
第三步是了解您的債務(wù)類型并正確記錄励两。您需要說明問題的類型黎茎、補救方法、負責人当悔，并說明不償還這筆債務(wù)的后果傅瞻。
確保衡量您的團隊何時以及如何因技術(shù)債務(wù)而放緩。它將幫助您識別業(yè)務(wù)影響并將抽象概念轉(zhuǎn)化為可衡量的任務(wù)盲憎。
-
調(diào)整您的積壓工作并跟蹤技術(shù)債務(wù)
嘗試定期償還您的技術(shù)債務(wù)嗅骄。技術(shù)領(lǐng)導者必須不斷與利益相關(guān)者合作，將技術(shù)債務(wù)審查納入待辦事項并在必要時安排維護沖刺饼疙。Wolpers 說溺森，Scrum 團隊應(yīng)該考慮將 15-20% 的資源分配給每個 sprint 周期的重構(gòu)代碼和修復錯誤。確保您將相關(guān)任務(wù)包含在您的待辦事項中窑眯，并防止它掉入裂縫并被遺忘屏积。
技術(shù)債務(wù)在持續(xù)測量時得到最好的控制。像 SonarQube 這樣的工具允許用戶使用指標和規(guī)則及時觀察技術(shù)債務(wù)磅甩。
麥肯錫 2020 年的研究表明炊林，大多數(shù)公司將其技術(shù)預(yù)算的 20% 以下用于支付技術(shù)債務(wù)。
-
堅持最佳實踐
發(fā)展通常是在“什么是正確的”和“什么是有效的”之間找到平衡卷要。是的渣聚，我們都聽說過 GRASP 或 KISS 原則，以及好的代碼的特點僧叉。但是奕枝，對遺留應(yīng)用程序進行現(xiàn)代化改造意味著您需要與現(xiàn)有方法保持一致。因此瓶堕，您需要找到平衡點并采用最適合您的案例的最佳實踐
您還應(yīng)該調(diào)整“完成”的定義隘道。每個團隊成員都需要了解任務(wù)何時準備就緒，并且它符合可接受和可管理的技術(shù)債務(wù)標準郎笆。
-
教育非技術(shù)利益相關(guān)者
管理技術(shù)債務(wù)的關(guān)鍵方面之一是確保決策人員了解減少技術(shù)債務(wù)的重要性谭梗。你越解釋為什么會出現(xiàn)技術(shù)債務(wù)以及為什么必須償還它，就越容易讓他們站在你這邊题画。 現(xiàn)在我們已經(jīng)了解了原因默辨，讓我們放大特定類型的技術(shù)債務(wù)。
4種主要類型的技術(shù)債務(wù)以及如何減少它們
早在 2014 年苍息，一群學者就擔心現(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)要求课梳，如性能指標距辆、健壯性等余佃。為什么會發(fā)生這種情況？諸如對軟件架構(gòu)理解不足跨算、軟件系統(tǒng)的復雜性爆土、架構(gòu)侵蝕以及對軟件開發(fā)生命周期 (SDLC) 缺乏了解等因素都會造成架構(gòu)債務(wù)。
如何解決建筑債務(wù)诸蚕？首先步势，您需要評估現(xiàn)有架構(gòu)。您甚至可以進行外部審計背犯，以便更好地了解情況坏瘩。專家將分析系統(tǒng)的當前狀態(tài)，定義轉(zhuǎn)換范圍漠魏，概述潛在的瓶頸和風險倔矾，并找到解決它們的方法。
如果您正在處理遺留系統(tǒng)并且難以擴展您的產(chǎn)品蛉幸，您還可以從采用微服務(wù)中受益破讨。
代碼債務(wù)
這種形式的債務(wù)是指在源代碼中發(fā)現(xiàn)的問題。一些最常見的屬性是所謂的“代碼異味”奕纫，即長方法提陶、代碼重復和其他類似癥狀。當缺乏代碼審查匹层、標準化指南或 lint 時隙笆，它通常會出現(xiàn)。
重構(gòu)是解決代碼債務(wù)的主要方法升筏。它可以幫助您在不改變應(yīng)用程序行為的情況下實現(xiàn)系統(tǒng)現(xiàn)代化撑柔。您還可以改進代碼審查程序并在代碼審查期間和推送之前介紹 lint 的使用。
基礎(chǔ)設(shè)施債務(wù)
基礎(chǔ)設(shè)施債務(wù)主要與運營環(huán)境有關(guān)您访。它在基礎(chǔ)設(shè)施代碼中偽裝自己铅忿，導致許多問題，如缺乏可觀察性（也稱為監(jiān)控債務(wù)）灵汪、部署問題檀训、CI/CD 管道中斷等。
DevOps來救援享言。DevOps 不僅可以幫助您降低運營成本峻凫，而且通過確保開發(fā)、測試和生產(chǎn)環(huán)境的一致性览露，DevOps 還可以最大限度地降低風險荧琼。
測試債務(wù)
這種類型的技術(shù)債務(wù)包括一般測試債務(wù)、缺乏測試自動化和缺陷債務(wù)。它包括缺乏測試覆蓋率命锄、測試和實際代碼之間的一致性差堰乔、測試用例設(shè)計不明確或不成熟等。
為了成功減少測試債務(wù)累舷，至關(guān)重要的是 a) 增加測試覆蓋率浩考，b) 測試正面和負面場景夹孔，c) 引入自動化測試被盈，以及 d)盡快開始測試。
概括來講
無論您擁有遺留系統(tǒng)還是從頭開始構(gòu)建新系統(tǒng)搭伤，獲得技術(shù)債務(wù)都是不可避免的只怎。這是每個公司都面臨的復雜問題。盡管它的性質(zhì)怜俐，重要的是承認它的存在身堡，記錄它并支付它。確保您對開發(fā)團隊和利益相關(guān)者都誠實并直言不諱拍鲤。
