在軟件工程領域中，“技術債務“是一個貶義詞。人們在使用這個詞的時候常常表達出某種遺憾，過去犯下的錯誤，最終需要通過重構來彌補。
什麼是技術負債？
技術負債（英語：Technical debt），又譯技術債，也稱為設計負債（design debt）、代碼負債（code
debt），是編程及軟件工程中的一個比喻。指開發人員為了加速軟件開發，在應該採用最佳方案時進行了妥協，改用了短期內能加速軟件開發的方案，從而在未來給自己帶來的額外開發負擔。這種技術上的選擇，就像一筆債務一樣，雖然眼前看起來可以得到好處，但必須在未來償還。
技術債務的產生有著很多原因，但其中更多的是由於要在短時間內匆忙完成原本耗時較長的工作，導致部分業務邏輯沒有完整的設計等，使得產品在短時間內有效，但是長遠來看，卻是一顆不穩定的炸彈，一旦觸發，對產品、對企業都有可能造成無法挽回的損失。
總而言之，技術債務會帶來很多麻煩，有些甚至是“致命”的。
那麼身為技術開發者，該如何償還技術負債？
如何償還技術負債？
無意的
由於經驗的缺乏導致初級開發者編寫了質量低劣的代碼。
解決方案：
1.技術培訓
畢竟大部分的程序員學習能力還是很強的，部門牛人的培訓還是很有必要的，也是學習的重要途徑之一。
從最開始的代碼規範、到熟悉業務、最後再到編寫文檔。
2.CodeReview
CodeReview 是非常重要的，同時也是對自身的一個提高。
在這個階段不同工程師之間可以相互review,審查別人的代碼能夠發現很多問題，同時也能學到很多知識。
有意的
團隊根據當前而非未來進行設計選型，這種方式可能很快就能解決當前的問題，但卻很拙劣。
這就情況很可能是為了圖省事才這樣乾的。也有可能是工期太短，人員太少，技術問題等等。
解決方案：
1.系統設計的框架是對的
必須能夠有效處理當前需求可預見的情況，對於未知的、可能出現的特殊情況，很小的改動就能解決問題。
根據當前的業務，進行合理的創建數據表，儘量的代碼解耦和。必須有日誌模塊，操作日誌，錯誤日誌，業務日誌等等...
2.所有的工程師有主人翁的意識
開發前，針對產品提出的需求，進行要進行細節確認，自己也可以畫一個程序的流程圖。
開發時，首先把流程全部順下來，其中遇到調用其他接口、技術難點、需求模糊，及時確認或記錄 TODO 標籤。
開發後，及時對自己的流程進行確認，查看代碼中是否有未解決的地方。
每個公司都有自己任務管理系統，例如JIRA之類的，提測後，時時關注自己的BUG。
如果與產品有分歧的地方一定要及時溝通，達成共識。
3.一定要有健全的測試環境、預發佈環境、正式環境
因為有些程序可能需要進行壓力測試，所以服務器的配置還是很關鍵的。
多個環境的測試，更能保證程序的健壯性。
4.定期處理一些技術債務
等產品上線後，開發就沒有那麼緊啦，這個時間大家可以找個時間處理技術債務，一邊建立感情，一邊品味一下原來的代碼，是不是酸爽無比。
5.善於發現系統的技術債務
勇於發現系統中的技術債務，當然不是為了所謂的獎勵，僅僅是為了自己的提高，讓自己為系統負責，而不是事不關己高高掛起。
當然，最重要的其實是把技術債務的重要性提到一個被認可的位置上。
工程師如果能遇見一個債務可能導致的問題，自然願意花時間去處理。
總結
技術債務是伴隨著項目出現而且無法避免，但是如何保持其在可控範圍之內，是我們應該思考的問題。技術債務的避免和消除都需要優秀的開發人員，人始終是軟件開發中最重要的因素。作為一名普通的碼農，不斷地提升自己是非常必要的。
閱讀更多 一隻IT喵 的文章
