以前的我只在乎「功能做不做得出來」，但隨著專案越來越大，我開始發現，「做得出來」好像不等於「寫得好」。

身為一名前端工程師，我最近一直在思考一個問題：

「演算法跟前端到底有什麼關係？」

以前看到「演算法」這三個字，我總覺得它比較像是後端在處理大量資料時需要考慮的東西，或是應用在 AI、機器學習等領域，感覺離前端有一段距離。

畢竟平常前端開發，好像也不太需要自己實作什麼演算法。

想從資料中找到符合條件的使用者，可以用 find；想篩選資料，可以用 filter；想轉換 API 回傳的資料，可以用 map；甚至要排序，JavaScript 本身就已經提供了 sort。

既然這些工具都已經準備好了：

那前端工程師為什麼還需要學演算法？

直到開始接觸比較大的專案後，我才慢慢發現，也許真正的問題不只是：

「這個功能做不做得出來？」

而是：

「當資料越來越多、問題越來越複雜時，我現在的解法還適合嗎？」

例如同樣是排序資料，不同的方法可能會有不同的效率。

又或者今天不是單純找一筆資料，而是要從很多節點與路徑中，找出從起點到終點的最短路線，這時問題就不再只是靠一個 find 就能解決。

這讓我開始意識到，學演算法也許不是為了取代 find、filter 或 sort，而是讓自己在遇到不同問題時，知道還有哪些解決方式可以選擇。

這也是為什麼，我決定利用這次鐵人賽，挑戰一個自己過去一直不太熟悉的領域——演算法。

比起單純看書或刷題，我希望用自己比較熟悉的 Vue，做一個「演算法互動視覺化平台」，把原本只存在程式碼裡的執行過程，實際呈現在畫面上。

這 30 天，我想做什麼？

目前預計實作三種演算法：

• Bubble Sort（氣泡排序）
• Quick Sort（快速排序）
• Dijkstra Algorithm（最短路徑演算法）

我不想只是把演算法的程式碼寫出來，而是希望把排序時的「比較」、「交換」，以及 Dijkstra 尋找最短路徑的過程，實際呈現在畫面上。

也希望透過這 30 天，慢慢回答一開始的那個問題：

「演算法，究竟能為前端帶來什麼？」