昨天決定開始學習演算法之後，我第一個遇到的問題不是「哪個演算法比較快」，而是一個更基本的問題：

「所以，演算法到底是什麼？」

身為前端工程師，我們平常其實一直都在處理各種問題，例如搜尋資料、篩選商品、排序列表、驗證表單。

這些功能背後都有一件共同的事情：

「資料進來之後，要經過哪些處理，才能得到我想要的結果？」

這也成為我開始理解演算法的一個切入點。

先不要想程式，從「煮泡麵」開始

假設今天肚子餓了，想煮一碗泡麵。

手上已經有泡麵、水和調味料，接下來可能會經過：

準備材料 → 把水煮滾 → 放入泡麵 → 加入調味料 → 煮熟 → 得到一碗泡麵

如果把這個過程拆開來看：

Input（泡麵、水、調味料） → Algorithm（煮水 → 放入泡麵 → 加入調味料 → 煮熟） → Output（一碗煮好的泡麵）

所以我目前會把 Algorithm 理解成：

為了解決某個問題，而設計出來的一系列明確、可執行的步驟。

也可以再整理成：

Problem（要解決什麼？） → Input（有哪些資料？） → Algorithm（經過哪些步驟？） → Output（得到什麼結果？）

只要有步驟，就叫做演算法嗎？

查資料之後才發現，並不是隨便列出幾個步驟就能稱為演算法，通常還會提到幾個基本特性：

• 明確性（Definiteness）：每個步驟都要清楚明確。
• 有限性（Finiteness）：經過有限步驟後必須結束。
• 有效性（Effectiveness）：每個步驟都必須實際可執行。

用泡麵來說，「把水弄熱一點」就不夠明確；「一直煮下去」沒有結束；「用魔法瞬間變出泡麵」則不是實際可執行的步驟。

所以演算法不只是「有步驟」，這些步驟還必須明確、有限，而且可以執行。

再回頭看看前端開發

例如平常的商品搜尋，也可以用同樣的方式理解：

Problem（找到符合關鍵字的商品） → Input（關鍵字 "Mac" ＋ 商品資料） → Algorithm（根據搜尋規則找出符合資料） → Output（符合條件的商品）

當然，這不代表每一段搜尋邏輯都要稱為某個經典演算法，而是讓我開始用另一種方式思考：

「我有什麼資料？要解決什麼問題？中間要經過哪些步驟？」

那為什麼還要特別學演算法？

因為同一個問題，可能有不同的解決方式。

就像台北到高雄，可以搭高鐵、火車或開車，都能到達目的地，但花費的時間與資源不同。

演算法也是如此。

當資料量變大，不同解法之間的差異也可能越來越明顯。

所以接下來除了學習「怎麼解決問題」，我也想開始理解：

「同一個問題有哪些解法？不同解法之間又有什麼差別？」

後面的 Algorithm Visualizer，我會透過 Bubble Sort、Quick Sort、Dijkstra 三個演算法慢慢把這些概念實際做出來。

參考資料

1. AppWorks School，〈初學者學演算法：談什麼是演算法和時間複雜度〉
   https://medium.com/appworks-school/初學者學演算法-談什麼是演算法和時間複雜度-b1f6908e4b80

2. INSIDE，〈什麼是演算法？〉
   https://www.inside.com.tw/article/31621-what-is-algorithm