採取行動消除技術債

五個要點開始針對祖產還債

技術債，就像任何債務一樣，如果不加以管理，會逐漸累積，最終導致開發過程中的重大障礙。在前面的章節我們已經介紹了一些面對技術債時，我們要怎麼量化，以及怎麼將這件事跟團隊的其他人溝通。

在這個篇章，我們要來說明怎麼進行規劃來落實消除技術債。

了解當前專案狀態

首先，對當前專案的理解，是解決技術債的第一步。這包括對使用的架構和技術的深入理解，識別理想中跟現實測試可能存在的障礙、程式碼的複雜性、重複性以及任何存在的可能脆弱點或不尋常之處。這個階段中，重要的是要將這些發現記錄下來或是清單化，後面可以檢視是否已經處理。

比對產品的路線圖

通常我們會把前面整理的清單也放入到 product backlog 中，同時針對產品的長遠路線圖排序，確保哪些技術債將直接影響到即將開發的功能，並優先處理這些問題。

針對怎麼處理問題，我們可以問：我們的產品或架構將如何發展？我們打算做哪些改變可以同時符合品質跟價值？

技術債相關的文件

把問題記錄下來給別人關注，或是透過一些簡單的內容確保大家都對於技術債有持續的共同理解。但最重要的是寫的文件要定期檢查，確保內容是最新的，不然大家還是會對於錯誤的文件產生錯誤的理解而造成生產力的浪費。

測試碼覆蓋後再修改

這個在 2023 年應該是很常見的策略，先對現有程式碼進行測試覆蓋，然後再進行修改。在處理遺留程式碼（Legacy Code）時，我們可以透過撰寫測試碼檢查邏輯是否運作正確，確保後面的重構不會造成功能的損壞或不正常運作。

但在實踐中，我們經常會遇到一些挑戰，例如時間壓力、測試難度，或對程式碼功能的不理解。我們常常聽到「我沒有時間寫測試！」但不寫測試直接修改程式，只會導致程式更難修改或除錯，或是技術債增加，造成「更急更慢」的現象。或是工程師可能會抱怨「我無法測試這段程式碼」，通常是因為程式碼過於依賴或是耦合。如果工程師不清楚要修改的地方的時候，先運用一些簡單的測試或猜想，看看執行結果後，來幫助理解現有程式碼的行為。

重構

《Refactoring: Improving the Design of Existing Code》和《Working Effectively with Legacy Code》 這本書有中譯本，很值得參考。這邊我想簡單說明兩個內容。

第一個是我們能不能直接重寫整個 app？直接重寫整個應用是找自己麻煩，所以通常會先是小部分的拆解與模組化重構成函式，再逐步把組件解耦。

另外一個是有人提倡微服務。通常會有這樣的考量是單體應用難以維護，而微服務架構包括獨立部署的服務，這些服務易於替換且不需要統一的技術選擇。但要注意的是如果非常注重效能跟反應時間，則不能選擇微服務，因為跨服務間的資料交換是耗時的，對於注重效能跟反應時間的應用程式來說反而採取微服務是一種毒藥。

結論

處理技術債需要想很多，包括工程團隊跟管理階層的心理狀態，工程面的測試覆蓋率、程式碼可擴展性和重構工作。另外了解當前專案狀態、產品路線圖，以及未來的規劃才能確保在償還技術債的同時，也持續發布新功能面對市場。