很長一段時間以來,我一直認為網站開發很簡單。
前端。
後端。
完畢。
一邊是HTML、CSS、JavaScript。
另一方面是 API、資料庫和 Node.js。
如果我能將資料從後端移動到使用者介面,我就認為自己是在「進行網頁開發」。
所以我專注於功能方面。
路線。
成分。
端點。
然而,不知為何……我的專案總感覺沒有完成。
我花了很長時間才明白這個簡單的道理:
Web開發不僅僅是前端和後端。
它涵蓋了介於兩者之間的一切。

我們從小就被教導要把事物清晰地分割開來:
前端 → 使用者所看到的
後端 → 伺服器做什麼
這個模型可以幫助我們起步。
但這也悄悄限制了我們的成長。
因為真正的 Web 應用程式失敗並非僅僅因為程式碼糟糕。
他們失敗的原因是:
糟糕的使用者體驗決策
未處理的邊界情況
效能瓶頸
無障礙差距
部署意外
團隊溝通障礙
它們都不是只存在於前端或後端。
他們生活在體制之中。
曾經有一段時間,我的應用程式在技術上是可以正常運作的。
按鈕被點擊了。
API已回應。
資料顯示出來了。
但總覺得哪裡不對勁。
頁面載入速度很慢,因為我沒有優化圖片或快取回應。
表格填寫起來很麻煩,因為只有在提交後才會進行驗證。
這些錯誤在技術上是正確的,但對使用者來說卻不清楚。
程式碼沒有出錯。
這段經歷…
那時我才意識到:
提供產品功能只是工作的一部分。
設計行為是另一半。
讓網站感覺良好的大部分因素都是看不見的。
例如:
有意義的載入狀態
提供指導而非指責的錯誤訊息
真正好用的鍵盤導航
適當的色彩對比度
合理的預設設定
簡潔易讀的URL
深思熟慮的空虛狀態
小的效能最佳化(例如避免不必要的重新渲染或過大的打包大小)
沒有任何框架會自動提供這些功能。
你來選擇。
而且這些選擇會疊加起來。
即使在後端,也不僅僅是:
“到此為止。完成了。”
它是:
錯誤處理方式
日誌是否結構化且有用
不同環境下的配置有何差異
如何驗證輸入
你的預設有多安全?
例如,從技術上講,這樣做是可行的:
app.get('/users', async (req, res) => {
const users = await db.getUsers();
res.json(users);
});
但如果資料庫故障怎麼辦?
一個更精心設計的版本:
app.get('/users', async (req, res) => {
try {
const users = await db.getUsers();
res.json(users);
} catch (err) {
logger.error(err);
res.status(500).json({ message: "Something went wrong" });
}
});
功能相同。
責任等級不同。
Node.js 讓快速啟動專案變得輕而易舉。
但是,應用程式的結構和保護方式決定了它能否平穩擴展……還是擴展起來會非常痛苦。
後端是行為,而不僅僅是邏輯。
大多數教程都只展示了順利的過程。
他們很少露面:
API 故障時會發生什麼
使用者在慢速網路上看到的畫面
使用者介面實際易用性如何
六個月後程式碼的可讀性如何?
其他人貢獻有多容易
但這些正是團隊在實際專案中難以解決的部分。
正是在這裡,Web 開發開始感覺更接近軟體工程,而不僅僅是編寫程式碼。
在某個時刻,情況發生了變化。
你別再問了:
“這樣行得通嗎?”
然後開始提問:
這樣說可以理解嗎?
這樣方便使用嗎?
這樣可行嗎?
這在意料之中嗎?
這樣對使用者友善嗎?
這樣對未來的我好嗎?
這種思維方式適用於任何地方:
前端。
後端。
Node.js 服務。
建置工具。
部署管道。
一切都是相互關聯的。
這就是全端開發的真實感受,不僅要了解雙方,還要從系統的角度思考問題。
諷刺的是,當你不再專注於工具,而是開始專注於系統時,成長反而會加速。
你不需要一次掌握所有東西。
你只需要留意一下你過去忽略的事物。
一次只改進一個小方面:
更清晰的使用者介面決策
更安全的後端邏輯
更好的預設設定
對用戶多一些同理心
對隊友更有同理心
專案就是這樣開始感覺完成了。
❌ 前端只是「使用者介面」而已
❌ 後端“只是邏輯”
❌ 框架才是難點所在
❌ 出貨快並不等於出貨好。
Web開發並非簡單地堆砌技術。
關鍵在於將各項決策連結起來。
如果你的專案運作正常但感覺不對勁,那可能並非是你缺乏技能。
你缺乏全局觀。
Web開發不僅僅是前端和後端。
它關乎體驗、性能、易用性、可靠性,以及那些無人稱讚卻人人都能感受到的細微之處。
多花點心思。
思考得比實際需要的更深一層。
優秀的開發者就是在這裡成長為卓越的開發者的。
祝福各位朋友在網站開發之旅中思路清晰、信心滿滿。 💙