如何評估、管理和避免技術債務

如果技術債務聽起來像是從金融手冊中摘錄的，那是因為該術語與金融有關。 然而，從真正意義上來說，技術債務與編程有關。 它的想法是，在軟件項目的開發過程中，某些必要的步驟被跳過，或者只是為了趕上最後期限而完全放棄。

為了開發完美的應用程序或軟件，開發人員通常時間緊迫——就像任何隨機執行任意任務的人一樣。 因此，在交付具有完美代碼的完美產品和最大化時間之間進行某種權衡通常是有意義的。

那麼問題是：這些權衡是否有限制？ 這種權衡是否會導致固有的危害？ 最後，從長遠來看，開發商真的會更好嗎？ 在這篇關於技術債務的文章中，我將嘗試回答所有這些問題。

什麼是技術債？

在定義技術債務時，我們必須首先提及創造該術語的人：Ward Cunningham。 根據 Cunningham 的說法，技術債務是指在編寫代碼時必須進行的額外開發工作，以彌補在短時間內編寫代碼所產生的赤字。

為了使它更形象化，想像一下你的任務是清理一個凌亂的房間，而你上課要遲到了。 為了確保您執行指令並準時上課，您會進行快速清潔，將沙發底下的大部分雜物清掃乾淨。 這樣做的後果是您最終將不得不花時間整理混亂。 對於軟件開發，當您跳過必要的步驟並遵循更簡單的路線時，使用“不那麼乾淨”的代碼，將來清理代碼會變得更加困難。 軟件項目多米諾骨牌中會遇到多個階段，您忽略現有問題的時間越長，解決問題所需的時間就越長。

技術債務的類型

技術債務有不同的類型，包括：

計劃的技術債務

這發生在組織故意決定承擔技術債務的情況下。 如前所述，這通常是為了超越規定的最後期限並達到特定目標。 在參與計劃中的技術債務時，組織需要清楚他們願意放棄什麼，以及他們不能放棄什麼。 你必須保持準確的記錄，記住你最終必須返回並糾正你一開始跳過的錯誤。

無意的技術債務

這種類型的技術債務與第一種直接相反。 當組織沒有預見或計劃技術債務時，就會出現這種情況。 造成這種情況的原因通常是組織中各個單位之間的溝通中斷，或者單位之間糟糕的工作實踐。

不可避免的技術債務

這是組織方面任何行動都無法阻止的技術債務。 例如，隨著技術的快速變化，過去編寫的一些代碼將達不到當前預計的標準是有道理的。

此外，當在編寫代碼時請求更改時，可能會出現這種技術債務。 如果在設計軟件的中途引入了某些更改，它可能會擾亂動態，使舊代碼過時或不必要。

技術債務的原因

上面已經討論了技術債務的一些原因，但我只是將它們一個接一個地挑選出來以使它們更清楚。

急速

技術債務最常見的原因是倉促。 開發人員通常有嚴格的截止日期，其中一些包括啟動某些軟件的截止日期。 在這種情況下，開發人員可能會在此過程中產生技術債務，這通常是可以理解的（並且是預期的）。 這種類型的技術債務通常是故意的，可能會導致代碼中出現錯誤或出現意大利麵條式代碼等問題。

疏忽/錯誤

有時，程序員只是編寫糟糕的代碼，最終導致技術債務。 不管壞代碼是否由於編碼人員的錯誤而存在，事實是錯誤會導致技術債務，並且由於它們不可擴展，因此最終必須修復。

缺乏對影響的認識

有時技術債務的出現是因為編碼人員沒有意識到或承認從長遠來看技術債務是多麼有害。 這可能源於對編程過程中走捷徑的有害影響的合理無知，也可能是故意無視後果。

意圖

編碼人員或組織的故意行為可能會故意產生技術債務。

缺乏模塊化

這主要是因為一個代碼可以同時服務於不同的業務邏輯。 這種情況使處​​理軟件變得更加困難。 對於開發人員編寫的每個代碼，他們遇到模塊化挑戰的機會就越大。

技術債務評估

永遠不應該手動計算技術債務，因為那將是相當艱鉅的。 這意味著必須手動輸入代碼來確定當前問題和未來可能出現的問題。 除了手動過程浪費時間之外，代碼有可能在手動過程結束時改變形式。

執行評估的一種方法是使用一些支持它的工具執行靜態分析。 一些可以使用的工具包括 Coverity、SonarQube、Check Style 和 Closure Compiler。

一般來說，有兩種計算技術債務的方法。 在第一種方法中，可以通過計算代碼比率之後的技術債務比率來獲得。 在這裡，開發應用程序所需的初始估計或總時間將用於確定修復技術債務所需的時間。

在第二種方法中，您可以直接使用 SonarQube 等各種工具給出的估計值。 這將與技術債務清單及其參考代碼相結合。 通過這些工具，您可以準確估計修復它所需的時間長度。

評估技術債務將使您了解修復技術債務需要多少天。 債務越多，解決它的時間就越長。

解決技術債務

如果發生了技術債務而您不知所措怎麼辦？ 您可以採取某些步驟來管理技術債務。

首先，您應該承認存在技術債務並將其傳達給您的團隊。 在溝通中，你應該清楚發生了什麼以及需要做什麼來糾正它。 您應該確保儘早清楚地傳達處理技術債務的必要性。

在通知您的團隊技術債務後，您可以採取三種方法。 在第一種方法中，您可以決定繼續使用系統。 在這種情況下，應用程序將按原樣使用。

或者，您可以決定重構應用程序。 重構的目的是降低應用程序的複雜性以及清理應用程序的結構。 通過重構，軟件的行為不會改變； 唯一受影響的部分是內部結構。

最後，如果上面討論的兩個選項都不起作用，您將不得不完全替換代碼。 這樣做的一個問題是它可能導致新的技術債務，但從長遠來看，這可能是一個更好的權衡。

避免未來的技術債務

當然，避免技術債務絕對比在它們出現時嘗試修復它們更明智，這是不言而喻的。 除了可以節省您的時間和壓力之外，它還可以確保不存在從一開始就存在技術債務的殘餘後果。

可以說，技術債務本身並不壞。 它們通常是有問題的，因為它們是必須償還的債務，而人類不是地球上最負責任的物種。 始終選擇較弱的選項通常會削弱軟件的強度，並使以後改進功能變得更加困難。 總之，避免技術債務是任何人的最佳選擇。

那麼，如何防止出現技術債務：

創建項目待辦事項

這裡的想法是讓每個人都了解這個過程，並讓他們跟上正在執行的任何任務的要求。 創建積壓工作讓每個人都可以看到未完成的任務，以及實現這些任務的路徑。

質量優先於速度

如果你自己是一名程序員，你必須學會優先考慮高質量的工作而不是大量的工作。 確保您的代碼是乾淨的，並且您的應用程序或其他軟件開發得完美無缺。 要明白，走捷徑的誘惑是不值得的，因為最終，你仍然必須完成你放棄的任務。

如果你領導一個團隊，你必須將這些相同的價值觀傳達給團隊成員。 應該教導成員創建以結果為導向的解決方案並避免走捷徑。

創建意識

一般來說，深入了解什麼是技術債務以及如何避免技術債務可能有助於從一開始就防止它們出現。 當您用必要的知識武裝您的開發人員時，他們將更好地避免技術債務帶來的陷阱。

介紹良好的編碼實踐

一些編碼實踐使您更有可能陷入技術債務。 因此，避免緊耦合、採用抽象和重構會很好。

引進最新技術

定期更新技術可能是防止技術債務的絕佳手段。 在更新中，你必須確保使用的是最新的框架、數據庫和應用軟件。

結論

在絕大多數情況下，只要您繼續開發程序和編寫代碼，技術債務是不可避免的。 但是，如果按照上面列出的步驟進行操作，它們發生的機會就會大大降低。 此外，即使出現技術債務，也不會失去所有希望。 保持冷靜，自信，採取相應的行動。