前言

學技術時，很容易一直收藏文章、影片和文件。

但收藏久了會發現，資料越來越多，真正用得到的時候卻常常找不到。

後來我覺得，技術筆記不一定要寫得很完整，但要能讓未來的自己快速想起來：「當時我到底怎麼解的？」

不要只貼連結

只貼連結的筆記，短期看起來很快。

例如：

1
Docker 教學：https://example.com/docker

但過一段時間後，可能會遇到幾個問題：

  • 忘記這篇連結重點是什麼。
  • 網站失效。
  • 文章內容太長，不知道當初看的是哪一段。
  • 當時的問題情境已經忘了。

所以我會至少補一句自己的摘要。

1
這篇主要是在講 Docker volume，解決 container 重建後資料消失的問題。

這樣未來找回來時會快很多。

記錄問題情境

技術筆記最有價值的部分，通常不是答案本身，而是問題情境。

例如：

1
2
3
問題：本機可以連 DB，但部署到測試機後連線失敗。
原因：測試機沒有設定正確的 connection string。
解法：補上環境變數 Database__ConnectionString。

這種筆記下次遇到類似問題時，非常好用。

因為你不是只記得一個指令，而是記得完整判斷過程。

指令要附上用途

很多指令當下會用，過幾個月就忘記。

例如：

1
git log --oneline --graph --decorate --all

如果只貼指令，未來可能還要重新理解一次。

可以加上一句：

1
用來用簡潔圖形查看目前所有分支的 commit 關係。

筆記不是為了展示自己多懂，而是為了降低下次重新理解的成本。

寫得短也沒關係

技術筆記不一定每篇都要像完整教學文。

有時候幾行就夠：

1
2
3
問題：Hexo 部署到 Cloudflare Pages 後樣式路徑錯誤。
檢查：_config.yml 的 url 與 root。
結論：網站掛在根路徑時 root 維持 /。

這種短筆記很實用，也比較容易持續寫下去。

結語

技術筆記的重點不是寫得多漂亮，而是讓自己下次少繞一次路。

我會盡量記：

  • 當時遇到什麼問題。
  • 怎麼判斷原因。
  • 最後怎麼解。
  • 有哪些坑下次要注意。

寫給未來的自己看，通常就會變得比較實用。