什么是技術債？

技術債是由沃德·坎寧安在1992年提出，指我們在軟件架構或代碼編寫過程中有意無意地做了錯誤的決策。隨著時間的累積，這種錯誤會越來越多，就像背負了很多債務一樣。

技術債的危害

技術債同財務債一樣，是有利息的，還債的時間拖的越長，就需要支付更多的利息。很多臨時性的代碼、不合理的架構最終都會造成嚴重的后果，比如：

• 一個小的功能優化，可能會引發大面積的代碼修改，大大提高了開發成本和測試成本，還很容易引入新的問題

• 在客戶的生產環境上，數據量提升一個數量級時，會出現嚴重性能問題，就像是一個隱形炸彈，不知道什么時候會爆掉

• 歷史代碼都不敢修改和維護，最終代碼越來越臃腫，無效代碼越來越多

技術債的形成

以我們現在的產品代碼來看，技術債的主要是以下幾個原因造成：

緊急任務

緊急任務分為兩種情況

1、有時需要有一些演示性的功能需要提前上線使用，主要用于售前
2、客戶的交付時間壓的很緊

上面的兩種情況都將使我們放棄原本好的設計方案，為了能更快速地交付，而采用一些臨時的方式去進行架構或代碼等編寫，并且要求在代碼改動的地方寫上 //TODO： 標記，表示此處是臨時代碼，最終是需要回來進行代碼重構的。

實際情況是，代碼中的 TODO 會越來越多，就像開發經常喜歡說的一句話一樣：“暫時先這樣，后面有時間再來進行優化”，然后就沒有然后了。

缺少溝通

一個初級程序員在修改歷史代碼的時候，如果在沒搞清楚代碼邏輯和業務邏輯的情況下，不和團隊成員進行溝通，就擅自修改代碼，會產生兩種結果：

1、出現的問題會被自動化測試或測試人員檢查出來，當然，這是一種較好的情況
2、修改后有隱藏的問題沒有被檢查出來就發布到生產環境，這種是非常危險的

KPI考核

從8月開始，團隊開始了 KPI 考核，目的是提高每個人的積極性，但如果每個人只是關注考核指標，就會出現「事不關己，高高掛起」的問題。長此下去，每個人的績效可能都還不錯，但產品代碼中的壞味道會越來越多。

所以我鼓勵團隊中的每個人，只要嗅到壞味道，可以提出重構申請，寫出自己的思路和方案，通過后會有額外的獎勵。

技術債要避免嗎？

上面說到技術債的種種危害，那么技術債一定要去避免嗎？其實不一定，例如為了售前演示而快速推出的功能，這種債是必須的，因為可以快速交付，也許就是因為速度快而得到了一個商機。

但因為溝通原因而欠下的債是需要避免的，在團隊協作中，任何時候，溝通都是要排在第一位的。

技術債的償還

出來混，遲早是要還的，欠債也是一樣，欠債并不可怕，只要定期償還，也會是一個良性循環。就像我們按揭買房，每個月得按時還款。

目前能想到的一些償還的方式：

1、代碼提測前的Code Review是后面準備要做的，可以在很大程度上避免一些不必要技術債的產生
2、定期以任務的形式來解決產品代碼中的 TODO 問題
3、溝通非常的重要，需要形成一種團隊文化，充分的溝通也可以避免一些技術債的產生

總結

正確的看待技術債，正向的技術債不可避免，但需要定期償還；負向的技術債需要盡量地減少。所以說技術債是需要合理的規劃和管理的，這也是一個技術管理者需要修煉的技能。

你們的項目或產品中有技術債嗎？

.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總?http://www.csharpkit.com?

總結

以上是生活随笔為你收集整理的你的技术债还了吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。