我是如何完成一篇文章的?

Image for post
Image for post
Photo by Steven Houston on Unsplash

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

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

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

  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,可是你了解到多深?》為例,我看了這麼多的資料,裡面有深有淺:

Image for post
Image for post
參考資料一籮筐

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

除了文章以外,很多時候也必須去看原始碼,才能找到自己想要的答案。例如說 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. 結束

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

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

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

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

Image for post
Image for post
各種待寫主題,寫完的我有時候不會刪掉,會繼續留著當作紀念(?)

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

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

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

心得文

  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、遲到率、客服)去切入,還可以幫每個項目都評分然後比較。

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

總結

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

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

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

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

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

Written by

重度拖延症患者,興趣是光想不做,有很多想做的事,卻一件都沒有執行。無聊的時候喜歡寫文章,發現自己好像有把事情講得比其他人清楚的能力。相信分享與交流可以讓世界更美好。Medium 文章列表請參考:https://aszx87410.github.io/blog/medium

重度拖延症患者,興趣是光想不做,有很多想做的事,卻一件都沒有執行。無聊的時候喜歡寫文章,發現自己好像有把事情講得比其他人清楚的能力。相信分享與交流可以讓世界更美好。Medium 文章列表請參考:https://aszx87410.github.io/blog/medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store