技術人有一個很常見的通病：看到一個舊東西很亂，第一反應不是先想清楚，而是很想直接重寫。
我完全懂那種心情。真的。尤其當你已經被歷史包袱折磨很久，看到一段舊流程、舊模組、舊畫面，心裡常常只剩一句話：這東西不如砍掉重來。
問題是，重做型任務最危險的地方，往往不是技術難度，而是大家太早開始動手。看起來很有效率，實際上只是更早進入錯的方向。等做到一半才發現邊界沒釐清、依賴沒盤乾淨、流程理解有落差，就會開始出現那種熟悉的惡夢：不是在重做舊系統，而是在替下一次重做鋪路。
「直接開幹」為什麼這麼有吸引力
因為它很爽。
真的很爽。
你可以很快建立一個新專案、拉一套新架構、寫幾個漂亮的元件，然後整個人瞬間有一種「我終於離開舊世界」的幻覺。這種感覺很容易讓人誤以為自己正在前進。
但這種前進常常只發生在程式碼層，沒有發生在問題定義層。
而重做型任務最怕的，就是問題都還沒定義完整，解法卻已經跑出好幾公里。
常見徵兆通常長這樣：
- 一開始只說「這套要重做」，沒說清楚為什麼
- 需求邊界模糊，大家各自腦補
- 舊系統哪些是痛點、哪些其實不能動，沒先盤清楚
- 外部依賴、資料流、角色權限，做一段才慢慢補
- 開發進度看起來很熱鬧，但共識其實很薄
這時候團隊很容易掉進一種陷阱：每個人都很努力，但努力的方向不一定一致。最後 code 寫了不少，風險卻沒有真的下降。
重做不是 coding 問題，先把它當成設計題
我現在看到重做型任務，第一個反應通常不是「怎麼實作」，而是「先拆段」。
至少要先拆出兩層：
- 規劃層：重做的目標、範圍、限制、成功條件
- 架構層：模組切分、資料流、整合邊界、遷移策略
這兩層如果沒先站穩，後面的開發就很容易變成賭運氣。
我自己現在偏好的節奏，比較像這樣：
flowchart TD
A[確認為何要重做] --> B[盤點現況與痛點]
B --> C[定義範圍與不做清單]
C --> D[拆出規劃文件]
D --> E[設計架構與模組邊界]
E --> F[確認遷移策略]
F --> G[再進入開發]
這條路看起來比較慢，但它通常是整體最便宜的走法。因為很多真正昂貴的錯誤，都是寫下去之後才發現自己根本不該那樣切。
規劃階段最重要的，不是把需求寫漂亮
很多人聽到「先做規劃」，第一個擔心是會不會變成很空的文件工程。這個擔心完全合理。規劃如果只是把大家早就知道的廢話寫成文件，確實只是在拖進度。
所以我認為規劃階段要處理的不是作文，而是決策。
要回答的問題應該很具體：
- 為什麼這個東西值得重做，而不是局部修補
- 這次要解決哪些核心痛點
- 哪些舊邏輯是必要相容，哪些可以趁機淘汰
- 這次的成功標準是什麼
- 哪些範圍刻意不做，避免失控
尤其「不做清單」超級重要。沒有不做清單的重做任務，通常都會默默膨脹。今天順手多改一點、明天覺得這個一起整理比較乾淨，最後範圍一邊長、一邊還以為自己只是順便。
然後災難就開始了。
架構階段真正要解的，是未來的衝突點
如果規劃是在回答「做什麼」，那架構就是在回答「做了之後怎麼不要撞死」。
我很常看到團隊把架構討論壓縮到很後面，甚至邊做邊決定。不是不能這樣，但前提是任務真的小。只要是重做型任務，牽涉的通常都不是單一畫面，而是角色、流程、資料、整合點一起變動。這種情況下，架構不先想，後面幾乎一定會補到懷疑人生。
我現在在架構階段通常最在意五件事：
- 模組邊界怎麼切，誰對誰負責
- 資料流怎麼走，哪裡是單一真實來源
- 舊系統與新系統的過渡期怎麼共存
- 錯誤發生時，回退策略是什麼
- 哪些地方未來最可能變，現在要不要預留彈性
這些事情如果晚點再想，不是不能補，而是補的成本會很高。因為一旦開發已經展開，每個決策都會牽動更多實作細節，修正就不只是改圖，而是動到一串已經寫下去的東西。
真正的速度，來自減少返工，不是提早寫 code
這件事我以前也容易搞錯。總覺得先動手比較務實，先做出來再調整就好。聽起來很 agile，實際上很多時候只是把設計成本延後支付，而且還加利息。
重做型任務如果一開始就先把規劃和架構拆出來，開發未必會提早開始，但返工通常會少很多。這才是真正的速度。
因為你少掉的是這些東西：
- 開發到一半才重新定義需求
- 元件寫完後才發現模組邊界錯了
- API 做出來才知道流程不成立
- 測試階段才驚覺舊資料很難遷移
- 上線前才發現還有外部依賴沒盤到
這些返工都不是「調一下」而已，它會連帶消耗團隊信心。做越久越心虛，最後大家開始怕改、怕碰、怕再討論，然後一個本來想改善的重做任務，又慢慢長回新的包袱。
技術主管最該守住的，是進場節奏
如果你是帶團隊的人，我覺得你最重要的責任之一，不是第一個跳下去寫，而是守住節奏。
當團隊對舊系統很不耐煩時，大家通常都會想趕快離開現況。這時候主管很容易一起被情緒帶著走，覺得先做點什麼比較安心。但真正該做的，往往是反過來踩煞車。
不是為了拖，而是為了把錯誤的快速，換成正確的穩定。
有時候你只需要多撐幾個討論點：
- 目標真的講清楚了嗎
- 範圍有沒有失控
- 依賴有沒有盤完整
- 遷移策略是不是可行
- 哪一段值得先做 proof of concept
這些問題當下看起來像在阻擋進度，但其實是在替團隊買保險。因為重做型任務最怕的不是慢，而是做了很久之後，才發現一開始方向就偏了。
先拆規劃與架構，不是保守，是尊重成本
所以我現在對重做型任務的態度很簡單：越想直接開幹，越要先停一下。
不是因為我變保守，而是因為看過太多「想用一次重做解決所有歷史問題」的劇情，最後都演成下一輪維護地獄。先拆規劃與架構，並不是文書作業，而是把不確定性提前暴露出來。
這其實是一種很務實的尊重：尊重團隊時間、尊重開發成本、也尊重未來還要接這套系統的人。
如果你手上剛好也有一個看了就想砍掉重來的東西，我的建議會是：先別急著開新專案。先把規劃和架構拆出來，讓問題先長出輪廓，再讓程式碼進場。
這樣做不一定最痛快，但很可能是最不會重做第二次的路。