斷捨離的一天

今天整個上午的時間，我幾乎都在跟自己寫的程式碼搏鬥。昨天 OAuth 解除綁定的邏輯處理到一半，於是今天早上第一件事就是專心處理 OAuth 的部分，其實也沒想像中的難，各個情境的路線都弄好就好了。

接著回頭處理 Navbar 組件的效能問題，昨天 Clarity session 裡看到一些用戶點擊時會有卡頓感。結果一打開原始碼才發現，先前為了 debug 臨時加了一堆 console.log，居然忘記清掉了，難怪效能會掉。順手把這些 log 清掉之後，順便把事件處理函數全部改成用 useCallback 包起來，避免每次重新渲染都生成新的函數實例。這個小地方雖然看起來不起眼，但實際效能提升還蠻明顯的，尤其在移動裝置上，點擊反應明顯順暢了不少（再次感嘆 React 的坑真的很多）。

下午重拾昨天 OAuth 帳號解除綁定流程的戰場，原本的設計是用戶在前端點擊解除綁定後，前端還會再拿一次 Google access token 丟給後端 API 做 revoke。後來仔細想想，這樣做其實沒什麼意義。因為我們已經在 AuthProvider 處理了 OAuth 狀態，額外去 revoke 一個本來就會過期的 token，只是徒增 API complexity 跟錯誤處理的負擔而已。於是果斷把這段邏輯整個拔掉，改由 AuthProvider 單一處理 OAuth 標記更新，前端只需要處理 UI 狀態跟提示訊息即可。這樣做的好處不只是程式碼更乾淨，連用戶操作時的延遲感也減少了，整個流程變得更加流暢自然。

但就在我覺得一切都順利的時候，帳號刪除流程又冒出了一個意想不到的問題：我們原本的設計是讓用戶輸入密碼確認刪除帳號，但對 OAuth 帳號來說根本沒有密碼，這樣的設計完全不合理。當初怎麼會沒想到這點呢 🤦‍♂️？思考了一下後，我決定乾脆把密碼確認拿掉，改成靜默獲取 Google token 驗證一次 OAuth 身份就好。這樣整個刪除流程變得簡單多了，用戶也不需要記住莫名其妙的密碼（畢竟他們根本沒設定過啊！），整個帳號刪除流程也因此更加直覺。

說到這裡，突然想到昨天 UI 提示的問題，今天也順便調整了一下解除綁定按鈕的 HTML 結構，從原本 React 的 onClick 處理改成原生的 form submit，這樣鍵盤操作跟無障礙使用性都會比較好一點。雖然只是小小的調整，但這種細節在產品成熟後期反而會變得特別重要（至少我自己是這麼說服自己的啦）。

今天這樣一路刪刪改改，雖然 commit 記錄看起來都是在移除東西，但我反而覺得比起新增功能，這種把東西拿掉的過程更需要勇氣跟判斷力。做產品到現在，我越來越覺得最難的不是寫出功能，而是判斷哪些東西該留下，哪些應該拿掉。畢竟每一行程式碼的背後，都是當初自己的心血與期待。放手的瞬間，總是有點掙扎，但最終留下來的，才是真正重要且有價值的東西吧。