原本是想聊聊類似〈MVP 與 Product〉這樣的主題的，但覺得在這之前必須先暸解技術債這個概念再進行比較好，所以我們今天就來聊聊技術債吧！

關於技術債的基本介紹，前人已經有許多文章詳述了，包括淵源、概念、產生的原因等等，我就不再老調重彈。若是沒看過的朋友，顧名思義大概也能想像這是什麼意思吧。用一句話講明大概就是「開發過程中，因為各種因素妥協而只好先寫出會導致日後維護的困難的程式碼」吧。

許多人或許有這樣的經驗，就是主管一直在趕時程，為了遷就時程只好先妥協寫出帶有技術債的程式碼，想說等之後有時間再來改善。但是主管當時承諾的「還債時間」卻總是不斷推遲，取而代之的是又一個個趕時程的需求插隊進來，最後因為技術債務越欠越多，讓程式碼品質越來越差，維護成本越來越高，導致軟體的研發時程越拖越長，最終在客戶一次次的失望下，成為印上失敗戳記的專案。

不確定各位有沒有看過我前面寫的〈重構的時機〉這篇文章，或是看過後不知道還記不記得，在那篇文裡面有提到一個名詞，叫做「技術債清單」。看到這個名詞，或許我們會聯想到一件事，那就是「咦？技術債其實也是可以被管理的，而不是跳過後就繼續忘在那邊？！」，沒錯，就是這個道理！

讓我先幫大家回憶一下那篇文章的敘述：

通常順手可以完成的重構是可以在開發功能或修復缺陷時，順手完成。但是若遇到需要一個不短的開發時段去完成的重構，會建議先記錄在一個團隊都看得到的清單（可能是技術債清單、或是壞味道清單），並在每次規劃進度時，也挑一到數個（團隊與主管或客戶雙方都能接受的範圍）希望重構的項目，一起列入開發成本或待辦清單，透過這種方式逐步改善。

其實重構這個動作，某種程度上就是在還技術債，所以這段敘述可以搬過來直接用的。當我們發現我們在開發時，不得不欠債時，就先將這個債務記錄在某個地方，可能是 Issue Tracker、可能是看板上，只要在團隊能常看到、方便關注的地方都好。這樣我們就可以在規劃進度時，除了針對有價值的功能去實作外，也挑選數個債務去還。

但還債這件事情，似乎只有工程師看得到其價值，對於非工程人員、主管或是客戶是相對無感的。那我們就必須嘗試說服他們修復這個技術債的好處，或是讓他們看到這個技術債會帶來的副作用，像是前面提到常常發生的軟體到最後改不動的困境、或是找 Bug 會越來越困談、需要投資的研發人力會越多，但效益會越來越低等等，在談論時技術部份可以略提，但是從軟體未來發展以及對客戶會造成的負面影響下手會顯得有說服力。

然而，當技術債的數量越來越多時，我們就得面臨抉擇：到底要先還哪個債呢？其實這個問題不難，把這個債務的概念回到金融上去思考，還債當然是先還利息高的債呀！那麼我們要如何評斷利息高低呢？這部分又不如金融一樣有明確的數字可以表示。這部分乍聽之下的確是個難題，但是事實上是可以透過圖表去表示的。

我們可以畫一張第一象限的座標圖，讓 X 軸代表時間，讓 Y 軸代表還債成本，並且畫一條線表示還債成本隨時間的變動。有些債務是一直欠著也不會增加成本的，那可能就會是一條水平線；有些債務是若不還，會緩慢增加成本的，那可能就是一條斜率不高的直線；有些債務可能短期內不還影響不大，但若在某件事或某個時間點仍沒還清，成本就會爆炸成長的，那就會是一個前面趨近水平，但是通過某個時間點後變成指數限性⋯⋯等等。透過這種圖表方式，就能將技術債利息的特徵給視覺化，讓我們在抉擇要先還什麼債務時，給予很大的幫助。

技術債是個很有趣的議題，但我們今天大致就先點到這邊。之後若是沒有其他主題可寫，或許我會再寫一篇聊下去。但是至少有個問題是我明天打算聊的，那就是「技術債可以不還嗎？」如果可以，那會是在什麼情境呢？大家可以先好好想想，我們明天見。