除非對專案已經有非常深入的了解，否則重構、重寫通常是搞垮專案的開始。

之前曾與同事討論過 ByteByteGo，一方面對於 ByteByteGo 深入淺出的系統設計科普感到佩服；一方面覺得只把最後系統設計的架構拋出來，忽略系統設計是一步步演進的結果，以及系統的演進、背景因素，導致很多工程師只要看到架構中有不符最佳實踐的地方，就想整個砍掉重練。在不了解歷史背景的狀況下，很容易翻車。

那麼既然重構不行，那該怎麼下手才好呢？在開發過多個專案後我有一套流程分享：

• 從 API 介面下手，補齊文件如 Request body；回應格式與狀態碼有哪些
• 導入可提高信心的測試：如 E2E 測試；整合測試等
• 拆分共同模組：將商業邏輯搬到 Service 明確職責
• 到了這個階段才開始考慮重構

主要原因是直接重構而不考慮現有規格的情況下，重構往往是邁向地獄的開始。開發者想要寫出「好看」的程式碼，可能忽略掉歷史背景的程式碼。而撰寫文件、釐清現有邏輯、導入測試正是確保規格的關鍵，把這些基底都鋪好之後，重構起來才會事半功倍。

在實務上比較困難的是，如何說服上層重構是一個具有商業價值策略。就如同之前的文章提到的，大家看到的風景不一樣，而重構往往是上層無法理解且常被認為很花時間的改善。

可以從幾個方向下手：

1. 提出具體的規劃與方案，讓上層知道這不是自我感覺良好或完美主義作祟而已，而是真的想解決問題
2. 數據化：例如重構帶來的開發效益提升、團隊士氣
3. 明確的檢查點與時程：如果是願意聽話的上層。通常拿得出方案與足夠的準備，只要對產品有幫助都願意支持
4. 負責：重構或多或少也代表著風險，畢竟需要改變以往的寫法。這通常會帶來陣痛期，例如 Bug 回報較多，對寫法不熟悉需要教育團隊（補齊文件、訓練等等）。這時最忌諱的就是英雄主義式的大幅重寫程式碼，但不對結果負責

如果第一個想法是重寫、重構，可能只是想得還不夠多而已