在學習程式的過程中，經常聽到一句話「別重複造輪子。」因為這樣能夠把時間、力氣留給真正值得煩惱的問題。別人寫過、驗證過的邏輯，通常比自己埋首苦幹半天寫出來的更快、更穩定、更周全。

若是從追求開發效率的角度來看，這句話我不否認；但若從學習的角度，我持懷疑態度。懷疑，並非是自認有把輪子做得更好的能力；而是，我相信能從造輪子的過程中獲得啟發。

從亞里斯多德《詩學》看「再造輪子」

「模仿」(Mimesis)，在希臘哲學家亞里斯多德《詩學》裡是個重要概念，即使這本著作旨在談論藝術，但若把它放在軟體開發上，也許能提供一種看待「再造輪子」的不同視角。

亞里斯多德認為，模仿是人類天生就有的自然行為，我們從出生起便藉著模仿的本能來學習。但是，模仿的終點並非也不該止於機械複製，而是在反覆描摹中，把肉眼看不見的結構、邏輯勾勒出來，一點一點地提煉成屬於自己的理解。

學過畫、練過字的人多半能夠體會這種感覺：從一開始臨摹得歪七扭八，經歷反覆磨練之後，當筆下的東西忽然不再是照本宣科，從而變成了自己的筆觸 —— 這就是模仿的精髓。

從觀察、理解，再到創造，我覺得這就是學習的本質；事實上，在我眼裡，學習程式也是如此。

不過，在 AI 蓬勃發展的現代，撰寫程式碼是其中一項 AI 最擅長的能力。程式碼本身也因而變得廉價了嗎？

「AI 時代，程式基礎比以往更有價值」

我想分享先前在 YouTube 看到的一個觀點，來自 Total TypeScript 作者、AI Hero 創辦人 Matt Pocock。他曾是 XState 核心團隊成員，也在 Vercel 擔任開發者關係 (Developer Advocate)，參與過 Turbopack 的發表，是 TypeScript 社群最具聲望的導師之一。他認為，程式碼並不廉價。糟糕的程式碼，反而才是這個時代最大的負債。

正因如此，在 AI 時代，程式基礎比以往都更加重要。Matt 的論述在於，堅實的程式基礎能讓 AI 寫出高品質的程式碼，而讓 AI 在高品質的程式碼中工作，才是最大化 AI 能力的關鍵。

所以 Matt Pocock 從《The Pragmatic Programmer》、《A Philosophy of Software Design》等經典書籍取經，透過觀察 AI 代理撰寫程式碼的模式與自身經驗的衝突，設計一套屬於自己的 Claude Code Skill 工作流，並且大方開源（截至 2026 年 9 月中查核，已累積超過 26 萬顆星）。

而我想說的是，這件事本身就是一次臨摹。他描摹的對象，是那些經典書籍裡的設計原則；描摹的方式，是讓它們在自己每天的工作裡反覆受檢驗、反覆被修正。最後留下來的，不是書上的句子，而是一套屬於他自己的判斷。

亞里斯多德說的那個過程，在 2026 年的工程現場又發生了一次，只是這一回，臨摹的不是筆觸，是設計的判斷。

為什麼選擇這個主題，以及對系列的期許

之所以會選擇 React Hook 函式庫來著手，以下是我考量的原因與期許：

• 客製化 Hook 能夠結合內建的各種 React Hook，將複雜、可重用的邏輯從元件裡抽離，是現代 React 設計模式、提升程式碼品質的基礎；
• 同一個設計問題，社群往往不只給出一種答案，而每一種都被大量真實專案驗證過 —— 這是現成的、能彼此對照的設計樣本，數量之多、品質之高，在其他領域並不容易找到；
• 當然，倘若真能埋下激發任何想像的火花，或是有任何未來貢獻社群的可能性就好了 😌

至於為什麼是「臨摹」，而不是把原始碼讀過一遍就好？這正是第一天要回答的問題。

最後我還是得為自己打劑預防針。老實說，我將在摸索中執行這個系列，並沒有十足把握能走完這趟旅程。

但沒把握走完，不代表不知道要走去哪。這三十天，我會挑六個 React 開發者每天都會碰到的設計問題：遠端來的資料是誰的？共享狀態變了，哪些人該知道？每次擊鍵，誰該被通知？瀏覽器 API 到底該包多厚？互動行為怎麼交給你、卻不決定你的 DOM？真實的 DOM 又該由誰負責？每一個問題，我都會找幾個成熟的函式庫當作不同的答案，寫出最小的臨摹實作，再問那一句：為什麼它們選得不一樣？

無論能否堅持到最後，喜歡探究的心是不會變的，如果你跟我一樣，邀請你加入我的旅程，在這 30 天中，暫時放下「別重造輪子」這句話，一起探索這些輪子的背後，到底埋藏多少社群前輩的智慧吧！