模組五｜重構期的品質與節奏（Day 22–26）

新系統的請求層有這麼一行：

const { code, data, msg, sucess, total } = res.data

sucess。少了一個 c。

正確拼法是 success，而且這個字在專案裡的正確版本出現了 73 次，所以顯然不是大家不會拼。

那為什麼這裡是錯的？

因為那是後端回傳的欄位名。 前端只是照著解構，改了就拿不到值。

昨天講「重構就是刪減」。今天講相反的一面：有些東西你知道它醜、也知道怎麼修，但正確的決定是不要動。

判斷該不該改的三個問題

我後來歸納出三個問題，依序問完就知道該不該動。

問題一：這個東西的「主人」是誰？

那個拼錯的欄位，主人是後端 API 的回應格式。

要改它，得動：後端的程式碼、所有其他呼叫這支 API 的系統、以及可能已經對接的外部單位。

而改完之後的收益是：眼睛比較舒服。

這個帳算得出來。所以不改。

反過來說，如果那個拼錯的是前端自己的變數名，主人就是我們，那就該改，而且改起來只是一次搜尋取代。

判斷該不該改，先確認你有沒有那個東西的所有權。

問題二：它會不會擴散？

這才是關鍵，而且我覺得團隊在這裡做對了一件事。

那個 sucess 在整個專案裡只出現 6 次，分布在 3 個檔案，全部集中在請求層和兩個直接使用它的地方。

而正確拼法的 success 有 73 次，那些都是前端自己的變數。

也就是說：錯誤的拼法被留在邊界上，沒有滲進業務程式碼。

這件事很重要。因為同一個問題可以有兩種處理方式：

• A：接受它，然後讓它一路傳下去。 於是每個頁面、每個型別定義、每個變數名都跟著錯。
• B：接受它，但在最外層就轉成正確的形狀。 內部只有一個地方知道外面拼錯了。

我們比較接近 B。這是「隔離」而不是「修正」：你改不掉外面的世界，但你可以決定它能滲透多深。

用一個場景：

你租的房子，水龍頭出來的水有鐵鏽味。房東不修。

做法 A：認了，全家都喝鐵鏽味的水。
做法 B：在總管線裝一個濾水器。水源沒變，但進到屋子裡的水是乾淨的。

問題三：不改的話，下一個人會不會踩到？

如果會，那就算不改，也一定要留下標記。

而這帶到我們專案裡另一個更危險的東西。

一個會把使用者踢出系統的錯誤碼

Day 19 提過：新系統的錯誤處理裡，任何 API 回傳 code: -1，使用者就會被登出。

這個問題比拼錯的欄位名嚴重得多，因為它會造成實際的使用者困擾，你在填一張表單，按下送出，然後突然回到登入頁。

那為什麼不改？

回到問題一：這個約定的主人是後端的錯誤碼定義。要改它，得盤點所有 API 目前怎麼用 -1，然後跨團隊協調。

回到問題二：它會擴散嗎？ 不會——它只存在於請求層的一個判斷裡。

回到問題三：下一個人會不會踩到？ 會，而且一定會。

因為新來的後端工程師寫一支 API，需要回傳一個「參數錯誤」，他很自然會用 -1。然後前端的使用者就會被登出，而他完全不知道自己做了什麼。

所以我們做的是：把它寫進專案守則的地雷清單。

「寫進文件」不是敷衍，但也不是解決

我要誠實面對這件事：把地雷寫進文件，是一種有限的處理。

它的價值在於：當有人踩到的時候，他查得到。 這聽起來很低標，但對照「完全沒有記錄」，差別是「查十分鐘」和「查一整天」。

它的限制在於：文件不會主動找上你。 那個後端工程師在寫 API 的時候，不會先去讀前端的專案守則。

所以真正有效的處理應該是讓它會噴錯：例如在請求層加一個檢查，發現有 API 用 -1 表示非登入問題時，在開發環境印出明顯的警告。

我們沒有做這件事。 這是這篇最誠實的部分：我們止步於「寫下來」，而寫下來只擋得住讀過文件的人。

Day 15 講命名規範的時候，我說過「文件擋不住下一個人，只有會噴錯的東西才擋得住」。這裡我們自己犯了同一個錯。

第三類：工具產物

還有一類東西不能改，但性質完全不同：工具自動產生的檔案（Day 9 講過那個註冊了 388 個元件的型別宣告檔）。

它們套用同樣的三個問題會得到不同答案：主人是建置流程、不會擴散、而下一個人踩到的機率不高，因為這類檔案通常在開頭就寫著「此檔案為自動產生」。

所以這一類，寫進文件就夠了。不是每個地雷都需要同等級的處理，而分辨的方法就是問題三。

破窗效應，以及它的例外

有個常被引用的說法叫破窗效應：

一棟建築有一扇窗戶破了沒人修，很快就會有第二扇、第三扇，最後整棟樓被放棄。

這個比喻在程式碼上很成立——一個沒人清的死碼、一個大家都忍受的爛命名，會讓下一個人覺得「反正這裡本來就這樣」。

但我想補一句它常被忽略的部分：

有些窗戶不是你家的。

拼錯的欄位名、會登出的錯誤碼，主人都不是前端。你修不了它，硬修反而會弄壞更多東西。

而這種情況下，破窗效應真正的風險不是「窗戶破了」，是「別人以為你沒發現」。

所以差別在於：

• 破窗：一個沒人管、沒有記錄的問題 → 會傳染
• 刻意保留的疤：一個有記錄、有原因的問題 → 不會傳染，因為下一個人知道那是決定，不是疏忽

兩者在程式碼上長得一模一樣。差別只在有沒有那份文件。

代價

一、地雷清單會過期。 如果哪天後端真的改掉了那個錯誤碼，而沒有人更新文件，那份清單就開始說謊，而說謊的文件比沒有文件更糟。我們沒有機制確保它同步。

二、「隔離而非修正」需要紀律。 那個拼錯的欄位目前只有 6 次，但沒有任何機制阻止它變成 60 次。只要有人在業務程式碼裡直接用它，隔離就破了。

三、我們用「不是我們的所有權」當理由，可能有點太方便。 有些東西確實該去推動跨團隊修正，而「寫進地雷清單」是一個成本很低的替代方案。低到讓人不想去做那件對的事。

帶走什麼

1. 判斷該不該改，先問「這個東西的主人是誰」。 沒有所有權的東西，硬改的代價通常遠大於收益。
2. 改不掉的東西，至少可以隔離。 讓錯誤停在邊界，不要滲進業務程式碼。
3. 不改的東西一定要留下標記。 「破窗」和「刻意保留的疤」在程式碼上長得一樣，差別只在有沒有記錄。
4. 文件只擋得住讀過文件的人。 會造成實際傷害的地雷，應該要能噴錯，我們沒做到，這是實話。
5. 分清楚「原始碼」和「工具產物」。 後者看起來一模一樣，但改了會被覆蓋。

明天 Day 26 是模組五的最後一天，講一段我一開始完全誤讀的紀錄：有四個月，某個專案的開發量掉到近乎停擺。 我以為那是失敗，把四個專案的曲線並排之後才發現——那可能是整段重構裡最健康的一段。