發現并修復五種架構技術債務
開發人員、架構師和應用程序團隊不斷追逐技術債務。不管是好是壞，這是一個令人煩惱的問題，經常被踢到路上，直到為時已晚，應用程序開發放緩，新功能延期，測試周期增加，成本上升。在最公開的情況下，應用程序會完全崩潰——就像我們最近在西南航空公司、Twitter、FAA 和其他從未公開過的網站上看到的那樣——但你知道你是誰。技術債務從源代碼的味道中呈現出多種形式從安全風險到更嚴重的架構技術債務問題。存在用于掃描源代碼質量和安全性的優秀工具，但由于缺乏可觀察性、工具和最佳實踐，跟蹤、基線化和檢測架構漂移一直很困難。
架構技術債務到底是什么，我為什么要關心？如果您是負責維護和擴展舊的 Java 或 .NET 單體的架構師或開發人員，您可能已經非常熟悉這個問題。單體應用程序實際上是由其架構（單體）模式定義的，它帶有密集的依賴關系、長依賴鏈，本質上是一個大泥球，對于任何試圖理解和跟蹤的架構師來說都是不透明的。這就是架構技術債務的本質：類糾纏、深度依賴、死代碼、長依賴鏈、密集拓撲以及缺乏通用代碼庫，它們困擾著單體、舊應用程序，甚至最近的微服務已經開始類似于巨石本身。
架構可觀察性
到目前為止，軟件架構師缺乏從他們的角度理解、跟蹤和管理技術債務的可觀察性和工具。架構債務不是源代碼質量或圈復雜度，盡管這些是需要跟蹤和管理的關鍵技術債務元素。問題的切入要深得多，因為這些結構性問題直接影響產品質量、功能交付提前期和測試時間。學術研究強調了分析依賴關系如何為返工、重構和應用程序現代化的復雜性提供主要預測指標。
架構可觀察性照亮了應用程序黑匣子和泥球應用程序，使不透明變得透明，因此架構師可以左移進入正在進行的軟件開發生命周期。這使他們能夠在結構異常爆發為更大的問題之前，以迭代、連續的方式管理、監控和修復結構異常。可觀察的架構從工具開始，首先建立基線、設置閾值并檢查架構漂移以主動檢測關鍵異常。
需要追蹤的五種關鍵建筑債務形式
克服架構債務是一項挑戰，但任何時候開始都不晚。在過去十年中，許多單體應用已經被提升并轉移到云端，這應該是您的首要目標。有五個關鍵因素需要分析、跟蹤和制定修復計劃。
- 死代碼：最難找到的死代碼是駐留在應用程序和公共庫中的可訪問遺留代碼，這些代碼已過時或不再被任何當前用戶流訪問。它通常被認為是“僵尸代碼”，因為它潛伏在陰影中，沒有開發人員真正愿意接觸它。找到它需要結合動態和靜態分析來確定代碼是否存在但從未在生產中訪問過。死代碼不同于“無法訪問的代碼”，因為代碼實際上在技術上是可以訪問的，但實際上不再使用。死代碼會隨著時間的推移而發展和傳播，使重構和現代化工作變得膨脹和復雜化。
- 服務蠕變：通過手動或自動方式設置基線服務拓撲。逐條列出應用程序中的核心業務服務和公共服務，最好是在整個團隊可以跟蹤的共享位置。定期審核應用程序結構以查看是否添加或刪除了新服務，以及是否出于適當的業務或技術原因。
- 公共類：準備重構或重新架構項目的關鍵方面之一是確定公共類，這些公共類應包含充當共享公共庫的核心平臺服務。這一關鍵的現代化最佳實踐將減少重復代碼和依賴性，將通用服務集中在一個地方。定期觀察應用程序以檢查應添加到公共庫中的新公共類，以防止進一步積累技術債務。
- 服務排他性：一旦您從整體中提取了一個或多個微服務，為這些服務的排他性設定基線并尋找架構漂移將及早標記未來的技術債務。測量和基線服務排他性以確定服務的獨立類和資源的百分比，以在引入擴展架構技術債務的新依賴項時發出警報。
- 高負債類別：某些類別比其他類別承擔更多的技術債務。根據依賴項、依賴項和大小分析和設置“高債務”類分數，以確定重構的最佳候選者，這將對減少技術債務產生最大影響。
使用自動化工具的主動架構監督將使架構師能夠通過設置觀察、分析和設置配置基線測量和閾值的時間表來應對這些類型的變化。
架構漂移管理
持續的現代化要求架構師不僅在應用程序的初始設計或需要重新架構或重構時，而且在其應用程序的整個生命周期中都扮演更積極的角色。架構漂移管理為架構師提供了他們所需的可觀察性和工具，以保持其架構的領先地位，隨著時間的推移實現現代化，并避免下一次技術債務災難。
