技術債務簡介
技術債務 是一個術語，用來描述選擇一個簡單的解決方案而非更好的實踐所引發的未來成本，因為更好的實踐會花費更多時間來完成。
選擇「技術債務」這個術語是因為它與金融債務的比較。 處於金融債務中的人們經常做出看似合適或當時唯一選擇的決定，但這樣做導致利息增加。
積累的利息越多，他們未來越困難，並且以後能選擇的選項越有限。 在累積金融債務時，利息會在利息上增加，形成雪球效應。 同樣地，技術債務可能累積到一個程度，即開發人員幾乎所有時間都花在處理問題和重做工作上，無論是計劃內的還是計劃外的，而不是增加價值。
那麼，它是如何發生的？
最常見的藉口是緊要期限。 當開發人員被迫快速建立程式碼時，他們通常會採用快捷方式。 例如，與其重構方法來包含新功能，不如複製以建立新版本。 然後，我只會測試我的新程序代碼，而且如果我變更原始方法，可以避免所需的測試層級，因為程式代碼的其他部分會使用它。
現在我有兩份相同的程式碼要在未來修改，而不是只有一份，這樣我就有可能面臨邏輯分歧的風險。 有許多原因。 例如，開發人員之間可能缺乏技術技能和成熟度，或沒有明確的產品擁有權或方向。
組織可能根本沒有編碼標準。 因此，開發人員甚至不知道他們應該生產什麼。 開發人員可能沒有精確的目標需求。 嗯，它們可能受限於最後一分鐘的需求變更。
必要的重構工作可能會延遲。 可能沒有任何程式代碼質量測試、手動或自動化。 最後，要在合理的時間範圍和合理的成本下將價值傳遞給客戶變得越來越困難。
技術債務是專案未能達到期限的主要原因之一。
隨著時間的推移，它的增加方式類似於貨幣債務。 技術債務的常見來源如下：
- 缺乏編碼樣式和標準。
- 單元測試案例缺乏或設計不佳。
- 忽略或不瞭解對象導向設計原則。
- 單一類別和程式庫。
- 缺乏遠見地構想技術、架構與方法的運用。 （遺漏考慮所有影響維護、用戶體驗、可擴展性等系統屬性）。
- 過度工程程序代碼（新增或建立不需要的程式代碼、在現有連結庫足夠時新增自定義程式代碼，或建立不需要的圖層或元件）。
- 註解和文件不足。
- 不撰寫自我記錄程式代碼（包括描述性或表示意圖的類別、方法和變數名稱）。
- 使用捷徑來達到截止日期。
- 將死程式代碼保留在原處。
注意
隨著時間的推移，技術債務必須償還。 否則，小組修正問題並實作新功能和增強功能的能力需要更長的時間，最終會變得成本過高。
我們看到，技術債務在開發期間增加了一系列問題，並使得增加額外的客戶價值更加困難。
在專案中有技術債務會削弱生產力、挫敗開發小組、讓程式代碼難以理解和脆弱、增加進行變更的時間，並驗證這些變更。 非計劃性工作經常會妨礙計劃的工作。
從長遠來看，它也削弱了組織的實力。 技術債務往往在組織中逐漸累積。 它開始很小，並隨著時間成長。 每當我們採取快速權宜之計或規避測試來匆忙完成變更，問題就會逐漸惡化。 支援成本會越來越高，而且總是發生嚴重的問題。
最後，組織無法以及時且符合成本效益的方式回應其客戶需求。
用於監視的自動化測量
將技術債務持續收購降到最低的關鍵方法是使用自動化測試和評估。
在後續的示範中，我們將探討用來評估債務的其中一個常見工具：SonarCloud。 （原始的內部部署版本是 SonarQube）。
還有其他工具可供使用，我們將討論其中一些工具。
稍後，在下一個實作實驗室中，您將瞭解如何設定 Azure Pipelines 以使用 SonarCloud、瞭解分析結果，最後如何設定品質設定檔以管理 SonarCloud 在分析專案時所使用的規則集。
如需詳細資訊，請參閱 SonarCloud。
若要檢閱：
Azure DevOps 可以與各種不同的現有工具整合，以在建置期間用來檢查程式代碼品質。
您目前使用哪些程式代碼品質工具（如果有的話）？
您對這些工具喜歡哪些、不喜歡哪些？