技術債務簡介
技術債務這個字詞是描述由於更佳的做法較為耗時，因此未選用，而先選擇簡單的解決方案，從而在日後產生的成本。
選擇使用技術性債務一詞是為了與財務債務進行比較。 具有財務債務的人通常會採用當下看似適當或別無選擇的決策，但這樣做會產生利息。
累積的利息越多，未來情況就會越發艱難，並且日後只能選擇更不佳的選項。 在財務債務影響下，利息會快速增加，進而產生雪球效果。 同樣地，當技術債務累積到一定程度時，可能會導致開發人員將絕大多數的時間耗費在歸結問題，以及進行計劃性或非計劃性的修改，而不是增加價值。
那麼這是如何發生的？
最常見的原因之一是交期緊迫。 當開發人員被迫要快速建立程式碼時，常會選擇走捷徑。 例如，不重構方法以納入新功能，而是將其複製以建立新的版本。 然後，我只會測試新的程式碼，而且如果我變更原始方法，由於程式碼的其他部分會使用，因此可以避免所需的測試層級。
現在我有兩份相同的程式碼複本，我未來需要同時修改兩者，而不是一個，因此產生了邏輯差異的風險。 原因並不止於此。 例如，開發人員可能缺乏技術技能和成熟度，或沒有清楚的產品擁有權或方向。
組織可能完全沒有程式碼撰寫標準。 因此，開發人員甚至不知道他們應該生產什麼。 開發人員可能沒有精確的目標需求。 此外，他們可能受限於時間緊迫的需求變更。
必要的重構工作可能會遭到延宕。 可能沒有任何手動或自動化的程式碼品質測試。 最終，技術債務將使您越來越難在合理時間範圍內，以合理的成本為客戶提供價值。
技術債務是專案無法在期限前完成的其中一個主要原因。
隨著時間拉長，這種債務會如同貨幣債務一般持續增加。 技術債務的常見來源如下：
- 缺乏程式碼撰寫的樣式和標準。
- 缺乏單元測試案例的設計或設計不佳。
- 忽略或未理解物件導向設計原則。
- 整合型類別和程式碼程式庫。
- 對技術、架構和方法的使用設想不佳。 (忘記需要考慮影響維護、使用者體驗、可擴縮性等的所有系統屬性)。
- 過度建構的程式碼 (新增或建立不需要的程式碼、在現有的程式庫足夠時新增自訂程式碼，或建立不需要的圖層或元件)。
- 註解和文件不足。
- 未撰寫自我記錄程式碼 (包括描述性或表示意圖的類別、方法和變數名稱)。
- 便宜行事以滿足期限。
- 保留無作用程式碼。
注意
經過一段時間後，必須償還技術債務。 否則，當小組要修正問題並實作新功能和增強功能時，將會花費更多時間，且最終成本會變得難以負荷。
我們發現技術債務會在開發期間帶來一系列問題，並使提升額外的客戶價值更加困難。
專案中的技術債務會降低生產力、使開發小組感到挫敗、讓程式碼難以理解和不穩定、增加變更及驗證這些變更所花費的時間。 計劃性工作經常會受到非計劃性工作妨礙。
長期而言，這也會使組織的力量減弱。 技術債務往往在組織中蔓延。 一開始較不起眼，並隨著時間增長。 每當需要迅速變更而進行快速處理或規避測試時，問題就會逐漸惡化。 支援成本會不斷攀升，而且一定會發生嚴重的問題。
最後，組織將無法用及時且符合成本效益的方式回應客戶需求。
監視的自動化測量
將技術債務的總量維持在最低的其中一個重要方法便是使用自動化測試和評量。
在後續示範中，我們將探討用來評估債務的其中一個常見工具：SonarCloud。 (原始的內部部署版本是 SonarQube)。
還有其他可用的工具，我們將討論其中一部分。
稍後，在下一個實際操作實驗室中，您將了解如何設定 Azure Pipelines 以使用 SonarCloud、理解分析結果，並在最後設定品質設定檔來控制 SonarCloud 在分析專案時所使用的規則集。
如需詳細資訊，請參閱 SonarCloud。
若要檢閱：
Azure DevOps 可以與各種不同的現有工具整合，以在建置期間用來檢查程式碼品質。
您目前使用哪些程式碼品質工具 (若有)？
您對這些工具滿意和不滿意的部分為何？