比起 UX，你更該先重視 DX

序

大家常說產品要以使用者體驗（UX）為中心，沒錯 UX 的確是產品成功的關鍵之一。但對於每天在專案裡打滾的開發者來說，有一件事往往被嚴重低估了：開發者體驗（DX, Developer Experience）。

如果一個專案架構夠順手，工具鏈乾淨俐落，功能開發自然能事半功倍；反之，如果你被困在 legacy 環境裡，情況就完全不同了。

Legacy 環境的痛點

在一個老舊架構下，就算只是新增一個很小的功能，都可能耗掉你好幾倍的時間：

• 編譯時間動不動就要五分鐘起跳，還要邊等邊泡咖啡
• 改了一段小邏輯，心裡卻要掛念「啊看，這樣改那邊會不會爆掉」
• Side effect 排查比開發還久，Debug 的時間永遠超過實際 Coding

結果就是，你根本沒辦法專心解決「產品」問題，因為大半時間都在跟「環境」搏鬥。

很多團隊都抱著「能動就好」的心態，但這樣其實很危險。當時間許可，或是你已經被開發上的小毛病搞得毛毛躁躁，就該好好想想——是不是該把底層梳理一下了？因為「能動」只是一時的，長遠下來反而是消耗士氣的來源。

這也是為什麼我很喜歡看新技術、新框架的趨勢發展，如果有適合的工具就想馬上裝來玩，因為只有開發體驗夠好，才有餘裕去顧 UX。

🌰

舉個實際的例子。

過去我在一個基於 Webpack 的前端專案上工作，冷啟動時間動不動就要 3-5 分鐘。這對產品端的使用者來說沒差，反正他們只看到最後產出的網頁。但對開發者來說，每次要等幾分鐘才能跑起來，更別說每次存檔還要等上 5-10 秒畫面才會刷新，等到天荒地老，工作效率完全被拖垮。

所以我開始「兼職」重構底層，在不影響原本工作排程的前提下，斷斷續續花了兩年，把 Webpack 架構從 v4 升級到 v5，然後再整組換成 Vite。完工後冷啟動時間直接縮到 5 秒以內。

這種優化對產品終端使用者來說，可能完全無感，對公司而言甚至還可能被說毫無價值浪費時間，但對開發者卻是翻天覆地的差別。因為這直接決定你每天能不能順順利利進入「開發心流」，還是被卡在工具上消磨耐性。

延伸閱讀：Webpack@4/Vue-cli@4 優化之路 (後篇 webpack -> Vite つづく...)

There's ALWAYS a better way

最後我想強調一個觀念：優化永遠不嫌晚。

今天你覺得「啊，太晚了，專案都這麼老了，不可能再動了吧」，但事實上，只要第一步踏出去，時間花得再久都有完成的一天。

就像我五年前曾經想過要把一個始祖巨人級的專案 (gulp + jQuery + mustaches) 徹底翻掉，如果當時就算一個人慢慢改、不影響主線開發，現在早就完成了。結果因為上層一再的否定，就是抱持著「東西能動就好不要花這個時間」，直到今天做一個小功能還是要小心翼翼，處處怕踩雷，更別說還有多少需求是因為整個專案基礎越蓋越歪而衍伸出來的 bug。

所以別小看這些基礎建設的優化。因為明天要改的東西只會比今天多。現在不做，未來只會更痛。

結語

UX 讓使用者開心，DX 讓開發者能活得下去。

而當 DX 好了，開發者才有餘力把 UX 做好，降低開發成本對於團隊，甚至公司絕對是百利無害，端看於你們願意投入多少心思在看待 DX 這件事，就看我的例子而言，這件事是可以不影響到原本的工作流程的情況下慢慢同步進行的，但如果打從一開始團隊就沒有這個觀念的話，逐漸累積的開發成本終究會影響整個團隊。

Btw, 愛護開發，從遠離 React 開始 🙈