透過已知的障礙、自由及目的，便可以在人生的各種遊戲玩得更好

句話深刻地呼應了本文的主題。它提醒我們，一旦我們深入瞭解各種障礙——無論是制度的限制、社會規範還是其他規則，並掌握其中隱含的自由—即可採取的各種行動和選項，再明確的最終目的下，我們就能在任何情境（或稱之為遊戲）中更為出色地表現。

回顧 Day25

在 Day25 的分享中，我提到公司產品面臨一些品質挑戰。為了解決這些問題，我採用了同時進行需求開發和程式碼重構的策略，以逐步提升軟體品質。然而，某些問題仍未能全面解決。接著，我們遭遇了一個特別的需求，該需求直接觸及到 React，或更廣義地說，是單頁應用（SPA）的固有局限。這為我提供了一個絕佳的機會，以全面優化該產品。以下將詳細介紹這個過程。

那個需求

前因後果

根據資料，每天都有成千上萬的視訊診療需求。隨著新冠疫情從最初的每日幾百例確診暴增至數千例，僅依靠醫生的實體診療已經變得不切實際。因此，政府要求利用我們的平台進行視訊確診，導致我們的系統流量急劇上升，有時候甚至達到五位數的診療量。

隨著疫情惡化，我們產品需要實現的功能也日益增多。我們逐步完善了這些功能，伴隨著系統變得更加完善和流量的大幅增長，醫生們的需求也從最初對系統完整性的要求轉向了性能優化。

提出需求

某一天，主管向我傳達了用戶反饋的一個問題：「在諮詢列表頁面載入時，會停留在白色的畫面狀態一段較長時間，才能顯示相關資料。」經過分析，我發現這個問題主要出現在資料量大的特定頁面上。原因在於我們系統之前被前人設計是一次性拉取所有資料，這在資料量增大後導致讀取時間過長，儘管後端已進行過某程度的優化。

另外一點是，當我進一步了解用戶操作行為後，我發現他們在首次開啟網站的特定頁面時，由於需要載入 React 等資源，必然會經歷一段白畫面的時間。這個白畫面與前述的大量資料讀取問題相結合，導致整體用戶體驗下降。

解決策略與實施

問題診斷與方案提出

在初步分析後，我迅速地向主管指出這應該是單頁應用（SPA）的固有限制。在 SPA 架構中，用戶必須首先下載一大批JavaScript 資源，然後才能進入應用界面和進行呼叫 API 獲取資料。

不過幸運的是，React 提供了 React.lazy 和 Suspense 機制，這允許我們對資源進行更細粒度的分割和延遲加載。這可能會有助於加速應用的初始加載時間。

最初，我誤以為這些功能是在 React 17 版本才引入的，因此我們計劃進行版本升級。事實上，這些功能早在 React 16.6 版本就已經提供。不過，升級仍具有其他好處，例如新版本的熱重載（Hot Reload）機制，這將使開發過程更加流暢。有這個功能我們開發就可以更加順暢容易，因為他只會修改我們更動的部分，而不是像 React 16 那樣會整個畫面加載，這點我在 Day17的產品問題點 有稍微談過。

對於問題點的結論

後來我也跟主管以及資深工程師提出，既然要做就應該做得徹底點。我們都同意，也差不多是時候該讓整個專案大變身了，所以我就被予以以下任務：

1. 從 React 16 升級到 React 18
2. 在專案中實施 pre-commit 檢查
3. 用 Airbnb 的 Eslint 規則替換前任工程師自定義的 Eslint 規則
4. 將專案的 Tab 空白由四格改為兩格
5. 調整與新 Eslint 設定相關的代碼
6. 實現 React.lazy 和 Suspense
7. 優化用戶體驗，特別是減少白屏時間

另外，我個人還計劃升級一些過時或舊版的工具庫，畢竟最終負責這個產品開發的還是我。

實作過程

根據我習慣的工作流程，我習慣先將不同的功能和需求進行區分。因此，我決定：

1. 首先完成版本升級。
2. 之後著手於實現 React lazy 與 Suspense 功能。

我隨即建立了一個專門用於版本升級的分支（branch），並開始按照下列分階段策略進行實施：

1. 更新 React、React-dom 等相關套件，並修復出現的錯誤。
2. 更新 Eslint 並切換至 Airbnb 的規則集。
3. 安裝 pre-commit 工具，如 prettier、husky 和 lint-stage 等。
4. 更新其他次要的工具庫。
5. 檢查各工具庫版本間是否存在衝突。

儘管只有數個主要步驟，但在過程中我遇到了諸多挑戰，特別是在更新 Eslint 規則時。以下是一些主要的問題點：

• 邏輯調整：先前的開發者經常使用 for 迴圈，這在 Airbnb 的規則中是不被允許的。因此，我對大量的程式碼進行了邏輯上的修改。對於較為複雜的邏輯，我在 commit 中加入備註，表示將來需進一步修正。

• Props-type 補全：由於先前的開發並未嚴格遵守 props-type 的規定，我也投入不少時間來補全這部分，並仔細審查相關邏輯以確定正確的資料型態。

• 其他錯誤修正：總計約有三百到五百個錯誤，我逐一進行了修復。

儘管挑戰重重，整個版本升級過程在短短三天內就得以成功完成。這也是我首次將產品升級至具有 pre-commit 功能的版本，進一步證明了我有能力妥善處理這類升級問題。回想當初轉行學習時，面對 Eslint 的錯誤曾讓我感到困惑，但現在我能自信地解決這些問題。

整體來說，這次升級為專案帶來了質的提升，儘管還有許多前人遺留下來的問題尚未完全解決。考慮到企業營運壓力，不可能一一修正所有細微問題，但至少我已經將這個專案提升到一個相對優質的水平。

最終結果

解決通點

包括先前已經重構過的部分，這次的重構觸及了約 99% 的程式碼。這樣的全面性改動為未來的開發鋪平了道路：我們可以更符合慣例地進行開發，並且在升級至 React 18 以後，利用其 hot reload 特性，免去了每次程式更改後全面重新加載界面的需要。

自動排版的引入也極大地提升了開發者體驗（DX），讓我們不必過度關注程式碼的格式。

值得一提的是，原計劃在升級後實現 React 的 lazy 和 Suspense 功能。但由於緊急需求，先暫緩了，而之後客戶也不再反饋有這樣的問題，所以這個部分暫時擱置。我推測這或許與 React 新版本中做了一些優化有關，這可能解釋了客戶不再抱怨界面加載速度慢的問題。

尚待解決的挑戰

• 某些複雜的 for 循環邏輯尚未處理，將在未來有相應開發需求時進行優化。
• 視訊系統的邏輯過於複雜，目前還沒有找到合適的解決方案。
• 其他尚未解決的問題也將按照開發需求逐一進行重構。

結語

透過長期的努力和經驗累積，我成功地證明自己有能力將一個產品引領至更好的階段，這充分展示了我一直熱衷於「優化」的特質。我感到非常自豪，不僅因為我進行了有效的重構，讓後續維護更為便利，還因為我提升了產品在 UI、UX 和 DX 方面的表現。

這個產品目前依然服務著既有的客戶群，而隨著公司業務的擴展，我們也計劃將這些成功經驗應用到新的產品線上。

在下一篇文章，我將分享面對新產品開發所帶來的各種挑戰。

希望你會喜歡這篇文章，謝謝你的觀看。

文章就說到這，有什麼想法或問題，歡迎隨時找我聊聊！

這篇文章也會同步發在 medium 上，如果有興趣歡迎追蹤我。

medium: https://medium.com/@hugh-program-learning-diary-js
email: u88803494@gmail.com