昨天我們討論了從「程式碼寫手」到「技術核心引擎」的轉變，而今天的議題，更是檢視一位工程師是否具備資深思維的關鍵：如何看待技術債。

許多人認為技術債都是因為偷懶或程式寫得不好而產生的，這是一個常見的迷思。然而，一位資深工程師都明白：技術債有時並非債務，而是為了快速實現商業目標，在特定時空背景下所做的理性選擇。

技術債從來不是單一概念，它的意義會隨著公司的發展階段而變化。以下我們將其分為三個階段來探討。

第一階段：從 0 到 1，技術債是生存工具

這指的是公司從一個零散想法到產品雛形的時期，目標只有一個：驗證市場，活下來。

在這個階段，技術債的意義是生存工具。為了快速上線、測試市場反應，許多技術上的妥協是必要的。這就像一個新創公司為了啟動業務而借貸，這筆錢不是為了奢華，而是為了生存。此時的技術債，是換取市場先機的理性選擇。

一位資深工程師的任務，就是在這個階段勇敢地借下「正確的」技術債。這不是盲目地偷懶，而是有意識地選擇在非核心功能上做出妥協，並清晰記錄下所有技術債，為未來償還做好準備。

第二階段：從 1 到 10，技術債是風險因子

當公司已經有了一個可行的產品，並開始快速成長，用戶和團隊都在快速擴張。

此時，0 到 1 階段累積的技術債，開始變成風險因子。混亂的程式碼開始拖慢新功能開發，頻繁的 Bug 影響用戶體驗，而新進工程師也難以快速上手。若不開始償還，這筆「債務」的利息將會讓團隊陷入泥沼。

此時，資深工程師的任務是成為技術債的管理者。這意味著必須根據商業價值，找出影響最大的技術債，並與產品經理協商，將一部分開發資源用於償還，同時建立規範，防止新的技術債產生。

第三階段：從 10 到 100，技術債是系統性制約

當公司已經成熟，擁有穩定的產品和龐大的用戶群，產品重心轉向穩定、擴展與優化。

在這個階段，技術債已不僅是單一模組的問題，而是系統性的制約。它會阻礙微服務架構的轉型、難以導入新技術，甚至影響組織層級的敏捷性。此時，零星的修補已無濟於事。

此時，資深工程師的任務是成為技術債的佈道者與驅動者。這需要更強大的領導力：

1. 提出願景： 提出一個長期的技術藍圖，解釋為什麼現在必須投入資源，否則會影響公司的長遠發展。
2. 溝通 ROI： 將技術重構的價值，轉化為具體的業務回報。
3. 領導變革： 協調多個團隊，共同參與大規模的重構或架構升級專案。

技術債與功能的取捨：一個假議題的真相

在公司裡，我們經常會聽到 PM 和工程師之間的經典對話：「我們要先做新功能，還是先處理技術債？」

對公司來說這其實是一個假議題。

這道題的答案並不是非此即彼的「先做哪一個」，而是「取決於我們公司目前的使命」。

• 在 0 到 1 階段，公司的使命是驗證市場，此時技術債的價值高於功能以外的一切，因為它能幫助我們活下來。
• 在 1 到 10 階段，使命是成長與擴張，我們需要同時兼顧功能與技術債，因為技術債已經開始影響成長速度。
• 在 10 到 100 階段，使命是穩定與優化，此時大型技術債的償還變得至關重要，甚至可以為了長遠發展而放慢新功能的開發。

因此，一位真正優秀的資深工程師，不會在「技術債與功能」之間做簡單的取捨。他們會將討論提升到公司使命的層次，讓所有人都明白：我們正在做的每一個技術決策，都是為了公司的長期目標服務。這正是軟實力中，戰略思維的體現。