幾乎所有的技術團隊，都會經歷或多或少的技術債務。技術債務雖然是實現快速收益的一種捷徑，但是爲了修復那些爲了快速收益而不得不爲之的技術問題，企業往往需要花費大量的金錢、人力等。那麼如何有效地避免技術債務，使得開發人員能把更多的精力投入在有效的工作，從而產生額外價值、提高企業的產品競爭力呢？
技術債務的產生有着很多原因，但其中更多的是由於要在短時間內匆忙完成原本耗時較長的工作，導致部分業務邏輯沒有完整的設計等，使得產品在短時間內有效，但是長遠來看，卻是一顆不穩定的炸彈，一旦觸發，對產品、對企業都有可能造成無法挽回的損失。總而言之，技術債務會帶來很多麻煩，有些甚至是“致命”的。
什麼是技術債務？
技術負債（英語：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/t...）
作者：Gábor Zöld
編譯：TalkingData Robin
其他參考資料：
技術負債（https://zh.wikipedia.org/wiki...）
技術債治理的四條原則（https://insights.thoughtworks...）