[[379974]]

今年剛好是我寫技術博客的第十個年頭。恰逢最近也有些所想、所感、所得，所以想把發自內心的對技術博客這件事嘮叨幾句。算是想到哪寫哪，請見諒。

　　我的技術博客經歷

　　我的第一篇（姑且算是技術分類，但實際是我自己的做的一個軟件介紹）技術博客發布于 2010 年，在我大二的時候，那時候的技術博客還托管在博客園上；之后在 13 年到 14 年左右的時候，為了熟悉 Node.js ，用 Node.js + MangoDB 寫了一個內容管理的 cms，并且部署在 heroku 上（后來因為沒有續費，賬號被刪，源碼也沒有了）。最后因為維護成本過高，遷移到 github 的 jekyll 上，一直沿用至今。我博客的地址是 http://qingbob.com/， 但你可能更聽說過它的另一個馬甲——知乎專欄前端技術漫游指南

　　說真的我很好奇，在閱讀這篇文章的你們有多少是沖著標題進來的，被“收獲了什么”這個帶有些神秘色彩的語句誘惑的不行，迫切想知道最終的答案是什么。

　　我不敢說收獲是零，但如果我告訴你，寫技術博客的這十年，我收獲的可能并不會比你更多，你會不會很失望？

　　請允許我解釋這件事，讓我從一個工作的實際例子開始。

　　在加入項目的一年多的時間里，我負責的其中一項工作內容，是和前端代碼中用到的一個第三方類庫 Handsontable 斗智斗勇。這個類庫據說能夠承擔海量級別的數據渲染。但是在我們的項目中，在有的場景里使用它渲染上千條數據的時就會導致瀏覽器呈現一種假死的狀態，無法響應用戶的請求。

　　我的工作就是需要找到它的瓶頸，修復它，還原它的能力。

　　在解決這個問題相當長的一段時間內，我都是抱著一種類似于刑偵探案，緝拿真兇的心態，試圖找到性能問題背后的罪魁禍首。我認定真兇只有一個，一定存在某一處并不周正的代碼拖累了整個頁面的性能。

　　但結局是……這么說吧，好比其實是我找到了十處存在性能缺陷的代碼，每處會導致 500 毫秒的延遲，單拎出來任意一個缺陷都在可以接收的范圍之內。但是十處合并在一起拖累的就不只是 5 秒，而是會產生一加一大于二的效果。

　　說到底它還是一個寫代碼寫糙了，或者說代碼逐漸腐化了的問題，沒什么大驚小怪的。但我總幻想著背后有什么驚天大陰謀，解決它就能帶來質的飛躍。

　　哪有那么多事半功倍的好東西。

　　我想說的是，寫技術博客也是一樣，別指望它在某個時刻瞬間給你帶技術上的突飛猛進，讓你煥然一新。它和所有的“活”一樣，通過長時間的實踐，能讓某些技巧變得嫻熟，并鍛煉你的一些能力。而所謂的“意外收獲”？門都沒有。我見過很多很厲害的、讓我欽佩的程序員，他們也并非各個都寫技術博客，但我相信他們有他們的方式訓練自己。

　　所以我其實一直覺得，寫技術博客是一種訓練自己的過程。和反復地寫代碼，在上臺前反復的練習演講是一個道理。

　　對于我個人而言，我發現“發表是吸收的利器”。比如，你現在可以嘗試把你今天學習到的知識馬上向身邊的小伙伴復述一遍，你會發現過程中你會對一些概念有些模糊，或者他會向你提出一些你沒法立即回答的問題。這些都是值得再回過頭去學習的知識點，而技術博客就是這么一個無聲的小伙伴。

　　寫作的迷思

　　即使是說訓練，我覺得還是有一些寫作過程中的迷思和陷阱想提醒大家，純粹是我個人的經驗。

　　首先需要明確的是，博客究竟是寫給誰看的，讀者還是我自己？

　　除非你在刻意運營公眾號，需要迎合流量，否則一定是為你自己而寫。

　　首先寫作出發點就是你自己，只有當你有寫作欲望的時候，才有可能下筆，才想把它盡善盡美的寫好。

　　其次，也是更重要的是，讀者關注的并非是你關注的。

　　分享一個很有意思的事情。有一段時間，我的技術文章會同步發布在知乎和掘金上。于是這部分文章有了三個視角：我看待它們，知乎的讀者看待它們（點贊和收藏），和掘金的讀者看待它們（點贊和收藏）。我發現，一般我個人花了最多時間去整理和學習知識之后寫出來的最滿意的文章，或者是我認為價值最高的文章，通常在這兩個平臺無人問津。而“快速入門”和“全解”之類的文章收藏量和閱讀量卻最高。

　　我理解他們，但是我覺得很可惜。

　　某一年我拍腦袋想出來的一個算法相關的 idea，只花了三天時間就寫完了，但這篇技術文章的點擊率之高竟然成為了掘金的年度文章，讓我哭笑不得。而且知乎和掘金的群體又不太一樣，因為這篇文章在知乎上就沒有任何的反響

　　你永遠都不知道你的讀者在想什么

　　第二，“寫”這件事也是需要刻意提高的。

　　就算你工作了十年，但是你每天都在寫 hello world，你的技術也不會有任何的長進。

　　寫文章也是一樣，如果你只是為了寫而寫，習慣了在文章中貼大段大段的代碼，抱著一種“自己去理解吧”的心態，而不是嘗試用最簡單的文字去引導和解釋，你的寫作水平和表達能力永遠也不會有提升。

　　無論是在工作中還是文章里，我都反對不分原由的把文檔、代碼、或者是《XX 權威指南》扔給某個人，然后讓他自己去理解。這就好比你把一本漢語詞典遞給一個小學生讓他自學語文。可以，但很難，也完全沒有必要。

　　無論是在文字還是語言表達上，我習慣把我正在敘述的對象，想象為一名剛入門的程序員，或者只是一名有少許編程背景的 QA 同學，甚至是完全沒有只是背景的 HR。然后思考我應該如何通過最通俗易懂的表述，讓他們理解我想表達的概念。

　　甚至你還可以鋪墊， 賣關子，起承轉合，控制預期等等，為你的文采添磚加瓦，但這一切都離不開刻意的練習。

　　這一套訓練對口頭表達同樣有幫助。

　　第三，別怕不友好的評論

　　我不知道這是不是大家的問題，但這個是我的困惱。我的文章當然被懟過，我曾經因為被某個大V不友好的評論把文章的評論功能關閉了兩年。

　　后來我對這件事的焦慮有所緩解和理解是基于兩點：

　　我們很難通過文章評論的一來一回來表達我們想要表達的觀點。別說是文章評論，在公司內部，我們在會議室里交流幾個小時都不可能達成一致。在文章的背后，有我沒有完全表達的背景、上下文或者大家對一件事的理解不同又沒有辦法統一。誤解太正常了。

　　雖然“他”評論了，但是并不代表“他”有資格對你進行評論。也就是說，雖然我們有平等的網絡地位，在現實生活中我們有平等的政治權力，但并不意味著在某些專業問題上，我們的評論有相同的分量。好比一個人不敢評論交響樂、油畫，卻又為什么敢評論脫口秀和相聲呢，就因為大家都能說話是嗎？你可以發出“地球是平的”的聲音，大家也都能聽到你的聲音，但可能沒人會把你的評論當一件事。回到技術文章上，至少你應該對你的技術文章是有自信的，對于質疑的聲音，你要學會嘗試去自行判斷和理解。

　　寫技術博客這十年，讓我感到最遺憾的事情是，有很多在我剛入行時候關注的覺得有價值的技術博客，作者都早已不再維護了，甚至域名呈現的內容都已經面目全非了。 我還是希望在下一個十年我能繼續走下去，對于我個人來說，好奇心在，表達欲就在。