多年前在一個社群聚會場合，有人跟我聊到他想要解決技術債，但工作上這麼做值得嗎？需求都做不完趕上時程了，技術債真的有必要解決嗎？

技術債為什麼常常被否決？我自己常常看到的狀況是開發端講的天花亂墜，但是完全不管需求端的時程壓力堅決要做。另外就是需求端提出的需求，讓開發端思考整個架構需要大幅翻新，可能會影響開發時程。

這樣的故事可能你也曾經聽過，或是你就是裡面的一員。

難道不處理技術債嗎？繼續用這種框架和架構，來面對接下來的新需求嗎？

技術債不是要不要處理的問題，而是哪些技術債值得現在處理。過去我的做法會先把程式碼翻過和看過，並且將疑點、需要釐清的邏輯，或是前人留下的不可思議的程式碼都一一紀錄下來。接著替它們依功能分門別類，也標上它們執行重構的優先順序。舉例來說，最影響最近要開發的功能會排的比較前面，如果是功能頁需要點到第四層，或是使用頻率大概只有一年一次回顧頁面，相對來說可以放在比較後面。陸陸續續寫下來這些之後，你會得到一個重構優先順序的清單。將來產品要新增功能的時候，可以適時的從裡面挑出項目配合產品功能上線，或是當需求端詢問這需要重構嗎？你心裡也會知道有哪些地方需要做調整。一邊開發新功能、一邊重構。久而久之這個清單會一一被完成，而需要重構的項目會越來越少。我會從幾個面向來看技術債：為什麼要處理、影響什麼指標、影響哪些角色與功能，以及目前的重要程度，給大家做參考：

若是產品很願意給工程師時間調整，也可以從這份清單去挑出來去跟團隊說明為什麼我們要做這些，而對未來的影響有什麼好處。技術債值得解決，但不代表所有債都要現在一次全部解決。