系統越用越慢、bug 越修越多：該修還是該重做

「現在每次修一個 bug，就會冒出兩個新的。查一張訂單要轉好久，月底跑報表大家只能先去倒杯水。」

這是系統用了幾年之後，很多老闆都會碰到的狀態。剛上線的時候很順，後來加了一些功能、接了幾個串接、資料一年一年累積，某一天你突然發現，大家已經不太敢動它了。每次改東西都提心吊膽，廠商報的修改費越來越高，交期越來越長。最後有人提議：「乾脆整套重做吧。」

我是熊董，台灣川輝科技創辦人。我帶團隊做系統導入七年，經手超過 34 個案子、14 個以上產業，現在一個人加 AI，一年交付 2,000 萬以上的客製系統。我接手過別人交付不了的系統，也接過前一家廠商建了好幾年、從來沒上線的系統。所以「修還是重做」這個問題，我在現場回答過很多次。系統越用越慢、bug 越修越多，很少是因為某一個錯誤，而是技術債長年累積的結果：資料量長大了但結構沒跟著調整、功能一層一層往上疊、沒有測試也沒有文件、中間換過好幾手。該修、該重構還是該重做，看兩件事就好：核心的資料結構還對不對，以及你的業務規則有沒有大改。資料結構還對、規則沒大變，就修和局部重構；資料結構從根本就錯了，重做是遲早的事。而大部分情況下最好的路，是「逐塊替換」，不是一次推倒重來，因為一次重做最大的風險，是把多年累積在舊系統裡、沒人寫下來的規則弄丟。

先承認：想乾脆整套重做，這個衝動很可以理解

我完全理解想重做的心情。每天被一套又慢又會出錯的系統折磨，員工抱怨、客人等待、修改費一直付，換作是我也會想把它整個丟掉、重新來過。而且重做聽起來很乾淨：新的技術、新的架構、把這幾年學到的教訓全部放進去，一次解決所有問題。

有時候重做確實是對的選擇，我後面會講什麼情況該重做。

但我要先提醒一件事：重做的成本，幾乎每一次都被低估。不只是開發費用，還有重新整理規則的時間、資料搬移的風險、新舊系統切換時的混亂、以及員工重新學習的代價。更麻煩的是，舊系統雖然很爛，它卻默默承載了很多你已經忘記的規則。所以在決定重做之前，先搞清楚系統到底病在哪裡。

系統為什麼越用越慢？四個常見原因

「慢」聽起來是一個問題，其實背後的原因可能完全不同，而且有些修起來很便宜。

第一，資料量長大了，查詢方式沒跟著調整。 系統剛上線時只有幾千筆資料，怎麼查都很快；幾年後變成幾十萬筆，原本的查詢方式就開始吃力。這種慢通常集中在特定畫面或報表，而且是一年比一年慢。很多時候只要調整資料庫的索引或查詢寫法，就能大幅改善，不需要動到架構。

第二，報表都是即時計算。 老闆要看的報表，每次打開都從所有原始資料重新算一遍。資料少的時候沒感覺，資料多了就會越來越慢，還會拖累其他人的操作。改成定時預先算好、或把歷史資料整理成彙總表，通常就能解決。

第三，外掛和串接一層一層疊上去。 這幾年加了電商串接、加了 LINE 通知、加了會計匯出，每一個都是在原本的系統旁邊再掛一個東西，彼此同步、互相等待。系統本身不一定慢，是那些串接在拖。

第四，主機和架構跟不上使用量。 使用的人變多、資料變大，但主機規格和架構還是當初的設計。這種情況有時候升級主機就能撐一段時間，但如果架構本身不適合現在的規模，升級只是延後問題。

判斷是哪一種，要看「慢」發生在哪裡、什麼時候慢、是不是越來越慢。這一步不需要重做，需要的是一次健檢。

bug 為什麼越修越多？技術債長什麼樣子

技術債這個詞，簡單說就是：當初為了趕時間、省成本，用了比較快但不夠好的做法，這些做法會在之後每一次修改時收利息。

你不需要懂程式，也可以從這幾個徵兆判斷技術債有多重：

• 改一個地方，壞另一個地方。 代表程式之間的關係糾纏在一起，而且沒有自動測試可以在修改後馬上發現問題。
• 同一條規則，要改好幾個地方。 例如調一個折扣規則，要改報價、訂單、發票三個地方，漏改一個就出錯。代表規則被複製貼上散在各處。
• 只有某個人知道怎麼改。 沒有文件，所有知識都在某個工程師腦袋裡，他一離開，下一個人要從頭摸索。
• 換過好幾手。 每一家廠商、每一個工程師都有自己的寫法，疊在一起就變成誰也看不懂的拼裝車。
• 修改報價越來越高、時間越來越長。 這是技術債最直接的財務訊號：每一次修改都要先花時間理解、再花時間小心避開地雷。

這些徵兆出現得越多，代表每一次修改的成本越高。但即使徵兆很多，也不代表一定要重做，關鍵要看下一段的兩把尺。

修、重構、重做，怎麼判斷？

我用兩把尺來判斷。第一把是核心資料結構還對不對：系統裡最重要的東西，例如客戶、訂單、產品、庫存，它們之間的關係設計，是不是還符合你現在的生意。第二把是業務規則有沒有大改：你的生意模式、流程、規則，跟當初做系統時比，是小修小補還是根本不一樣了。

情況	建議	理由
資料結構對、規則沒大變	修補與效能調整	骨架還好，問題多在查詢、報表、外掛
資料結構對、規則改很多	局部重構	重寫規則所在的模組，保留資料與骨架
資料結構有問題、規則沒大變	逐塊替換	一塊一塊換掉，新舊並行，降低風險
資料結構錯、規則也大改	規劃重做	骨架和用途都不對了，修補只是延後
原始碼拿不到、沒人看得懂	先拿回東西再評估	連病在哪都看不到，任何決定都是猜

什麼叫資料結構錯了？舉例來說，當初設計時一個訂單只能對應一個出貨，但你現在常常分批出貨；或一個客戶只能有一個地址，但你現在有很多客戶是連鎖店、要出貨到不同分店。這種結構性的錯，會讓所有相關功能都要繞路處理，繞得越多，bug 就越多。如果核心結構錯了，修補只是在一個歪掉的地基上繼續加蓋。

舊系統到底該不該換，還有一些其他的訊號，可以搭配舊系統什麼時候該換那篇一起看。

重做最大的風險：把舊系統裡的規則弄丟

就算判斷下來真的該重做，也要知道重做最常失敗在哪裡。

舊系統用了好幾年，裡面藏著大量你已經忘記、也從來沒寫下來的規則：某類客戶的特殊折扣、某種產品的計算方式、某個月底的自動處理、某個欄位為什麼不能是空的。這些規則可能是當年某次客訴之後加的，可能是會計某一次發現錯誤之後補的。它們沒有出現在任何規格書裡，但系統一直默默在執行。

一次重做的時候，大家拿著「我們想要的樣子」去寫新規格，這些隱藏規則就很容易被漏掉。新系統上線之後，各種奇怪的錯誤開始出現，一查才發現：「原來舊系統有處理這個。」

另一個風險是時間。一次重做通常要很長的時間，這段期間舊系統還在用，業務還在變，等新系統做好，需求又已經不一樣了。最糟的情況是新系統一直做不完，舊系統也沒人敢再投資，兩邊都卡住。

逐塊替換：比一次重做更安全的路

所以除非資料結構和業務都已經完全不對，我通常建議逐塊替換：不要一次把整套換掉，而是一塊一塊換，每一塊換完、穩定了，再換下一塊。

第一步，健檢與盤點。 把系統的模組、資料、串接、隱藏規則盡量盤點出來。最好的方法是看真實的資料和操作，而不是只問人。

第二步，先補監控和備份。 在動任何東西之前，確保資料有完整備份、出錯時能馬上發現。這是安全網。

第三步，挑最痛的一塊。 通常是最慢、最常出錯、或規則最需要改的那一個模組。

第四步，新舊並行。 新的模組做好之後，先跟舊的同時跑一段時間，比對結果是否一致。不一致的地方，往往就是那些隱藏規則。

第五步，切換並下線舊模組。 確認新模組穩定之後，正式切換，把舊的那一塊關掉。

第六步，重複。 回到第三步，挑下一塊。

這種做法比較慢，但每一步都看得到成果，風險也被切成小塊，任何一塊出問題都不會讓整個公司停擺。

接手別人的系統，先做這三件事

如果你的系統是前一家廠商做的，現在對方不太配合、或已經聯絡不上，那在判斷修或重做之前，有三件事要先做。

第一，把東西拿回來：原始碼、資料庫、主機和網域帳號。拿不到這些，任何判斷都只是猜測。我們接過一個醫美品牌的系統，前一家廠商建了好幾年從沒上線，我們做的第一件事就是先把東西拿回來，再決定怎麼重做。完整的步驟可以參考系統被前一家廠商做爛了怎麼辦。

第二，找一個獨立的人評估。不要只聽原廠商說「這個要全部重做」，也不要只聽新廠商說「這個很好修」。雙方都有自己的立場，最好找一個看得懂程式、但不急著接你這筆生意的人看一次。

第三，評估完再談錢。接手別人的系統，難度通常比從零開始還高，因為要先理解別人的寫法。我們接過一個影音（OTT）平台，前一家廠商交付不了，我們接手之後 3 個月做完 18 項功能。我想說的不是速度，而是順序：接手別人的系統不是不能做，但一定要先把現況摸清楚，知道哪些能留、哪些要換、哪些規則藏在哪裡，再承諾範圍和時間。沒摸清楚就報價、就開工，通常是下一個做不完的開始。

常見問題

系統重構要花多少錢、多久？

完全看範圍。效能調整和修補可能只是幾天到幾週的事；局部重構一個模組，通常以週到月計算；整套重做則是一個新的開發專案。重點是先健檢、把範圍切清楚，再依書面規格報價，不要在不知道病在哪的時候就談總價。

原本的廠商說一定要整套重做，可以相信嗎？

不一定不能信，但要問清楚理由。請他具體說明是哪一部分的結構有問題、為什麼修補不行、重做之後哪些問題會解決。如果答案只是「舊的技術太老了」，卻講不出具體會影響什麼，那就值得找第二個意見。

不懂技術的老闆，怎麼判斷該修還是該重做？

你不需要看懂程式，但要能回答兩個問題：系統的核心資料結構，還符不符合你現在的生意？你的業務規則跟當初比，變了多少？前者可以請技術人員用白話解釋，後者你自己最清楚。把這兩個答案放進上面的四象限，方向大致就出來了。

系統維護費包不包含修 bug 和效能調整？

要看合約怎麼定義。我們的原則是，同一件事繼續跑，叫做維護；要做新的事，叫做導入或開發。系統維護 NT$20,000／月，只接我們自己做過的系統；別人做壞的系統，會先免費診斷評估，再決定該怎麼接。維護費怎麼算才合理，可以參考系統維護費怎麼算。

結語：先找出病在哪，再決定要開刀還是換人

系統越用越慢、bug 越修越多，不代表一定要重做。先健檢，看資料結構還對不對、業務規則改了多少，再決定修、重構還是逐塊替換。重做是最後的選項，而且就算要重做，也要一塊一塊換，別把舊系統裡的規則一起丟掉。

如果你的系統已經到了大家不敢動的地步，不知道該修還是該換，可以先看看系統維護與接手，了解我們怎麼評估一套現有的系統。