我也忘記這個主題是我自己想寫，還是有人問我所以才寫的。但無論如何這主題都滿有趣的，而且算是拋磚引玉，因為我也很好奇其他人寫文章時背後的過程以及心路歷程，希望大家可以互相分享交流。

原本這篇文章其實已經寫好一半，是把背後過程分成四個階段：記錄靈感、找資料、醞釀跟動手寫作。但我後來發現依照文章種類的不同，背後的過程以及細節都不太一樣，因此後來砍掉重練，改成以不同類別的角度來切入，並且以之前寫過的文章當做例子。

我自己會寫的文章類別大概分成三種：

  1. 面向一般大眾的技術白話文
  2. 面向工程師的硬實力技術文
  3. 心得文

每個類別我都找了一些文章，以下將直接以這些文章做舉例。

面向一般大眾的技術白話文

範例文章

  1. 白話 Session 與 Cookie：從經營雜貨店開始
  2. 從拉麵店的販賣機理解什麼是 API
  3. 零基礎的小明要如何成為前端工程師？

我從以前就一直很喜歡用白話文解釋艱澀技術名詞的這種風格，例如說 PTT 的水精靈就是我的偶像之一，以前高中時也買過那種靠著有趣的故事理解歷史的書籍，例如說《歷史是個什麼玩意兒，袁騰飛說中國史》，或前陣子買的《臺灣史上最有梗的臺灣史》。

我打從心底相信一件事情，那就是大部分的東西都可以用輕鬆好懂的白話文來解釋。如果解釋不了，那一定是你講得不夠白話，而不是這主題本身太過於艱澀。既然好好講話就可以讓對方理解，幹嘛一定要搬出一大堆技術名詞來嚇別人？何況目標讀者還是那些沒有技術背景的一般人。

我不太喜歡的一種風格就是在對一般人講解技術名詞時，只會像字典那樣帶過去：「這個叫做 Single Page Application，簡稱 SPA，單頁式應用，例如說 Gmail ，因為只有一頁而已」、「這個是 Cookie，就是儲存在瀏覽器的資料」…，這樣的學習成果極差。

除了白話以外，還有另一個重點是脈絡。

若是你想要講的白話，就要把技術放在一個脈絡底下去談它，這樣讀者才能知道為什麼需要這個技術，並且理解技術出現當下的時空背景是什麼。

我覺得自己會這麼注重這點，跟以前高中時很喜歡歷史有極大的關係。我忘記是從什麼時候對歷史開竅的了（搞不好就是看了那些白話文書籍之後），但開竅以後就覺得歷史的主軸是脈絡，而不是年代以及事件。

很多人會以為歷史就是一門需要去記年代以及事件的科目，但我不這麼認為。歷史就是以前發生過的事情，說穿了就是許多故事。大部分人都喜歡聽故事，但在唸歷史時卻忘記了它其實是一段故事。

重點不是那些事件本身，而是為什麼會有這些事件發生？是什麼引起的？當時的局勢是什麼樣子？那些點只是歷史這條長線之中很小的一部分，若你只看得到點，就永遠看不到背後其實是一條線。

我高中的歷史啟蒙之一是 PTT 歷史版的《海之民建立的千年共和國：威尼斯戰史》系列文，寫得真是好看而且引人入勝，把故事講得很精彩，比教科書有趣一百倍，在這邊誠心跟大家推薦。

總之有了脈絡這個心法之後，自然而然就會想把這樣的東西放到我的白話技術文裡面去——因為很多時候它是理解的關鍵。

舉例來說，大家都知道 Cookie 是瀏覽器存的一小塊資訊。但你有沒有想過 Cookie 發明以前是什麼樣子？為什麼要有 Cookie？Cookie 發明後帶來什麼樣的改變？我覺得這些問題才是重要的，因為只有理解這些，你才能真正理解 Cookie 到底是幹嘛的。

以上大概解釋了一下我為什麼喜歡寫白話文以及脈絡的重要性，接著來談談我是怎麼樣產生靈感的。

第一步：尋找靈感

靈感通常不會突然飛來，而是發生了什麼事所以給了你靈感。

我的靈感來源有兩個，工作與教學。

工作上會碰到一些技術問題，有時候可能只是基本的問題，你以為你理解，但實際深入之後卻發現不是這麼一回事，其實你不太懂這項技術。這時候就會想說：好，那我以後來研究一下這個技術好了，這就變成了靈感。

教學上的靈感來源是因為樣本數比較大（30~50 人），當你發現了集體卡關的現象時，就知道那邊一定有問題。例如說學生可能很多人卡在 API 的觀念，去找了很多資料還是不懂什麼是 API，這就是你表現的時候了，就可以來寫一篇有關 API 的白話科普文。

所以《從拉麵店的販賣機理解什麼是 API》其實就是這樣來的。

第二步：蒐集資料

決定好主題以後就要來開始找資料，在這個階段深度比廣度重要。以 Session 跟 Cookie 為例，一定可以找到一大堆相關的文章，但我敢保證八成的文章都長得差不多。大概就是簡單介紹一下這兩個東西，然後介紹 Cookie 可以放哪些參數，最後頂多加個實際應用範例，就結束了。

我自己覺得很多文章的深度都是不夠深的，有深度的文章可遇不可求。

所以我會盡量去找一些有權威性的資料來看，以網頁前端的領域來說就是 RFC、W3C 或是 ECMAScript 規格之類的，看你想寫的主題是什麼，這些東西的深度一定最深。

在寫《白話 Session 與 Cookie：從經營雜貨店開始》這一系列的時候，我大概花了三天看了三份 RFC 還有一篇像是論文的東西，就是為了想要徹底理解 Cookie 的歷史。

總之，這個階段的目標有兩個。

第一個是看一下其他人都寫了什麼，以什麼角度來切入，同時也增進自己對這個主題的理解。第二個目標是在下筆前確定自己對這個主題的理解是正確的。雖然之後還是有可能被糾錯，但至少有盡過查證的義務。

再來就可以邁入時間最長的第三階段。

第三步：醞釀

主題決定完也確定自己的理解無誤了，再來就是要想想自己要怎麼寫，要用什麼角度來切入這個主題。這一步跟上一步是相輔相成的，邊查資料邊想，邊想也邊查資料。

同樣的主題可以有千百種不同的寫法，也有許多種方式可以用來舉例。有時候比起常見的例子，我會想要舉一個不太一樣卻也貼切的，才能有驚喜感。

例如說我在《白話 Session 與 Cookie：從經營雜貨店開始》裡面舉的雜貨店加上臉盲症（？）的例子，就跟常見的通行證或是飲料店例子不太一樣，雖然故事誇張了點，但反而更幫助記憶，因為太離奇了所以比較有記憶點。

這一步會花最久的時間，因為你必須等待。你要讓它自然產生而不是去逼迫它，所以才叫醞釀。心裡有了一個點子，然後放著，偶爾沒事做的時候就想一下大概要怎麼寫，要怎麼開頭怎麼結尾，中間要用什麼故事來舉例，會有哪些情節。

以我的文章來說，通常架構都是長這樣的：

  1. 開頭稍微講一下為什麼寫這篇
  2. 從原初狀態開始講起，那時候還沒有主角技術 Y
  3. 鋪陳一段，繼續講早期的事
  4. 寫說碰到了什麼問題，把問題講清楚
  5. 開始寫各種當時的解法
  6. 寫解法之一的技術 Y 如何解決問題以及跟其他解法的差別
  7. 寫技術 Y 勝出的理由，再重新介紹一次技術 Y
  8. 附上結語與參考資料，結束

整體下來是很有脈絡的，可以看成就是少年漫畫主角的一生。世界大亂、主角崛起、打敗敵人、英勇退場。

平均醞釀的時間大概兩三週左右，像是 Session 與 Cookie 那篇文我花了兩個禮拜來醞釀。

第四步：寫作

如果上一步做得夠紮實，有把整個文章的架構都先想清楚的話，這一步就不太需要什麼思考的時間，順著架構把字打出來就好。花的時間取決於你腦袋轉動的速度以及打字速度，以我來說的話有些長文可能會花到一兩天，比較短的半天或一天就可以結束了。

若是寫一寫突然寫不出東西來，絕對不要在那邊死撐著。趕快打開 YouTube 看一些廢片壓壓驚，或是開始滑個臉書哀居批踢踢，把自己的大腦切換成發散模式，靈感就會自己慢慢累積起來，等到有靈感的時候再繼續寫。

面向工程師的硬實力技術文

範例

  1. 深入 Session 與 Cookie：Express、PHP 與 Rails 的實作
  2. 我知道你懂 hoisting，可是你了解到多深？
  3. 深入探討 JavaScript 中的參數傳遞：call by value 還是 reference？

技術文章比較常見的就兩種，一種是教學文，另一種是對於某種主題的研究。而我的文章幾乎都是後面的類型，因為教學我都錄成影片了，所以不會想要再寫文章講類似的事。

我覺得這種針對特定主題的文章有個很重要的點是深度。因為是主打硬實力的文章，所以能挖多深就多深。這邊我一開始也很不習慣，總是覺得自己的實力還沒到，一看到程式碼就退縮了，想說「算了…我也看不懂，就寫到這好了」，或是看到 RFC 文件就想說「阿…好長啊…我英文好差」，就放棄了。

直到我寫了《我遇過的最難的 Cookie 問題》，鼓起勇氣去看了 Chromium 的原始碼，才發現看原始碼沒有想像中的困難，只要掌握了一點小技巧就可以了，而且在原始碼中找到答案時也會非常開心，並且能夠百分之百保證那是對的。

上面差不多解釋了我對硬實力技術文章的看法，底下一樣來分享寫一篇文章的過程。

第一步：尋找靈感

這邊的靈感一半來自於工作上，另一半來自於生活上看到的技術文章或是別人問的問題。

以《深入 Session 與 Cookie：Express、PHP 與 Rails 的實作》為例，是之前幫忙做一個教學相關的專案時，對方誤以為 Session ID 這個東西跟登入的帳號有關，例如說把帳號 hash 過後就變成 Session ID。

我就跟他說不是的，Session ID 是亂數產生的。但在講出這句話的同時，我發現我沒有證據。我會知道這件事是因為「我以為」或是「我覺得」，但如果有人真的反問我：「你怎麼知道？」，我回答不出來。

於是我就跑去找 Rails 的原始碼來佐證這件事情，證明說：「你看，真的是亂數產生的，程式碼在這」。

《我知道你懂 hoisting，可是你了解到多深？》這篇則是一如往常在看前端技術社團的時候，發現有人在留言提到 TDZ（Temporal Dead Zone）這個詞。

我那時就想說：「咦？這是什麼？」，Google 之後才發現是跟 Hoisting 有關的名詞，查到之後覺得滿慚愧的，自以為知道什麼是 Hoisting 可是卻連 TDZ 都沒聽過。因此就循線找了更多文章，查到了更多的資料，最後才把這篇寫出來。

第二步：蒐集資料

這邊其實跟寫白話科普文的時候一樣，都是要盡量去找一些有深度的資料，確保自己的理解沒有問題。雖然說深度比廣度重要，但還是要盡可能找多一點參考資料來看，因為有些文章雖然講的淺，但卻是從一個不同的角度出發，也能讓你獲益良多。

以《我知道你懂 hoisting，可是你了解到多深？》為例，我看了這麼多的資料，裡面有深有淺：

這個步驟會需要去找以及去看很多資料，會花不少時間。以上面的文章為例子，前置作業可能花了一兩週吧，要把上面每一篇都看過，確認自己有徹底理解這個主題。

除了文章以外，很多時候也必須去看原始碼，才能找到自己想要的答案。例如說 Session 實作那一篇，就需要去看原始碼才寫得出來。

在看原始碼時有個小技巧，就是善用搜尋。例如說你想在 Rails 裡面找 Cookie 相關實作，就可以在 GitHub 上面針對這個 repo 搜尋「Cookie」，通常就能夠快速定位到相關檔案。找到相關檔案之後其他的都可以不用看了，因為你想找的東西就在附近了。

再來，追到原始碼的好處是你能肯定這個論述是對的。

舉例來說，你可能會查到一些資料跟你說在 Chromium 裡面 Cookie 的最大值是 4096 bytes，可是你要怎麼確定這是對的？

兩個方法，一個是找官方文件佐證，一個是去看相關原始碼。這兩種絕對是最權威性、最能拿來當作證據的資料。

第三步：醞釀

寫真材實料的技術文章一樣需要醞釀，因為你必須決定用什麼角度去寫這篇文章。你要如何開頭，如何結尾，中間要講到哪些東西？

以《我遇過的最難的 Cookie 問題》為例，開頭我先帶大家認識我之前碰到的問題，再記錄之後研究這個問題的經歷，最後給出一個結論。所以整體也是很有故事性的，發現問題、研究問題、解決問題。

至於《我知道你懂 hoisting，可是你了解到多深？》，開頭就列了十個項目，以這十個項目為主題來展開整篇文章。雖然說是由淺入深，但沒什麼故事性，就只是把這個主題從頭開始講到尾而已。

那像是《深入 Session 與 Cookie：Express、PHP 與 Rails 的實作》就更不一樣了，更無聊一點。沒有什麼故事性也沒有由淺入深，是三個平行的主題，湊在一起是因為他們都有 Session 與 Cookie 相關的實作。

所以同一個主題，可以從不同角度去切入。以《深入探討 JavaScript 中的參數傳遞：call by value 還是 reference？》為例，若是想寫這個主題，常見的架構如下：

  1. 介紹什麼是 call by value
  2. 介紹什麼是 call by reference
  3. 介紹什麼是 call by sharing
  4. 介紹以上三種的異同
  5. 結束

但我自己不太喜歡寫這種架構，我覺得比較無聊一點。我比較喜歡的角度是帶著讀者走過一遍當初研究的歷程。所以我這篇的架構是這樣的：

  1. 講說寫這篇的理由
  2. 稍微介紹 call by value、reference 跟 sharing
  3. 發現有人講「JavaScript 只有 call by value」，試著理解這句話
  4. 碰到問題想不通，決定去找解釋
  5. 找了 ECMAScript 發現一無所獲
  6. 想到隔壁棚的 Java，看看 Java 社群怎麼說
  7. 想到 C++，從 C++ 找靈感
  8. 得到解答，順利結案
  9. 後記
  10. 結束

這篇我可以不要把歷程寫出來，直接把最後得到的答案寫出來就好，但這樣太無趣了。在《學生為什麼不喜歡上學》這本書裡有一段我很喜歡：

回到教學上，我是這麼想的：我要學生學習的內容，說白了就是一個問題的答案。答案本身一點都不有趣，但如果你知道問題的話，答案可能會很有意思。所以把問題說清楚才那麼重要。但我有時候覺得，身為教師，我們都太強調求出答案，而沒有花足夠的時間讓學生理解問題，並了解問題的重要性。

有時候我不想讓讀者直接答案，我想藉著文章跟讀者一起找答案。或者是說，帶領讀者進入我當時找答案的歷程之中。

醞釀這個階段一樣是以週為單位來算的，我有一個筆記專門在放以後要寫的主題，都會先放個一陣子才真正動筆開始寫，因為有太多東西需要思考了：

第四步：寫作

跟之前一樣，在醞釀階段要先把大綱跟架構先想好，這樣子在實際寫作的時候可以省很多時間。

有些時候可能沒有想得很清楚就開始寫，下場有兩個，第一個就是邊寫然後腦袋邊運作，寫著寫著就把沒有想清楚的東西補齊了。

第二個下場就是寫一寫發現寫不下去，連自己都不會想看自己的文章，字寫得出來但毫無靈魂，只是一些冗言贅字而已，只好砍掉重練，再想清楚一點。

心得文

範例

  1. 四款訂餐外送 App 不專業評測
  2. 撇除娛樂不談，在新加坡生活一個月要多少錢？
  3. 非典型微 JGC 修行（JMB 水晶卡）之旅

相較於前兩種分類，心得文比較平易近人一點，都是一些比較生活化的文章。

因為很生活化，所以寫的時候不用有任何包袱，想寫什麼就寫什麼。

第一步：尋找靈感

這個分類的靈感通常都來自於生活，例如說你做了某件事之後有了一些心得，所以想把這些心得分享給大家。或也有可能初衷不是為了分享，而是為了幫自己留下紀錄，這樣子也很好。

以《撇除娛樂不談，在新加坡生活一個月要多少錢？》為例，其實想寫這一篇很久了，因為我那時能找到的新加坡生活相關文章我覺得參考價值都不大，所以想寫一篇以自己當作實際案例的文章，附上一些我覺得有參考價值的資料。

而《四款訂餐外送 App 不專業評測》則是因為那時在新加坡實在是叫太多外送了，每一款訂餐 App 都使用過。在使用的時候你就會發現有些 App 真的難用，但也有些細節做得很好，就特別想跟普羅大眾分享這些小發現。

我認為心得文是最容易發想靈感的一個類別——如果你本來是個喜歡分享的人的話。因為可以分享的主題太多了，例如說：

  1. 面試準備心得
  2. 面試公司心得
  3. 加入公司滿一個月心得
  4. 工作一年心得
  5. 記帳 App 心得分享
  6. YouTuber 觀察報告分享
  7. 常用網站分享
  8. ….

第二步：紀錄

心得文需要的不是蒐集資料，而是紀錄。

例如說新加坡生活的那篇文，在寫作之前我必須每天使用記帳 App 記帳 30 天，才有一個月的生活消費記錄。訂餐 App 那篇我也必須針對每個 App 截圖，還要計算各家叫外送的次數，把這些都記錄起來。

這個階段其實就是為了下一個步驟做準備，把你之後文章需要用到的資料都先記錄起來，截圖也先截好，參考資料都準備好，接著就可以進入到最後一個步驟了。

第三步：醞釀

雖然說心得文比較簡單一點，但還是需要一定的時間來醞釀，因為你依然要想說從哪個角度來切入主題。

舉例來說，新加坡生活的文章我可以只談總消費，也可以只談吃的價格，也可以從食衣住行育樂六個不同的角度下去分享。外送分享的我也可以單純只講我用每個 App 的心得，但也可以針對不同面向（速度、UI/UX、遲到率、客服）去切入，還可以幫每個項目都評分然後比較。

第四步：寫作

跟之前都一樣，我就不特別解釋了。

總結

四個步驟裡面，最簡單的我覺得是第四步寫作，最困難的是第三步醞釀。

我會認為寫作最輕鬆，是因為在醞釀的時候已經把文章的架構都想好了，所以當我在寫文章時不用特地去思考要寫什麼，很順的就可以把文章批哩啪拉打完。就算不順，也是稍作休息之後就可以接著繼續完成。

也因為這樣，醞釀的時間就需要比較久一點，有些主題會放個一兩個月甚至半年的也有，無聊的時候就想一下要朝什麼方向切入、要寫哪些內容，然後記在筆記上面。筆記真的很重要，千萬不要相信你的大腦，大腦會忘記，但筆記不會。

在我寫完一篇文章之後，通常會再看個兩三遍修改錯字，架構不太會變動，也不太會刪改。白話技術文有些會拿給朋友或學生看，看完之後根據意見再來修改，例如說把例子講得更清楚一點等等，有人幫你看文章還是一件很不錯的事。

若是有什麼想知道的事但我沒有寫出來的，也歡迎在底下留言，感謝。