不懂技術的老闆，怎麼判斷工程師說的「要重寫」是真的還是想偷懶？5 個技術債信號、3 條替代方案決策框架與外包專案 6 道把關題

工程師說「這個系統要重寫」——有 30% 是真的、有 40% 是真假混在一起、有 30% 是想偷懶或想累積履歷。不懂技術的老闆遇到這句話最常見的兩種反應是：（1）全信、立刻批 100-300 萬重寫；（2）全不信、跟工程師槓上拖了 6 個月、最後系統當機才後悔。兩種都會付學費。中間那條路——「先判斷、再決定該不該重寫」——才是省最多錢的反應。

最近我們陪幾位中小企業老闆處理「工程師建議重寫」的情境時發現一個共同 pattern——老闆通常卡在「我不懂技術，怎麼判斷工程師說的是真的」。真正的問題在於老闆缺乏「不靠工程師也能驗證」的判斷工具，至於該不該重寫反而是其次。我們在歷年系統客製化諮詢與接案經驗中整理出 5 個技術債真實信號 + 4 個假信號 + 3 條替代方案 + 6 道把關題，這篇給你完整框架。

先把幾個關鍵數據放這裡。Stripe 2018 The Developer Coefficient 報告 指出，全球工程師每週花 17 小時（總工時的 42%）在維護或重寫既有程式碼，這份成本被嚴重低估。McKinsey 2024 Tech Debt 報告 進一步指出，超過 60% 的企業承認技術債正在拖慢轉型速度，但只有 30% 的企業有系統性的「重寫 vs 重構」決策框架——剩下 70% 是「工程師說了算」或「老闆說了算」，兩種都有偏差。Google 在 Site Reliability Engineering 書中對重寫專案的成功率統計 也顯示，未做評估直接啟動的全面重寫專案，2 年內成功率不到 40%。

為什麼老闆 90% 都被「要重寫」嚇到

重寫這個詞在老闆耳裡有 3 個直接聯想：「要再花一次錢、要再等半年、舊系統可能 broken」。三個聯想都對、也都會發生——但問題不在重寫本身，在「該不該」跟「該怎麼」的判斷沒人做。工程師說要重寫的時候，老闆通常會出現 3 種反應：

第三種反應是這篇文章的核心。要做到「先判斷」，老闆要學會 2 件事：（1）區分真信號跟假信號；（2）知道除了「全面重寫」之外還有什麼選擇。下面把這 2 件事拆開講。

真正該重寫的 5 個技術債信號

這 5 個信號是我們在系統客製化諮詢中遇到「該重寫」案例的共同特徵。出現 3 個以上就高度可能真的該重寫；出現 4-5 個基本上跑不掉。

信號 1：每加一個小功能，bug 數會超過 3 個

這叫「副作用無法封閉」，是技術債最直接的訊號。健康系統加一個小功能（例如改個欄位、加個欄位）應該不影響其他模組；如果每加一個小功能都會在別處冒 3 個以上的 bug，意味著程式碼模組邊界已經崩壞、改 A 必動 B。

信號 2：底層框架已停止維護超過 3 年

例如系統建構在 Angular 1.x（2014 年版本，已 EOL）、PHP 5.x（已停止安全更新）、Node 10.x（已停止維護）這類「廠商已宣布不再支援」的版本上。安全漏洞無法修、新功能無法接、新人不會寫——這是真信號。

信號 3：沒有任何測試、改錯沒人知道

0 行單元測試、0 行 E2E 測試的系統，每次改完都是「上線後等使用者抱怨」才知道改錯。系統規模超過 5 萬行程式碼還沒測試，重寫的需求是真的。

信號 4：原始開發者已離職、文件 0、註解 0

這叫「知識斷層」。一個系統如果原作者已離職、沒留下任何架構文件、程式碼也沒註解、新工程師要靠閱讀 origin code 摸索 1-2 個月才能改一行——這個系統的維護成本會無限上升。重寫往往比繼續維護便宜。

信號 5：核心業務邏輯卡在資料庫 trigger 或 stored procedure 裡

雖然這個信號很技術，但老闆可以驗證：問工程師「如果要改一個業務規則（例如折扣計算方式），會動到幾個地方？」如果答案是「資料庫 + 後端 + 前端各動一處、且我不能保證都改到」——這就是 5 號信號。架構選錯了、重寫是唯一的根治。

想偷懶 / 想累積履歷的 4 個假信號

假信號通常是「工程師主觀偏好」或「個人職涯動機」，跟系統實際健康狀況關聯度不高。出現任何一個假信號都要警覺；出現 2-3 個基本可以確定是想換技術棧、不是真的該重寫。

假信號 1：「這個語言過時了、改用 Rust / Go / TypeScript」

語言本身過時很少是重寫的真實理由。PHP、Python、Ruby 都還在大量生產系統上運作得很好。如果工程師的主要理由是「語言不夠潮」、而不是「語言相關生態系出問題」——這是假信號。

假信號 2：「現有架構不夠 scalable，將來要做大應該重寫」

「將來」是這句話的關鍵字。如果系統目前處理量只用到 20% 容量、業務量未來 12 個月也不會翻 3 倍——「將來 scalable」這個說法就是 over-engineering 的開頭，不能算重寫的理由。

假信號 3：「微服務比較好、應該拆」

微服務適合「業務模組成熟 + 團隊規模超過 30 人」的場景。中小企業 5-10 人的工程團隊把單體拆成微服務，通常會在 6-9 個月後因為「跨服務溝通變複雜、debug 困難」反悔回去。

假信號 4：「現有程式碼太爛、看不下去」

新工程師覺得舊程式碼爛 90% 是真的（包含我們自己寫過的程式碼，3 年後回頭看都爛）。但「爛」跟「該重寫」是兩件事。問工程師具體爛在哪、影響的具體 KPI 是什麼——說不出來就是假信號。

3 條替代方案：重構不是只有重寫

業界對「系統老化」的標準解法有 3 條，全面重寫只是其中之一、而且是最貴最慢的那一條。Martin Fowler 在 Refactoring 第二版裡也明確指出：90% 的「該重寫」情境用 strangler fig 或漸進重構就能解決，全面重寫是最後手段。

方案 A：Strangler Fig（絞殺者藤蔓模式）

新功能寫在新系統、舊功能繼續在舊系統跑，逐步把舊系統的功能用「同等接口」替換掉。新舊系統並行 6-18 個月後，舊系統自然死掉。Martin Fowler 命名的這個模式是中大型系統最常用的替代方案。成本約等於全面重寫的 60-70%、風險低 80%。

方案 B：漸進重構（incremental refactoring）

不改架構、不換技術棧，只逐模組整理程式碼、加測試、改命名。適合「程式碼亂但架構還好」的情境。成本最低（10-30% of 重寫）、但需要工程師有足夠紀律持續做。

方案 C：隔離 + 微服務切片

把最爛的 1-2 個模組單獨抽出來改寫成微服務、用 API 跟舊系統接。其餘部分維持原狀。適合「大部分還能用、只有 1-2 個模組壞透了」的情境。成本約全面重寫的 30-50%。

重寫的真實成本（老闆要算的 3 種帳）

全面重寫的成本不是只有「給工程師的薪水」，至少要算 3 種帳：人力成本、營運斷層成本、機會成本。我們把每種攤開算給你看。

老闆最常忽略的是『營運斷層成本』。新系統開發期間，舊系統不能停、bug 還是要修、客戶問題還是要解——這意味著工程團隊一邊蓋新房、一邊修舊房。如果原本團隊 5 人，重寫期間實質產能只剩 50-60%，這 40-50% 的損耗是必然的。

我們有準備一份「重寫 vs 重構 60 分鐘自我診斷表」，跟我們聊聊現況 就會給連結——可以自己 60 分鐘填完評分、不一定要進入諮詢階段。

外包專案的 6 道把關題

如果你的系統是外包做的、現在外包商建議重寫——老闆要多防一層。下面 6 道題是我們陪老闆跟外包談判時最常丟出來的問題。任何 1 題答不上來，建議先暫停、找第三方做技術審查。

把關題 1：請列出最近 3 個月加新功能時、有多少次副作用 bug？

這題在驗證信號 1（副作用無法封閉）。具體數字、具體案例答得出來 → 真的有問題；含糊帶過 → 假信號可能性高。

把關題 2：請列出目前底層框架 / 函式庫的版本、廠商支援狀態？

這題在驗證信號 2（底層停止維護）。如果答出來都是「主流、有支援」的版本——重寫的理由不在框架。

把關題 3：現有系統有多少行測試程式碼、最近半年改錯被測試擋下幾次？

這題在驗證信號 3（測試缺失）。同時也測外包商有沒有「持續維護測試」的習慣。

把關題 4：如果今天找 3 個工程師看這個系統，多久能接手改 bug？

這題在驗證信號 4（知識斷層）。1 週能接手 → 系統相對健康；要 1-2 個月 → 真有問題。

把關題 5：除了全面重寫，有沒有評估過 strangler fig / 漸進重構 / 微服務切片？

這題在驗證外包商的職業誠信。沒評估過替代方案就直接跳全面重寫——通常代表他想接這個案子。

把關題 6：如果我請第三方做技術審查，你願意配合嗎？

這題是終極測試。願意配合 → 提案可信度高；推託或反對 → 高度可疑。健康的外包商會歡迎第三方審查、因為這幫他證明提案合理。

3 種典型情境的決策樹

把上面的 5 信號 + 4 假信號 + 3 替代方案 + 6 把關題串起來，老闆遇到「要重寫」對話時的決策樹分 3 種情境。

情境 A：業務變陣（新增大規模新功能）

如果重寫的理由是「現有系統撐不起新業務模式」——先評估能不能用 strangler fig 把新業務寫在新系統、舊業務繼續跑。能 → 不該全面重寫；不能（例如資料模型完全不同）→ 進入全面重寫評估。

情境 B：技術過時（框架 / 函式庫 EOL）

如果重寫的理由是「框架已停止維護」——先評估升級路徑。例如 Angular 1 → Angular 17、Node 10 → Node 22、PHP 5 → PHP 8 都有明確升級路徑（不一定是順暢、但有）。有升級路徑 → 漸進升級；無升級路徑 → strangler fig 或全面重寫評估。

情境 C：人員流失（原作者離職、無人懂）

如果重寫的理由是「沒人懂這個系統、改不動」——先做「技術文件回填」嘗試：請外部資深工程師花 4-8 週逆向理解系統、補文件、加註解、補測試。回填後仍無法維護 → 進入重寫評估；回填後能維護 → 不該全面重寫。

如果你正面對「工程師說要重寫」的情境、又不確定該信幾成，跟我們約 30 分鐘技術第三方審查初談——我們可以用 5 信號 + 6 把關題的框架陪你跟工程師對一次話，30 分鐘內你會帶走「信號出現幾個 + 替代方案有哪幾條 + 接下來該做的下一步」。第一次審查免費。

延伸閱讀：什麼是技術債？為什麼系統越改越慢、系統上線後第一年維運、技術債與持續優化、不懂技術的老闆怎麼管外包專案、老闆找外包做 AI 怎麼判斷廠商「真的會做」、微服務還是單體？老闆看得懂的選型、客製化網站與系統開發、AI 系統客製化開發，可以一起讀。