技術債務簡介

技術債務 是一個術語，描述了未來可能產生的成本，該成本來自於今天選擇一個簡單的解決方案，而不是使用需要更長時間才能完成的更好實踐。

選擇「技術債務」一詞是因為它類似於金融債務。 負債累累的人通常會做出看似正確或當時唯一選擇的決定，但這樣做會增加利息。

興趣越多，他們未來的困難就越大，以後的選擇就越少。 對於金融債務，利息很快就會增加，從而產生滾雪球效應。 同樣，技術債務可能會累積到開發人員幾乎所有時間都花在修復問題和進行返工上的地步，無論是計劃的還是計劃外的，而不是增加價值。

那麼，它是如何發生的？

最常見的藉口是緊要期限。 當開發人員被迫快速建立程式碼時，他們通常會採用快捷方式。 例如，他們可能會複製方法以建立新版本，而不是重構方法以包含新功能。 然後他們只測試新程式碼，如果他們更改原始方法，則可以避免所需的測試級別，因為程式碼的其他部分使用它。

現在他們有兩個相同程式碼的副本，將來需要修改，而不是一個，並且他們冒著邏輯變得不同的風險。 有許多原因。 例如，開發人員之間可能缺乏技術技能和成熟度，或沒有明確的產品擁有權或方向。

該組織可能根本沒有編碼標準，因此開發人員甚至不知道他們應該生產什麼。 開發人員可能沒有明確的目標需求，或者他們可能會受到最後一刻需求變更的影響。

必要的重構工作可能會延遲。 可能沒有任何程式代碼質量測試、手動或自動化。 最後，要在合理的時間範圍和合理的成本下將價值傳遞給客戶變得越來越困難。

技術債務是專案未能達到期限的主要原因之一。

隨著時間的推移，它的增加方式類似於貨幣債務。 技術債務的常見來源如下：

• 缺乏編碼風格和標準
• 單元測試用例缺乏或設計不佳
• 忽略或不理解物件導向設計原則
• 整合型類別和程式碼程式庫
• 技術、架構和方法的規劃不周（忘記了需要考慮所有系統屬性，影響維護、使用者體驗、可擴展性等）
• 過度工程程式碼 （新增或建立不需要的程式碼、在現有程式庫足夠時新增自訂程式碼，或建立不需要的圖層或元件）
• 註解和文件不足
• 不編寫自我文檔代碼（包括描述性或指示意圖的類、方法和變量名稱）
• 走捷徑以達到最後期限
• 保留無作用程式碼

我們已經看到，技術債務在開發過程中會增加問題，並使增加額外的客戶價值變得更加困難。

專案中存在技術債務會降低生產力，讓開發團隊感到沮喪，使程式碼難以理解且脆弱，並增加進行變更和驗證這些變更的時間。 非計劃性工作經常會妨礙計劃的工作。

從長遠來看，這也削弱了組織的力量。 技術債務往往在組織中逐漸累積。 它開始很小，並隨著時間成長。 每次進行快速黑客攻擊或因為需要匆忙進行更改而跳過測試時，問題就會變得越來越嚴重。 支持成本越來越高，最終出現了一個嚴重的問題。

最後，組織無法以及時且符合成本效益的方式回應其客戶需求。

用於監視的自動化測量

最大限度地減少技術債務不斷累積的關鍵方法是使用自動化測試和評估。

在後續的示範中，我們將探討用來評估債務的其中一個常見工具：SonarCloud。 （原始的內部部署版本是 SonarQube）。

還有其他工具可供使用，我們將討論其中一些工具。

稍後，在下一個實作實驗室中，您將瞭解如何設定 Azure Pipelines 以使用 SonarCloud、瞭解分析結果，最後如何設定品質設定檔以管理 SonarCloud 在分析專案時所使用的規則集。

如需詳細資訊，請參閱 SonarCloud。

若要檢閱：

Azure DevOps 可以與各種現有工具整合，用來在組建期間檢查程式代碼品質。

您目前使用哪些程式碼品質工具（如果有）？

您對這些工具喜歡哪些、不喜歡哪些？