技術債的真相:今天的捷徑,明天的利息

「技術債」大概是工程師跟老闆之間最雞同鴨講的詞。工程師說「這裡有技術債要還」,老闆聽到的是「我要花錢做一件看不到任何新功能的事」。這篇想用經營者聽得懂的話,把這件事講清楚——因為我們自己既是工程團隊,也是每天看報表的經營者,兩邊的痛都痛過。

用蓋房子講

你趕著開店,工班說:「水電管線照規矩走要兩週,但我們可以先走明線,三天搞定。」你選了三天。店開了,生意做了,這個決定是對的——技術債不是錯誤,是貸款。你借了兩週的時間,提早開始賺錢。

問題在利息。半年後你要加裝設備,師傅看著滿牆明線說:「要先把這些整理掉才能動,原本三天的工變十天。」再過一年,每次小修都要多花一倍時間,而且沒人記得當初哪條線是為什麼這樣拉的。這就是利息:每一次改動都變慢、變貴、變危險,而且複利計算。

軟體完全一樣。當初為了趕上線抄的捷徑,不會消失,只會躲在系統裡對之後每一個需求收利息。老闆常問「為什麼加個小功能要這麼久」,答案有一半的機率是:不是功能難,是它踩在三年前的捷徑上。

怎麼欠得聰明

我們自己也欠技術債,而且是故意的。搶市場時機的時候,先上再說是對的商業決策。差別在於欠得聰不聰明,聰明的欠法有三個條件:

1. 知道自己在欠。最可怕的不是明知的捷徑,是沒人意識到的爛作法。前者是貸款,後者是未爆彈。
2. 寫下來。我們的慣例是在程式碼和文件裡明確標記:這裡是捷徑、為什麼抄、正解是什麼。三個月後接手的人(包括未來的自己)不用考古。
3. 有還款計畫。欠債可以,但要進待辦清單,不能假裝它不存在。

技術債跟貸款一樣,問題從來不是「有沒有欠」,是「知不知道自己欠了多少、利率多高」。

什麼時候該還

不是所有債都要還。一段很少改動、跑得穩定的舊程式,債放著就好,提前還款反而浪費。該還的訊號有三個:同一區域的 bug 反覆出現(利息已經高於本金)、每次改那一塊的時程估不準(工程師自己都不敢預測,代表已經失控)、新人接手要很久才敢動(債變成了組織的瓶頸)。我們自己就有一套舊系統走到這一步,最後決定凍結、重寫——痛,但拖越久越痛。

還款的方式也有講究。最忌諱的是「停下所有功能,大掃除三個月」——業務停擺的壓力會讓大掃除做到一半就被腰斬,兩頭空。比較能持續的做法是編列固定比例:每一輪開發,固定撥一到兩成的時間還債,像房貸一樣按月攤還。速度不快,但它會真的發生,而且團隊會養成「經過就順手修」的習慣,新的債也欠得慢了。

給經營者的實際建議:別要求工程團隊「零技術債」,那跟要求公司零負債一樣不切實際。你該要求的是一份債務清單——欠在哪、為什麼欠、利息多高。順帶一提,判斷一個外包團隊專不專業,可以看他們敢不敢主動告訴你「這裡我們抄了捷徑」;至於怎麼防止債滾到失控,自動化測試是最有效的煞車,我們在這篇講過為什麼。