技術債務，到底應該怎麼還？

幾乎全部的技術團隊，都會經歷或多或少的技術債務。技術債務雖然是實現快速收益的一種捷徑，可是爲了修復那些爲了快速收益而不得不爲之的技術問題，企業每每須要花費大量的金錢、人力等。那麼如何有效地避免技術債務，使得開發人員能把更多的精力投入在有效的工做，從而產生額外價值、提升企業的產品競爭力呢？

技術債務的產生有着不少緣由，但其中更多的是因爲要在短期內匆忙完成本來耗時較長的工做，致使部分業務邏輯沒有完整的設計等，使得產品在短期內有效，可是長遠來看，倒是一顆不穩定的炸彈，一旦觸發，對產品、對企業都有可能形成沒法挽回的損失。總而言之，技術債務會帶來不少麻煩，有些甚至是「致命」的。

什麼是技術債務？

技術負債（英語：Technical debt），又譯技術債，也稱爲設計負債（design debt）、代碼負債（code debt），是編程及軟件工程中的一個比喻。指開發人員爲了加速軟件開發，在應該採用最佳方案時進行了妥協，改用了短時間內能加速軟件開發的方案，從而在將來給本身帶來的額外開發負擔。這種技術上的選擇，就像一筆債務同樣，雖然眼前看起來能夠獲得好處，但必須在將來償還。軟件工程師必須付出額外的時間和精力持續修復因爲以前的妥協所形成的問題及反作用，或是進行重構，把架構改善爲最佳實現方式。 ——摘自 維基百科

不少人將技術債務類比於金融債務，可是和金融債務不一樣的是，技術債務可能不會承擔利息。例如當須要快速驗證產品的某個特色的時候，帶有必定技術債務的產品多是個好的選擇；當驗證以後，無需該特色的時候，便可以直接移除等，此時可能不會承擔債務利息。可是大多數時候，此類狀況較少，就算僅僅是爲了驗證產品，也不建議使用技術債務的方式去實施。相似這樣的技術債務可稱爲有意的技術債務，另外一種更加危險的技術債務稱爲無心的技術債務，無心的技術債務就像是前文說到的隱藏在代碼中的炸彈。

不管是那種技術債務，在將來的產品迭代過程當中，都須要開發人員去界定債務邊界，不能任由技術債務滋生，不然在迭代過程當中，面臨的困難會愈來愈多，甚至須要被迫承擔更多的技術債務。基本上，你承擔的債務越多，項目的進度就越慢，項目的後續階段就會更加困難。

可是須要清楚的是，技術債務是沒法消除的，你必須隨時作好承擔技術債務的準備。由於在有的項目場景中，一些解決方案能夠針對性解決某些具體問題，可是該方案可能不是全局有效或最佳的，因而在系統的其餘方面就造成了一個不可避免而必須承擔的技術債務問題。一個好的工程師團隊，應該是可以最小化技術債務影響，並對技術債務進行合理管理的團隊。

上文提到，技術債務分爲有意的技術債務和無心的技術債務，兩種形式的技術債務造成的緣由和帶來的結果是不一樣的。在某些狀況下，有意的技術債務相比無心的技術債務更好，有意的技術債務會讓團隊意識到問題，從而有意的去進行優化改進等；而無心的技術債務可能在項目中潛伏很長一段時間，可能致使嚴重的問題，然而，無心的技術債務在項目中是沒法避免的，只能經過在工程師團隊中強化編碼規範、業務理解等來對技術債務進行管理或者減弱其出現的可能。

另外還能夠將技術債務分類爲魯莽型技術債務和謹慎型技術債務。一些謹慎型的技術債務在項目進程中是可取的，可是不管是哪一種技術債務，都須要每一個人敢於承擔。理想的狀況下，承擔的債務應當是那些有意的和謹慎的技術債務，而那些無心的和魯莽的技術債務應當不惜一切代價去避免。

爲何要關心技術債務？

技術債務如何影響開發

在開發階段，開發人員不可避免會遇到技術債務，應當直面技術債務，並積極處理技術債務問題。雖然處理技術債務可能會使得開發週期變長，但從長遠來看，開發人員及時處理技術債務是有益的，一方面處理技術債務是一個技術經驗積累的過程，另外一方面及時的處理能夠在以後的迭代中減小技術債務產生的可能等。每個開發人員都應當有意的或者盡力地避免那些無心的和魯莽的技術債務。

技術債務如何影響客戶

雖然乍看起來，技術債務和客戶並沒有聯繫，客戶也不太關心產品的代碼質量等，客戶只須要在成本沒有增長的狀況下，產品可以按時交付使用。然而，一個揹負無心或者魯莽的技術債務的產品在開發過程當中，每每須要花費更多的時間、精力和資源，致使成本增長而收益卻減小的狀況等。

技術債務如何影響用戶

即便是間接的，用戶也會受到技術債務的影響。他們可能不關心軟件開發所需的工做量或資金，但他們確實關心它的可靠運行，以及快速添加的新功能，這二者均可能受到大量技術債務的影響。用戶越快樂，客戶越快樂，開發者越快樂。

技術債務最佳實踐

解決技術債務的最大問題是，它沒法真正被量化。這使得開發團隊很難跟蹤技術債務並讓管理層向客戶展現爲何要投入更多的資源和時間。

可是這裏有一些事情是你能夠作的：

保持最新狀態

不言而喻，工具、框架和庫應該始終保持最新狀態。並非每一個人都能意識到這一點，因此這裏再強調一下也無妨。

文檔

記錄須要修復或更新的全部內容，這是確保實際修復和更新的最重要步驟。

若是存在技術債務，最好了解它並確保團隊或將來的開發人員也瞭解。文檔減小了定位和修復問題所需的工做量，若是債務記錄良好，甚至能在業務層面上可見，將有助於得到客戶認可並提供額外資源。

代碼審查

另外一個強大的工具是在sprint期間按期審查代碼。代碼審查能夠捕捉到可能致使問題的隱患，並找到解決方案。代碼審查確實須要一些時間，但在整個項目的背景下確定是值得的。

可是，代碼審查也有其缺點。開發人員每每太忙，沒法深刻挖掘他人的代碼，所以他們只會發現明顯的錯誤，而吹毛求疵可能會致使團隊內部緊張。所以，它能夠成爲減小技術債務的有力工具，但應該謹慎應用。

自動化測試

自動化測試是一種很是強大的工具，可是常常被忽視。自動化測試被忽略後，可能會沒法察覺出代碼中的隱藏問題，每每致使產品發佈後須要投入不成比例的人力和時間來應對，使得成本變高甚至不可控。在開發階段，有必要實施測試驅動開發，編寫完善的測試用例，以清除代碼中的許多不易察覺的問題等。

敏捷架構

敏捷架構具備不少優勢，在構建軟件的過程當中對更改更加開放，這基本會發生在任何項目上。可是，它確實要求代碼具備靈活性和可維護性，所以敏捷方法天然會使開發人員保持良好的代碼，這有助於防止技術債務的大量積累。

有效地覆盤

若是出現問題，應該敢於面對，當問題解決後，須要進行有效地覆盤。可是要注意的是，覆盤是爲了提升工做效率，而不是爲了找人背鍋。覆盤的重點應放在瞭解問題及產生問題的緣由上，以便團隊能夠採起必要措施防止一樣的問題再次發生。

管理技術債務的最佳作法

即便你作了以上全部事情，並儘量避免技術債務的堆積，仍然會有一些債務須要去處理。這是沒法避免的，所以應該執行最佳實踐和流程以防止技術債務失控。

高利息（高代價）技術債務優先

並不是全部技術債務都是平等的，所以應該優先考慮在特定時間內要解決的問題以及先不解決的問題。存在於常用和更改的部分代碼中的「垃圾」，就比在幾乎沒有使用或更改過的部分代碼中的「垃圾」要嚴重得多。

高息債務每每是那些在項目中起重要做用的核心部分，一般圍繞它進行了不少工做並以此爲基礎。若是此部分的技術債務沒有解決，就會妨礙全部的工做，並可能迫使其餘部分的代碼背上更多的技術債務。所以，若是有可能，首先應優先考慮這些問題，並在後續使一切變得更加順暢。

童子軍規則

「要始終保持營地比你發現它的時候更清潔」也是適用於軟件開發的：「提交的代碼要比檢出的更好」。鼓勵團隊成員，以積極減小技術債務 ; 例如，當他們發現了爲了功能增長或錯誤修復的代碼時，激勵他們重構這部分代碼。

固然，它不能沒有邊界，不然它可能會無止境的消耗時間。可是，若是你在每一個sprint中留出必定比例的時間，專門用於修復開發人員發現的任何技術債務，那麼它能夠在很大程度上保持產品儘量無債務。

在履行有價值的客戶工做時償還債務

在項目的整個sprint階段修復技術債務不是一個好主意。一方面，客戶每每不喜歡延期，對他們來講，看起來你彷佛花了他們的時間和金錢來解決你的錯誤。另外一方面，它也代表你已經因技術債務所累而作了大量工做，因此你可能已經爲了債務付出了超出必要的代價。

最好限制在每一個sprint中償還技術債務所花費的時間，並用它來解決高優先級或忽然遇到的問題。讓客戶滿意，並使技術債務處於可控水平。

忽略

一樣重要的是，要注意並非全部技術債務都應該償還。當產品接近其使用壽命時，若是它是短時間使用或者只是一次性原型時，技術債務不是主要問題。這些實例不多見，可是當它們出現時你能夠節省一些時間和精力。

結論

技術債務是伴隨着項目出現並且沒法避免，可是如何保持其在可控範圍以內，是咱們應該思考的問題。技術債務的避免和消除都須要優秀的開發人員，人始終是軟件開發中最重要的因素。做爲一名普通的碼農，不斷地提高本身是很是必要的。

本文主要譯自：

• TECHNICAL DEBT: EVERYTHING YOU NEED TO KNOW, AND HOW TO MANAGE IT （https://codingsans.com/blog/technical-debt）
  

做者：Gábor Zöld

編譯：TalkingData Robin

​

其餘參考資料：

• 技術負債（https://zh.wikipedia.org/wiki/%E6%8A%80%E6%9C%AF%E8%B4%9F%E5%80%BA）
  

• 技術債治理的四條原則（https://insights.thoughtworks.cn/managing-technical-debt/）
  

• 解析技術債務（https://www.infoq.cn/article/2009/10/dissecting-technical-debt
  

​