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

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

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

什麼是技術債務？

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

摘自維基百科框架

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

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

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

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

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

爲何要關心技術債務？

! spa

技術債務如何影響開發

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

技術債務如何影響客戶

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

技術債務如何影響用戶

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

技術債務最佳實踐

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

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

保持最新狀態

不言而喻，工具，框架和庫應該始終保持最新狀態，可能你還未意識到這個問題所帶來的影響，那只是你還沒意識到而已。

文檔

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

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

代碼評審

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

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

自動化測試

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

敏捷架構

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

有效地覆盤

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

管理技術債務的最佳作法

即便你作了以上全部事情，並儘量避免堆積技術債務，你仍然須要處理一些問題。這是沒法避免的，所以您應該實施實踐和流程以防止技術債務陷入困境。

高息技術債務優先

並不是全部技術債務都是平等的，所以您應該優先考慮在特定時間解決的問題以及不解決的問題。對於常用和更改的代碼而言，比在幾乎沒有使用或更改過的部分的重要性要重要得多。

高息債務每每是那些在項目中起重要作的核心部分，一般圍繞它進行了不少工做並以此爲基礎。若是此部分的技術債務保持不變，就會妨礙全部的工做，並可能迫使更多的技術債務被添加到代碼的其餘部分。所以，若是有可能，首先應優先考慮這些問題，從長遠來看，使一切變得更加順暢。

童子軍規則

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

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

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

在項目的整個衝刺階段，用於修復技術債務不是一個好主意。一方面，客戶每每不喜歡延期，對他們來講，看起來你彷佛花了他們的時間和金錢來解決你作錯的事情。另外一方面，它也代表你已經作了大量的技術債務工做，因此你可能已經支付了更高的債務利息。

你最好指定在每一個衝刺中償還技術債務所花費的時間，並用它來解決高優先級或發生過的問題。讓客戶滿意，並使技術債務處於可控水平。

忽略

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

結論

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