在學習寫程式的路上，設計出具備易讀、好維護、有彈性…（以下省略幾千字）的程式一直都是大家追求的目標，不管是看到別人的 code、自己不會寫去問人，或是被人問，應該很常聽到這句：
你怎麼知道要這樣寫？
對啊。你怎麼知道要這樣設計？你怎麼知道會遇到這樣的問題，能夠預留好某些彈性呢，甚至是防範於未然呢？
這句話問過的人都可能會得到這個好像有回答，但是好像沒什麼幫助的答案：
這都是經驗。
呃，我彷彿看到大學時期的我對這個回答感到無奈的臉。但好像就是這樣，寫多了自然就會知道。
但過去的我，一直沒有辦法被這個答案給說服。我不停在思考一件事情：
難道就沒有更有邏輯性的回答嗎？
現在的我，已經不會再問這種問題了。並不是我變得多會寫 code，而是我有我累積自己經驗的邏輯。
這篇文章的目的，就是希望能把我自己的邏輯記錄下來，幫助現在正在這條路上努力的人，也給過去的我一個交代。
這些經驗的累積，有一個很重要的概念，就是：循環、檢討、實際使用
不要停止思考，不要妥協，不斷去追尋更好的做法，並且把每次學到的經驗，不僅僅回饋到下次的專案開發之中，同時也要回頭檢討過去的專案。
凡事由需求出發
寫程式是目的性很強的一種工作，你得先知道往什麼方向去，要達到什麼目標，為了達成這個目標要做哪些事情。跟蓋房子一樣，不知道房子要蓋成什麼樣子，是沒有辦法動工的。
開始寫 code 之前，確認需求一定是首要目標。
技術選擇靠實力
確認完需求之後，要使用哪些技術來達成，這完全是實力的展現。跟你過去看過多少 code，寫過多少 code，累積了多少知識，有完全的正相關。不可能選擇一個自己不知道的技術，因為他一開始就不會在選項裡面。
選擇的過程也需要知道為什麼選這個，他應該直接跟需求有關，而不是為了比較新，或是炫技而使用。
那沒經驗怎麼辦？
查資料、看文件、問人，然後再 POC，這大概是你唯一的路。
懂的下對的關鍵字、會整理資料、懂的怎麼問問題是現在大家都必備的能力。
實作與重構的循環
確定技術選擇之後，會進入實作環節，但這重構又是怎麼一回事？
因為你會 Google、會看到別人的 code、會問 ChatGPT、會看 StackOverflow…，這些都會不斷影響你的想法，讓你在一邊開發的時候，一邊又想改寫法。
這都是正常的，只要技術能力跟得上，又有時程上的餘裕，直接改寫也不失是一個選擇。
實作以及重構的流程，會一直不斷的在開發的過程中上演，有經驗跟沒有經驗的開發者，就差在這個循環的次數（還有實作的速度😅）
老話一句：先求有再求好，如果因為一直重構而沒辦法實作完成，反而本末倒置。建議至少先完成一版，再來思考重構。
回饋環節不能少
當專案完成，程式碼寫完之後，好好檢討自己做得好，以及做得不好的地方，把這些事情統整記錄下來之後，找出原因，提出可行的解決方案，讓自己下次能夠做得更好，不要重蹈覆徹。
這環節不應放寬標準對待自己，更不能自我感覺良好，魔鬼就藏在細節裡。
如果專案做完就算了，也沒有從中獲得什麼進步，那這專案對自己毫無幫助。一定能找出什麼讓自己成長。
練習機會別放過
寫程式這條路上，學習得到的一切知識、技巧，有實作過跟僅僅是紙上談兵有顯著的差異，多練習多熟悉，之後才能抓準使用時機，所以說拿舊的專案來練習可以說是最好不過。
面對真實的自己很重要，了解過去自己有哪些不足之處，才有進步的機會。
透過對過去的自己做 code review，能獲得最直接的成長。
所以說，我認為「你怎麼知道要這樣寫？」的答案就在於實作重構的循環他之前已經走過了，並且檢討過了，也成為他的經驗之一，也因為已經內化成為知識了，所以沒辦法很明確的說出來是因為什麼事件，讓他有這種想法要寫成這樣。
那我們能做的是什麼？就是去搞清楚這樣寫是要解決什麼問題，為什麼能解決這個問題，並且把這次學會的融入自己的經驗，變成自己的東西，然後不斷的問自己：
「如果是我的話，我會怎麼做？有沒有更好的寫法？」
祝各位學習順利，實作重構的循環越來越少！
下一篇預計用一個 Timer 的範例，來演示這個流程，一步一步改變實作。也順便回答學生的問題🤣
