這是我第一次挑戰 iThome 鐵人賽。
在正式開始分享 PawPal 這個專案之前，我想先從自己開始說起。
我不是本科系出身，也不是一開始就很會寫程式的人。
甚至在學前端的過程中，我曾經有一段時間真的很想放棄。
以前的我，從來沒有想過，只是在鍵盤上敲出一串英文字，就可以加入邏輯，讓畫面產生互動。
甚至完成一個真的能使用的功能。
一開始看到朋友在寫後端專案時，我覺得很神奇。
原來程式不是只有黑黑的畫面和看不懂的指令，它可以把想法變成功能，也可以解決真實的需求。
但真正開始學之後，我才發現事情沒有想像中簡單。
程式不是照著範例打就好，也不是把語法背起來就會。
很多時候更難的是：我到底為什麼要這樣寫？這個邏輯是怎麼跑的？不同需求為什麼會有不同的寫法？
這些問題，在我剛開始學前端時，常常讓我卡很久。
在學前端之前，我過去主要是在餐飲業工作，也曾經擔任餐廳副理。
那時候的工作內容，和寫程式看起來完全不同。
我需要負責門市營運、人員安排、跨部門協調，也要處理現場突然發生的狀況。
這些經驗讓我養成了責任感、執行力，也學會在不同任務之間安排優先順序。
遇到問題時，我會先確認目標，再一步一步拆解該怎麼處理。
只是當我開始學程式時，我才發現，這些能力雖然有幫助，但不代表我可以很快理解程式。
因為對非本科系的我來說，前端幾乎是一個全新的世界。
HTML、CSS、JavaScript、Vue、API、Git……
每一個名詞都像是新的語言。
我就像一張白紙，一邊學，一邊慢慢建立自己對前端的理解。
學習前期，最讓我挫折的是 JavaScript。
JavaScript 對我來說，不只是語法難，而是它有很強的銜接關係。
只要前面一個觀念沒有跟上，後面就會整個斷掉。
有時候老師已經在講下一段邏輯了，但我還停在上一段程式碼，不知道為什麼要這樣寫，也不知道資料到底是怎麼變化的。
那種感覺其實很挫敗。
尤其當同學好像都能跟上，而我需要花很長的時間才能理解一段程式碼時，我會開始懷疑自己是不是不適合寫程式。
課程前期，我真的有一度想退出。
那時候心裡很常出現一個聲音：
「是不是我太慢了？」
「是不是我根本學不起來？」
「是不是現在放棄比較好？」
但後來我還是告訴自己，至少再撐一下。
不要這麼快否定自己。
也不要還沒真的做過專案，就先放棄。
現在回頭看，還好那時候有撐下來。
真正讓我開始感受到寫程式的樂趣，是後期進入團隊專案之後。
我們的專案叫做 PawPal，是一個和寵物照護相關的平台。
這也是我人生中第一個真正參與的團隊專案。
在 PawPal 裡，我印象最深、也最有成就感的，是寵物資料功能。
那時候我負責寵物資料的 CRUD，從零開始處理新增、讀取、修改、刪除。
這個功能後面我會用好幾篇文章慢慢拆開來寫，因為它幾乎是我第一次真正把前端、後端、API 和資料庫串在一起的經驗。
它不只是畫面上的表單而已。
還包含資料怎麼送到後端、後端怎麼處理、資料庫怎麼存，最後又怎麼回到畫面上。
一開始我也不是真的全部都懂。
很多時候是邊做、邊問、邊查，也會使用 AI 協助自己理解問題、拆解功能，或是在卡住時參考它給的寫法，再回頭慢慢看它到底在做什麼。
但當我真的成功建立第一筆寵物資料，而且那筆資料是自己心愛的寵物時，那種感覺很不一樣。
它不再只是課堂上的練習題。
而是我真的做出一個功能，讓使用者可以新增一筆資料，讓畫面有反應，讓資料被保存下來。
那一刻，我第一次很明確地感受到：
原來寫程式真的可以把一個想法，慢慢做成一個可以使用的東西。
那種成就感，真的滿出來。
坦白說，在 PawPal 專案裡，我也曾經很常使用 AI 協助自己理解問題、拆解功能，甚至在卡住時參考它給的寫法。
但我後來也發現，AI 可以幫我走過當下的卡關，卻不能替我真正理解整個專案。
有些程式碼當下可以跑，功能也做出來了。
可是如果要我完整說明為什麼這樣寫、每一段在做什麼、組員寫的部分又是怎麼串起來的，我其實沒有那麼有把握。
尤其專案開發的時間很短，大概一個多月內要完成很多功能。
在那樣的節奏下，很多時候會先想辦法把功能做出來，再慢慢補理解。
所以我想透過這次鐵人賽，重新整理 PawPal 這個專案。
不是只是把功能列出來，而是回頭問自己：
這個功能當時為什麼要做？
我那時候卡在哪裡？
我後來怎麼理解？
它背後其實牽涉到什麼前端觀念？
如果重新做一次，我會怎麼處理？
我希望透過 30 天，把這個人生中第一個團隊專案好好記錄下來。
同時，也練習用自己的話，把程式邏輯和專案經驗說清楚。
這個系列不會是單純的 JavaScript 語法教學。
我不會從「今天介紹變數」、「明天介紹陣列方法」這樣一路寫下去。
因為對我來說，真正讓我理解程式的，不是單獨背某個語法。
而是在專案裡遇到問題時，才突然知道：
原來這個觀念是用在這裡。
所以這 30 天，我會用 PawPal 的真實開發故事當主線。
每一篇會從一個功能、一次卡關、一次 Debug、一次協作，或一次部署經驗開始，再回頭整理它背後牽涉到的技術。
這些技術可能包含：
也就是這個系列的核心：
「真實開發故事 × PawPal × JavaScript 回扣」
我希望它不是一份很完整、很權威的技術文件，而是一份真實的新手學習紀錄。
因為我自己是程式新手，所以我很清楚新手卡住的感覺。
有時候不是不努力，而是真的需要更多時間理解。
有時候不是不想學，而是前面一個觀念沒接上，後面就整個聽不懂。
也因為自己走過這段過程，我更希望用新手聽得懂的角度，把自己理解的過程記錄下來。
這不是站在很厲害的位置教大家怎麼寫程式。
而是用一個剛走過這些卡關的人，回頭整理自己怎麼一步一步理解前端、理解專案、理解團隊協作。
如果你也是前端新手，或是正在學程式的路上覺得很挫折，我希望這個系列可以讓你知道：
卡住不代表你不適合。
看不懂不代表你永遠學不會。
有時候只是還需要多一點時間、多一點實作，還有一個比較貼近新手角度的說明。
當邏輯真的通了的那一刻，寫程式其實會很有成就感。
所以這 30 天，我不會把自己包裝成一個已經很厲害的工程師。
我更想誠實記錄一個新手，是怎麼從看不懂、跟不上，到慢慢在專案裡找到一點成就感。
這也是我開始這個系列的原因。
第一天，我先介紹了自己，也說明為什麼想挑戰這次鐵人賽。
下一篇，我會開始介紹 PawPal 這個專案。
它是我第一個參與的團隊專案，也是這 30 天文章的主要案例來源。
下一篇會聊聊：
為什麼是 PawPal？
第一次加入團隊專案時，我對這個專案的第一印象是什麼？
iThome鐵人賽
看影片追技術