技術文章寫作備忘錄：寫給三個月後的自己
技術文章寫得好不好，最簡單的檢驗方式是：三個月後的自己看得懂嗎？
先講結論
好的技術文章就三個要求：結構清楚、語氣像人、細節有例子。做到這三點，就贏過 80% 的技術文章了。
結構：開頭就要給答案
最常見的錯誤是用論文的寫法——先鋪陳背景、再講方法論、最後才給結論。但讀技術文章的人不是在寫學術報告，他們是在找答案。
所以開頭就把結論丟出來。讀者知道結論以後，才有動力往下看「為什麼」和「怎麼做」。
反面教材：「在當今快速發展的軟體工程領域中，我們經常面臨各種挑戰…」——拜託，直接告訴我答案。
語氣：想像你在跟朋友聊天
技術內容已經夠硬了，語氣不需要再硬。想像你在跟一個有興趣但不熟悉這個領域的朋友解釋，語氣自然就對了。
不要寫「提升系統效能」，寫「讓系統跑更快」。不要寫「實現資料持久化」，寫「把資料存起來」。用人話說技術，不是降低專業度，是提高可讀性。
當然，該用專業術語的時候還是要用。但第一次出現的時候，花一句話解釋一下：
CDN 是「內容分發網路」的縮寫，簡單說就是把你的網站內容複製到全球各地的伺服器上，讓各地的讀者都能快速載入。
細節：沒有例子的技術文章就是廢文
「版本控制可以幫助你管理程式碼的歷史記錄」——ok，然後呢？
「想像你在改一篇報告，改到一半發現三天前刪掉的那段其實是對的。沒有版本控制，你只能哭。有版本控制，按一下就回來了。」——這才讓人有感覺。
每一個抽象概念，都值得一個具體的例子。不用太複雜，一兩句話的場景描述就夠了。
自我檢查清單
每次寫完文章，我會問自己這幾個問題：
- 開頭 30 秒內能不能知道這篇在講什麼？
- 三個月後的我看得懂嗎？
- 有沒有哪段沒有例子的抽象解釋？
- 大聲唸出來，會不會覺得彆扭？
如果任何一題答案是「不」，就回去改。
寫了一篇教別人怎麼寫文章的文章，然後回頭看自己之前的文章，嗯，果然都沒做到。