這次暑期學校的一個月時間都是用來開發一個專案。說是一個月，但實際用來編碼的時間大約在三個星期。更具體的時間是早上八點半到下午五點半。最後這一週晚上也會拿來編碼。
三個星期的時間說多不多，但這種經歷倒是少有，踩了不少坑，也有不少收獲，這裡記錄一下。
學習新技術#
這次用的幾個技術棧都是之前沒有接觸過的：前端 React，後端 Flask。專案後期還引入了 Redux 和 useSWR。
我對學習新技術倒是蠻有熱情，之所以選用這些也是出於想嘗試些之前所沒有接觸過的事物。並且這次用到的技術棧，上手也都是比較容易的，除了 Redux 現在還是雲裡霧裡，所以整體的開發體驗下來並不會因為都是自己沒接觸過的技術而寸步難行。
但我還是發現了一個蠻大的問題：因為要趕最後的 ddl，所以比較偏向於急於求成，看了看用法和示例就開始寫了，雖然最後也確實能寫出點東西，但總有種半生不熟的感覺，沒有一種確確實實掌握的踏實感。
我還意識到，一個人的時間和精力是有限的，而技術卻是日新月異的。所謂莊子所說的：吾生也有涯，而知也無涯。所謂貪多嚼不爛，就是這個道理。
DRY 與 AHA#
這次專案中，後端幾乎是我在負責的。但就是這樣一個自己在開發的兩千行左右的代碼，到第三週的時候就還是偶爾會冒出想推倒重寫某個部分的想法。
尤其是 action 這個部分。在這個專案中，我將用戶收藏、評分、評論這三個功能抽象成一個 action。自己剛開始寫的時候還有點沾沾自喜，認為自己是做到了合理的內聚。
但後來卻發現其中的弊端：當我想單獨修改其中某一部分，因為其耦合性，導致我需要修改一些本不需要修改的代碼。而到了專案後期，前端已經和後端對接已經完成百分之八九十。這時候修改一個核心功能，可謂是牽一髮而動全身。改是能改，但是卻不敢改，因為承擔不起所需的時間成本。最後的解決方式是另外又寫了幾個方法，這就導致代碼變得很醜。這時候就真切體驗到了壘屎山是一種什麼樣的心情了。
回顧過去，思考如何在以後能盡量避免這種情況，我想有兩個原則可能會起作用：
- DRY
"Don't repeat yourself" 的縮寫。我雖然有意識去將一些常用的代碼封裝為一個方法。但還是有不少代碼，我選擇了直接複製粘貼原有可用代碼，並在其基礎上進行些許修改。這樣子固然省事，寫的時候也很暢快，但後期想要修改時，卻就要之前的偷懶付出相當的代價。而如若我之前多花些時間，將其封裝，這樣我的代碼也就更方便修改。 - AHA
"avoid hasty abstractions" 的縮寫。這個原則讓我不禁想到一句話 "premature optimization is root of all evil"。還是以 action 為例，如果我在將三個操作耦合成一個時多想一想，那會好許多。但話又說回來，怎麼樣才算是不倉促，怎麼樣才算不是過早。我覺得現階段的我還是缺乏經驗，所以下次遇到類似的情況時，我想我大概率還是會為自己的某個小聰明而沾沾自喜，並毫不猶豫地踏進給自己挖的又一個坑。
專案流程#
這次的流程是採用瀑布模式，相比於上學期所使用的 Scrum 總覺得不得勁。我個人感覺最大的差異是在專案前期，連續多天都是花在寫一些比較虛的文件。而這些文件：需求文件，設計文件之類，我們這幾個甚至連初出茅廬都還不算的新人，沒辦法考慮得那麼周到。而且多日時間上的付出只是一些文字，這樣的體驗感實在不好。
總的來說，這樣的經歷在我的學生階段中算是比較一個獨特的經歷，一個月的時間也沒有怎麼白白浪費掉，對自己還是較為滿意的。