RUBY 大叔｜什麼是「技術債」？4 個避免「技術債」產生的建議

本篇來自 RUBY 大叔 觀點分享，Meet.jobs 經編審刊出。原文標題：什麼是「技術債」？不只工程師要懂，老闆更要知道！。

技術債指的是開發人員為了加速軟體開發，忽略長期效益及品質，改以短期能加速開發的方案，導致未來要花更多時間、技術、資源來修補額外開發負擔，就像一筆債務一樣，看似得到好處但未來得償還。技術債問題在各行各業都可能發生，例如，餐廳可能在初期因省預算採便宜設備，造成未來品質下降或食安問題，或部分建築業也會有為省預算或趕工「偷工減料」用不夠符合標準的方式建造，造成未來需要重新設計等情況。

別以為技術債只會發生在不熟技術或經費不足的公司上，像 Facebook、Google 或 Amazon 這種知名科技龍頭也曾發生過類似事件，我認為技術債很難真正歸咎對錯，早期軟體開發環境較單純，網路也沒有現在普及，現在的網路環境、軟體複雜度及網友使用習慣不斷變化，開發團隊必須不斷地迎接新挑戰、新需求。我也碰過為了要緊急解決眼前問題，沒有足夠時間理解整體結構的情況，能感同身受其中的辛苦啊！

時間如何讓「技術債」一一現形？

技術債通常是經過一段時間才會被發現，在技術領域中有個現象被稱為耦合（Coupling），指的是系統模組之間互相依賴或相互關聯，就像手錶齒輪般互相牽引，如拿掉其中一個齒輪，另一個齒輪也連帶受影響或不能運作，我舉個例子，就像聽一場演唱會，歌手與樂手、樂隊演奏彼此互相關聯、協調，若有一方沒聲音或麥克風、音響出錯，或是趕著上場沒時間彩排（測試），就可能影響演唱會效果。

網站重建改版絕對不止「新增」或「拿掉」某些功能這樣簡單，過去有企業來找我，他們也是經過一段很長時間才發現網站問題，想要進行網站改版或重建，並提出想新增的功能，我進到後台一查看，發現因「耦合」緣故，無法只拿掉一個功能，維持另一功能的正常運作，模組跟模組之間相互依賴的程度越高，就會增加程式碼的複雜度，我的任務在於努力降低耦合，讓整個系統邏輯正確，有更好維護及擴充。

如何有效避免「技術債」的產生呢？

技術債的存在不一定都是壞事，有時技術債的產生反而可以幫助我們在一些情況下，發現企業長遠需求及問題，至於如何避免「技術債」，以下提供四個建議：

第一，具備測試概念：及早發現及早治療！對每一個功能進行不同測試，確保功能在串接或應對不同需求都可以順利運作，這樣也可以替未來打下好的結構基礎。

第二，不定期檢查清除技術債：科技變化快速，每隔一段時間必定會發現不適用於新環境的功能，必須評估是否優化，如不優化，也要同步檢視是否會對企業造成長遠性的負面影響，有何風險等。

第三，避免過早「最佳化」：雖然規劃未來是好事，但如是現行階段的開發，建議只需考慮「現在的需求」，如現階段不需要的功能就不要先做，有時提前設想反而最增加「技術債」風險。

第四，重視技術團隊：事在人為，一般有決定權的老闆不一定會懂技術，如公司有工程師，必須確認是否對技術債概念有認知，而且要讓老闆清楚知道技術債會衍伸的問題。今年我們協助專門提供用戶「創立禮物清單」與親友分享的禮物登記平台 Thankful Registry進行網站大改版，當中也解決了一些技術債問題，有興趣了解在改版上可能碰到哪些問題的人，可以看看這篇，下次聊囉！