正確管理技術(shù)債務(wù)可以決定軟件項目的成功和失敗。另一方面，忽視或未能識別技術(shù)債務(wù)可能導致更高的開發(fā)成本和更低的商業(yè)回報。有這么多的利害關(guān)系，理解和處理技術(shù)債務(wù)應(yīng)該是軟件開發(fā)人員和高級決策者的優(yōu)先事項。
本文是技術(shù)債務(wù)的初學者指南。我們解釋了該術(shù)語的含義，它如何影響軟件開發(fā)項目，以及如何最好地衡量組織中不同類型的技術(shù)債務(wù)。我們還提供了一系列有效的實踐來幫助控制技術(shù)債務(wù)。
技術(shù)債務(wù)定義
技術(shù)債務(wù)（也稱為技術(shù)債務(wù)、代碼債務(wù)或簡稱TD）是在軟件開發(fā)過程中為了獲得短期成果而走捷徑的結(jié)果。開發(fā)人員推遲了某些工作以達到可交付成果或截止日期，但“陷入債務(wù)”，他們必須通過未來的返工來償還。
當開發(fā)人員依賴易于實施、次優(yōu)的編碼或設(shè)計解決方案來加速生產(chǎn)時，通常會出現(xiàn)技術(shù)債務(wù)。然后，團隊必須（在某個時候）返回該產(chǎn)品以添加更多功能或修改代碼。以下是公司在質(zhì)量和速度之間進行權(quán)衡的一些常見原因：
- 測試市場契合度的戰(zhàn)略決策。
- 時間表或預算限制。
- 糟糕的軟件設(shè)計選擇。
- 編碼技能不足。
- 有缺陷的商業(yè)決策。
技術(shù)債務(wù)的功能與任何其他類型的債務(wù)一樣：您在短期內(nèi)獲得便利，但以后必須支付利息和利息。快速修復和低于標準的解決方案加速了軟件開發(fā)，但在未來解決這些問題是昂貴的、受限的和耗時的。未解決的技術(shù)債務(wù)的一些常見癥狀是：
- 導致性能問題的產(chǎn)品錯誤。
- 更長的發(fā)布周期和上市時間。
- 代碼質(zhì)量問題。
- 降低團隊的敏捷性和生產(chǎn)力。
- 負面的用戶體驗。
- 更高的總擁有成本。
- 可利用的網(wǎng)絡(luò)安全漏洞。
- 擴展和采用新技術(shù)的困難。
敏捷宣言的作者 Ward Cunningham是第一個使用術(shù)語技術(shù)債務(wù)來描述累積技術(shù)問題的影響的人。他還使用術(shù)語“?cruft ”來描述敏捷團隊需要修復或“回饋”以消除技術(shù)債務(wù)的隱秘代碼問題。
技術(shù)債務(wù)的類型
雖然技術(shù)債務(wù)總是具有影響力，但不同類型的債務(wù)比其他債務(wù)風險更大。您產(chǎn)生的債務(wù)可能是故意的，也可能是無意的：
- 當公司有意識地延遲解決問題以實現(xiàn)既定目標（例如，向用戶發(fā)送 MVP 以籌集資金或獲得概念驗證）時，就會出現(xiàn)故意技術(shù)債務(wù)（也稱為主動債務(wù)）。
- 無意的技術(shù)債務(wù)（也稱為被動債務(wù)）是偶然或由于粗心造成的，例如選擇錯誤的平臺或編碼錯誤。
Martin Fowler 的技術(shù)債務(wù)象限通過定義兩種類型的故意債務(wù)和無意債務(wù)進一步細分了技術(shù)債務(wù)的類型：
| 魯莽 | 謹慎 | |
|---|---|---|
| 商榷 | 當團隊知道缺點但沒有立即計劃如何或何時解決問題時 | 當開發(fā)人員知道他們正在積累興趣但決定現(xiàn)在發(fā)布并稍后修復錯誤時 |
| 不經(jīng)意間 | 當開發(fā)人員盲目地實施解決方案而沒有意識到他們正在負債時 | 當團隊在發(fā)布后了解到實施錯誤時 |
我們還可以根據(jù)團隊“欠”什么來區(qū)分不同類型的技術(shù)債務(wù)，例如：
- 建筑債務(wù)。
- 建立債務(wù)。
- 代碼債務(wù)。
- 缺陷債務(wù)。
- 設(shè)計債務(wù)。
- 文件債務(wù)。
- 基礎(chǔ)設(shè)施債務(wù)。
- 處理債務(wù)。
- 需求債務(wù)。
- 服務(wù)債務(wù)。
- 測試債務(wù)。
技術(shù)債務(wù)總是不好的嗎？
技術(shù)債務(wù)本質(zhì)上并不壞。大多數(shù)開發(fā)團隊無法避免偶爾在速度、成本和質(zhì)量之間進行權(quán)衡。只有在以下情況下，技術(shù)債務(wù)才會成為一個問題：
- 不知道債務(wù)。
- 忽略被指控的債務(wù)。
就像穩(wěn)健的金融債務(wù)一樣，智能技術(shù)債務(wù)在某些情況下可以帶來巨大的好處。戰(zhàn)略性債務(wù)可以幫助：
- 盡早交付 MVP 解決方案。
- 確認概念驗證。
- 確定產(chǎn)品/市場契合度。
- 獲得快速反饋。
- 快速滿足客戶需求。
技術(shù)債務(wù)對項目的影響取決于團隊如何處理他們所欠的。如果公司： 技術(shù)債務(wù)可能是一種有價值的工具：
- 有意識地決定負債。
- 有資源和知識來償還債務(wù)。
技術(shù)債務(wù)也是不可避免的。軟件開發(fā)不斷發(fā)展的本質(zhì)意味著每個產(chǎn)品都需要隨著時間的推移進行維護和重建。
技術(shù)債務(wù)示例
以下是故意和意外技術(shù)債務(wù)的三個真實示例。
示例 1：審慎而深思熟慮的技術(shù)債務(wù)
- 技術(shù)債務(wù)：不靈活的框架。
- 欠債原因：管理層設(shè)定了一個較短的期限，以快速進入市場并獲得“先行者”優(yōu)勢。
- 債務(wù)描述：開發(fā)人員選擇了一個可以快速構(gòu)建但存在已知靈活性問題的框架。
- 債務(wù)回報：將應(yīng)用程序重構(gòu)為更靈活的框架。
在此示例中，團隊使用具有已知問題的框架來實現(xiàn)早期發(fā)布。一旦公司達到目標，開發(fā)人員就會回去重構(gòu)組件并消除代碼問題。
示例 2：魯莽和無意的技術(shù)債務(wù)
- 技術(shù)債務(wù)：低質(zhì)量的代碼。
- 欠債原因：缺乏編碼經(jīng)驗。
- 債務(wù)描述：開發(fā)人員的編碼技能很差，因此團隊在努力滿足緊迫的最后期限時編寫了低質(zhì)量的代碼。
- 債務(wù)回報：清理和重寫有問題的代碼。
在這種情況下，陷入技術(shù)債務(wù)不是計劃中的決定，而是技能低劣的結(jié)果。該團隊發(fā)布的產(chǎn)品存在錯誤，這些錯誤會增加云成本并增加客戶流失率。償還債務(wù)的唯一方法是聘請更有經(jīng)驗的開發(fā)人員重新編寫代碼。
示例 3：魯莽和蓄意的技術(shù)債務(wù)
- 技術(shù)債：錯誤的網(wǎng)站平臺。
- 欠債原因：開發(fā)人員更喜歡使用 WordPress。
- 債務(wù)描述：開發(fā)人員選擇在 WordPress 上建立一個高流量的電子商務(wù)網(wǎng)站，因為他們更喜歡使用該 CMS。
- 債務(wù)回報：將網(wǎng)站遷移到新平臺。
在此示例中，團隊使用 WordPress構(gòu)建電子商務(wù)網(wǎng)站。CMS 無法處理高流量，導致客戶放棄購物車并轉(zhuǎn)向競爭對手。唯一的解決方案是將網(wǎng)站遷移到更合適的平臺。
技術(shù)債務(wù)的原因
技術(shù)債務(wù)有四種根本原因：
- 業(yè)務(wù)原因：公司需求有時會阻礙最佳開發(fā)實踐。更快或更少錢發(fā)布產(chǎn)品的壓力是技術(shù)債務(wù)的常見原因。
- 上下文切換：有時，對初始設(shè)計有意義的計劃會隨著時間的推移而失去意義。技術(shù)堆棧發(fā)生變化，系統(tǒng)變得過時，因此團隊經(jīng)常采取捷徑來保持系統(tǒng)運行和（在某種程度上）最新。
- 開發(fā)原因：當您在編碼過程中引入不足的資源、糟糕的文檔和缺乏測試時，就會發(fā)生基于開發(fā)的原因。
- 基于人的原因：缺乏經(jīng)驗或動力、溝通不暢、團隊分散和資源轉(zhuǎn)移是技術(shù)債務(wù)的常見原因。
以下是一些技術(shù)債務(wù)原因的真實例子：
- 一個不合理的最后期限，迫使團隊快速發(fā)布。
- 使用更簡單、熟悉的平臺，而不是最佳平臺。
- 低質(zhì)量的軟件設(shè)計決策。
- 項目目標的前期定義不佳。
- 缺乏編碼技能。
- 缺乏產(chǎn)品所有權(quán)。
- 依靠快速而有風險的創(chuàng)可貼修復，而不是完全重構(gòu)。
- 測試不足（QA 和 QC）。
- 對軟件架構(gòu)的理解很差。
- 在不參考支持文檔的情況下編寫代碼。
- 緊急的、最后一刻的規(guī)格變更。
- 由不同開發(fā)人員進行的一系列產(chǎn)品改進。
- 在未來需要合并的多個分支上并行開發(fā)。
衡量技術(shù)債務(wù)
以下是有助于評估組織中技術(shù)債務(wù)水平的指標：
- 新錯誤與已關(guān)閉錯誤：如果開發(fā)人員在修復錯誤時創(chuàng)建注釋，您可以計算團隊消除技術(shù)債務(wù)的效率。如果新錯誤的數(shù)量超過已關(guān)閉的錯誤，您應(yīng)該進行一些更改。
- 代碼質(zhì)量：代碼質(zhì)量通過計算圈復雜度、類耦合、代碼行數(shù)和繼承深度來量化代碼的整體狀態(tài)。更高的代碼質(zhì)量分數(shù)意味著產(chǎn)品中的技術(shù)債務(wù)更少。
- 周期時間：該指標衡量第一次提交和部署之間的時間。較短的周期時間表明技術(shù)債務(wù)較低。
- 代碼流失：該指標顯示團隊在發(fā)布后重寫或替換一行代碼的次數(shù)。任何代碼區(qū)域的長期高流失率表明迭代存在錯誤或快速修復。
- 代碼覆蓋率：該指標衡量運行測試套件時執(zhí)行了多少代碼。代碼覆蓋率通過評估未使用的行數(shù)來揭示代碼的效率。
- 技術(shù)債務(wù)比率 (TDR)：?TDR 有助于計算技術(shù)債務(wù)的總體未來成本。該指標是修復系統(tǒng)的成本（修復成本）與開發(fā)系統(tǒng)的成本（開發(fā)成本）的比率。
如何減少技術(shù)債務(wù)？
沒有一種萬能的方法來減少技術(shù)債務(wù)。一些適用于小型初創(chuàng)公司的策略并不總是適用于解決企業(yè)級系統(tǒng)問題的 100 多人團隊。然而，每家公司都應(yīng)該采取兩個總體方向來控制技術(shù)債務(wù)：
- 盡量減少新科技債務(wù)的產(chǎn)生。
- 盡可能高效、定期地償還現(xiàn)有債務(wù)。
讓我們看看您可以使用哪些不同的最佳實踐和策略來控制當前的技術(shù)債務(wù)并限制出現(xiàn)的新錯誤的數(shù)量。
追蹤并剔除“垃圾”
跟蹤和消除垃圾至關(guān)重要，因為技術(shù)債務(wù)可以在多個開發(fā)周期中幸存下來。處理工藝是一個五步過程：
- 技術(shù)債務(wù)清單：開始并維護公司的技術(shù)債務(wù)清單。跟蹤團隊知道代碼不干凈的所有實例以及需要未來返工的版本。
- 對雜項進行分類：根據(jù)技術(shù)債務(wù)的復雜性、修復成本和潛在影響將技術(shù)債務(wù)分組為可行的單元。
- 評估債務(wù)：注意忽略每個單位的后果。此描述性指標有助于確定任務(wù)優(yōu)先級。
- 使列表易于訪問：粗略的列表應(yīng)該對公司中的所有相關(guān)方（利益相關(guān)者、營銷、銷售、SecOps等）都是可見的。
- 盡早并經(jīng)常刪除垃圾：為開發(fā)人員安排定期（和頻繁）時間來償還技術(shù)債務(wù)并保持產(chǎn)品清潔。
這個過程應(yīng)該是連續(xù)的，并且是每個發(fā)布周期的一部分。理想情況下，雜亂無章的跟蹤和刪除應(yīng)該是您的開發(fā)或DevOps 團隊的 KPI 之一。
不要雇用低質(zhì)量的開發(fā)人員
即使在積極解決現(xiàn)有錯誤時，低質(zhì)量、廉價的開發(fā)人員也會產(chǎn)生更多的技術(shù)債務(wù)。當您考慮交付性能較低的產(chǎn)品所造成的收入損失時，低質(zhì)量的開發(fā)人員花費的成本比您為經(jīng)驗豐富的團隊支付的費用要高。
在招聘開發(fā)人員時，您應(yīng)該接受以下兩種心態(tài)：
- 價值超過價格。
- 質(zhì)量而不是數(shù)量。
較小、較好的團隊比較大、技能較低的部門運作得更好。雇傭兩名頂級開發(fā)人員通常比雇傭十名表現(xiàn)不佳的程序員更好。一旦你有兩個可靠的工程師來指示方向并監(jiān)督發(fā)布，你就可以開始引入初級員工進行內(nèi)部培訓。
編寫高質(zhì)量代碼
這種做法與上述做法有關(guān)；通過衡量以下指標來確保團隊編寫高質(zhì)量的代碼：
- 代碼復雜性（圈和認知）。
- 類耦合。
- 代碼行。
- 繼承的深度。
- 阿里蒂。
- 可維護性指數(shù)。
- Halstead 復雜性度量。
- 是時候?qū)?n 行了。
密切關(guān)注這些指標有助于推出低負債軟件產(chǎn)品。請記住根據(jù)高水平的工作而不是編寫代碼的數(shù)量來獎勵員工。還可以考慮創(chuàng)建編碼風格指南。通過記錄理想的編碼實踐，團隊會發(fā)現(xiàn)更容易編寫更簡潔的語法并花更多時間審查代碼。
使用自動化而不是手動測試
手動測試不是控制技術(shù)債務(wù)的長期選擇，這就是為什么您的團隊應(yīng)該轉(zhuǎn)而尋求建立和依賴自動化測試的原因。雖然建立和維護自動化測試需要時間和精力，但缺少手動測試將確保您更準確、更一致地發(fā)現(xiàn)問題。
保持透明的更改記錄
開發(fā)團隊應(yīng)持續(xù)記錄存儲庫中的所有更改。如果出現(xiàn)問題，開發(fā)人員可以輕松追蹤其來源并記錄債務(wù)。此記錄還有助于分布式團隊和需要仔細更改的高度復雜的項目（例如遷移到云或?qū)z留軟件進行現(xiàn)代化改造）。
創(chuàng)建技術(shù)債務(wù)團隊
并非每個開發(fā)人員或利益相關(guān)者都應(yīng)就技術(shù)債務(wù)做出決定。決策應(yīng)該來自了解項目并具有產(chǎn)品權(quán)衡經(jīng)驗的合格團隊成員。
考慮在您的公司內(nèi)建立一個專門的團隊來制定與技術(shù)債務(wù)相關(guān)的決策。這個團隊應(yīng)該：
- 對您的產(chǎn)品有深入的了解。
- 具有在質(zhì)量和速度之間進行戰(zhàn)略權(quán)衡的經(jīng)驗。
- 對團隊承擔債務(wù)的原因保持透明。
- 以非技術(shù)性的方式與高層管理人員溝通債務(wù)的目的。
- 概述最佳修復方法。
- 創(chuàng)建一個路線圖，說明團隊將償還債務(wù)的人員、時間和方式。
- 確保開發(fā)人員遵守計劃并在商定的時間表內(nèi)解決技術(shù)缺陷。
并非每個機會都值得為之舉債，因此專門的團隊還應(yīng)評估技術(shù)債務(wù)墻上的選擇權(quán)。
留出時間和資源來解決債務(wù)問題
優(yōu)先考慮良好的文檔和質(zhì)量代碼至關(guān)重要，但您還需要確保您的團隊有足夠的時間和資源來處理技術(shù)債務(wù)。調(diào)試產(chǎn)品和解決問題既耗費資源又耗費時間，因此如果開發(fā)人員面臨不斷交付新功能的壓力，他們將無法解決與債務(wù)相關(guān)的問題。專家建議，平均 Scrum 團隊應(yīng)該將15% 到 20% 的 sprint 周期用于重構(gòu)代碼和修復與債務(wù)相關(guān)的錯誤。
確保定期代碼重構(gòu)
你的團隊應(yīng)該定期進行代碼重構(gòu)，以確保持續(xù)償還技術(shù)債務(wù)。重構(gòu)是重組雜亂的代碼段以使其更多的過程：
- 可以理解。
- 可維護。
- 可靠的。
重寫軟件產(chǎn)品中的組件可以消除冗余并提高性能，這兩者對于償還技術(shù)債務(wù)至關(guān)重要。您還應(yīng)該考慮改進團隊的代碼審查程序并引入代碼檢查（自動檢查源代碼中的程序和樣式錯誤）。
調(diào)整貴公司對“完成”的定義
開發(fā)一個可重復的公式，指導開發(fā)人員如何進行實驗或向產(chǎn)品添加新功能。該程序應(yīng)包括可管理技術(shù)債務(wù)的標準，因此在軟件滿足設(shè)定要求之前，團隊不應(yīng)將任何產(chǎn)品視為“完成”。
在速度和質(zhì)量之間取得適當?shù)钠胶?/h2>
只要您的團隊明白他們必須“償還”他們的技術(shù)債務(wù)，采取戰(zhàn)略捷徑并偶爾以質(zhì)量換取速度，就可以為您帶來相當大的競爭優(yōu)勢。快速上市和快速概念驗證是當今市場的一切，因此明智地使用技術(shù)債務(wù)并確保團隊主動管理平衡以避免未來的障礙。
文章鏈接： http://www.qzkangyuan.com/5209.html
文章版權(quán)：夢飛科技所發(fā)布的內(nèi)容，部分為原創(chuàng)文章，轉(zhuǎn)載請注明來源，網(wǎng)絡(luò)轉(zhuǎn)載文章如有侵權(quán)請聯(lián)系我們！
