那些來不及說出口的話

第一次知道鐵人賽，是在 2014 年的時候。那時候還有分成學生組跟社會組，我還寫信去問說休學生算不算學生，後來主辦單位也很快的回了我信，說可以讓我當作學生身份。那時，我就覺得鐵人賽是一個還不錯的活動。

只是，因為那時候參賽日期剛好撞到我去日本玩（而且我還去十天，有文有真相，想看遊記的話可以參考這裡），出國玩還要每天寫技術文章實在是太累了，因此也只能作罷。

兩年以後，我是個有著一年半工作經歷的前端工程師。

而這一次抱著不成功便成仁的決心捲土重來，我已經提早做好準備！說實在的，要真的每天寫一篇真的超級無敵困難，如果真的這麼堅持的話，就會發生有些天可能只是講個兩三句話就發出去了，就為了達標而已。這樣子，會造成系列文的文章品質有些高有些低，我自己是覺得不太好。這次參賽，在開始之前我就先寫好大概十篇左右了，可以撐一個多禮拜，這樣就能夠有更多時間來醞釀品質比較高的文章，也會比較完整一些。

其實我覺得鐵人賽不必刻意強調三十天內每一天都 po 一篇，這樣很容易造成「為了寫文章而寫」的現象，只是為了每一天都有交作業，就隨便寫一寫。如果真的想提高文章品質，又想維持這種鐵人賽的精神，感覺六十天內 30 篇文章也不錯？或者是 30 天內 15 篇文章，不用連續，你只要有寫出來就好，我覺得這會是比較好的折衷辦法。但是，如果真的有人連續 30 天寫的系列文品質超級棒，那我真心佩服。

那接下來先來講一下自己當初為什麼會想寫這篇系列文吧。

在這之前，我在 Hahow 開了一門線上課程叫做：初心者的計概與 CODING 火球術，裡面教一些基礎的電腦知識等等，可以看作是比較淺顯易懂的計算機概論。但這堂課的缺點就是：幾乎沒有實作的課程。就是一大堆理論跟原理講解，但不太會有時間讓你真的動手開始寫程式。我覺得這是滿可惜的一點，因此之前就有想要做一系列的教學是真的可以做出東西的。

而且我自己又學的比較廣一點，所以前端後端甚至 Android, React Native 等等的我也都可以教一些基本的，可以讓你寫出一個小作品來。我一直很想把這些我會的東西全部都寫成教學文分享出來，但這要花的功夫比想像中多好多。

總之呢，半端工程師養成計畫這一系列文章就是個 MVP，試著先把一些基本的概念寫出來，或者純粹先把大綱都訂出來也好。有了初稿以後，之後要更改或是新增內容都會容易很多。

對我來說，在寫文章的時候也是在學習，而且也學到很多。也算是一個研究，邊寫文章邊研究到底怎麼樣教初學者才是比較好的方式。其實我一開始是把文章的目標讀者訂在幾乎沒有程式基礎的人，所以會盡量講的淺顯易懂一點，但之後發現有些主題好像不管怎麼講都有一點點困難，所以到後期就會比較難閱讀一點了，有些地方會寫的沒那麼完整。

30 篇文章要講完整個前後端，其實我覺得是有一點困難的，有些主題沒有辦法帶到，但我已經盡可能寫得比較完整一點了。之後有機會，會想把每一個章節都補充的更深入一點，畢竟我覺得我章節規劃訂得還不錯，一步一步來。我之前有說過，有時候學習是要看脈絡的，只要你知道為什麼會有這個技術，以及這個技術是用來解決什麼問題，你就會學得更快，也理解的更深入。

總體而言，其實我對這 30 篇文章的品質是不滿意的，沒有達到我預期中的水準，而且範例程式碼都沒有地方可以下載，想要跟著練習也很困難。有很多內容也是讓大家自己查資料，但有些部分我覺得我能講得更清楚一點。如果我之後沒有太懶惰的話，我會想辦法找個時間把文章整理一下，加上範例程式碼以後發佈到 github 上面去，讓這系列文變得更完整一點。

在寫這系列教學文的時候，我也會時時刻刻不斷問自己說：有沒有更好的教法？還真的有幾次寫一寫突然被我想到怎麼教應該會比較好。也慢慢歸納整理出了一些「我認為」比較好的教法，因為沒有驗證過是不是真的比較好，所以必須強調我認為三個字。我認為你要能讓他們先知道痛，才來教解法，而不是先教解法再來跟他們說為什麼要這樣，這是完全不一樣的兩件事情。打到痛點是一件非常，非常重要的事情。如果不夠痛的話，就沒有理由去解決這個問題。

如果夠痛的話，當問題被解決之後就會豁然開朗，覺得：噢～原來是因為要解決這個問題，才有這種技術的出現。我希望可以帶給看這系列文章的人這個感想。當然，如果你看的時候沒感覺，那就是我寫得還不夠好，脈絡還不夠完整，這是我自己不足的地方，絕對不是你的。

最後，感謝這一個月來所有關注、瀏覽、留言或是追蹤的朋友們，很高興你們願意關注我的文章，有任何問題也都可以直接在底下留言，我都會盡可能找時間去回覆。