圖像理解，對我來說比較自然
如果是電腦科學本科背景，資料結構與演算法大多是必修基礎；但對像我這樣，從生科系轉職成前端工程師的人來說，一開始就算沒有把這一塊補齊，好像也能開始寫程式、完成工作。只是工作一段時間後，我越來越明顯感覺到：很多實際遇到的問題，其實都和資料結構與演算法有關。
不一定是面試題，而是像：
- 為什麼某段程式在資料一多就變慢
- 為什麼這樣寫總覺得卡卡的，卻說不上來問題在哪
當我開始想認真把這一塊補起來時，卻發現學習過程本身對我來說並不輕鬆。直接看文字說明、數學公式或程式碼時，我需要花很多時間在腦中「自己補畫面」，而且常常會有一種很挫折的感覺：
每一行好像都看得懂，但合起來卻不知道整體到底在做什麼。
我分不清楚現在卡在哪一個步驟，也很難回想整個流程跑過一次後，狀態是怎麼變化的。
直到後來我慢慢注意到一件事：只要我真的理解了某個資料結構或演算法，腦袋裡幾乎一定會出現畫面。
那時我才意識到，也許問題是「理解方式」。
可能跟前端工程師的思考習慣有關
回頭想想自己的工作習慣，其實滿符合這個狀況的。在寫前端時，我通常會：
- 先看到設計稿
- 在腦中想像畫面結構
- 再思考 component 要怎麼切
- 資料要怎麼流動、狀態怎麼變化
我很少一開始就直接寫程式，而是需要先「看到東西長什麼樣子」。後來我發現，其實資料結構與演算法也是一樣的概念。只是它們是看不到的畫面。
Array 裡的元素怎麼排列、pointer 怎麼移動、資料在什麼時候被存進去、拿出來，如果腦中沒有畫面，就只能靠硬記，很快就會混在一起。但一旦畫面出現，理解會突然變得比較直覺，也比較容易記住。
我目前嘗試的學習方式
所以我決定用比較符合自己思考方式的方法，重新學資料結構與演算法，並把這個過程當成學習筆記記錄下來。目前我打算這樣嘗試：
- 先用圖像整理我對某個資料結構或演算法的理解
在還沒寫程式之前，先弄清楚：
- 結構大概長怎樣
- 每個元素或角色在做什麼 - 再對應 LeetCode Blind 75 裡的相關題目
解題時，會先用圖像把流程拆開，對我來說，這有點像是「視覺化的 pseudocode」讓我知道每一步為什麼要這樣做。 - 最後再用 TypeScript 把畫面轉成程式碼
同時記下我目前對時間複雜度與空間複雜度的理解，不追求完整推導，而是先回答：這樣寫為什麼比較快？代價是什麼？
這些內容都只是我目前學到、想通的方式，之後如果理解有變，也會隨著學習更新。
這系列筆記比較適合誰
這個系列不是完整教學，也不是標準答案，比較像是我在補資料結構與演算法時，把卡住的地方、畫過的圖、想通的過程記錄下來。如果你：
- 不是資訊本科背景
- 看得懂程式碼，但很難在腦中串起整個流程
- 需要先「看到畫面」才比較好理解
也許這些學習筆記能陪你一起走這段路。
