我從事技術寫作的時間其實不長，開始寫作的時間就是我掘金賬號註冊的時間：  到今天(2021年2月23日)也就是一年零一個月，這一年的收穫是超過我的預期的： 1. 產出博文四十多篇，總共數十萬字 2. [掘金優秀作者，掘金年度人氣作者No.27](https://juejin.cn/user/2295436011645655) 3. [思否2020年度"Top Writer"](https://segmentfault.com/a/1190000038796132)，[萬粉專欄作者](https://segmentfault.com/blog/dennis-jiang) 4. 開源中國優秀源創作者，[源創計劃年度活躍博主 Top20](https://www.oschina.net/best-2020) 本文想對這個歷程做一個回顧，並分享一下我總結的寫作技巧以及推廣策略。 ## 為什麼寫作 在寫作之前想清楚為什麼寫作非常重要！因為你最初的想法會決定你往哪個方向去寫，寫出的內容的質量怎麼樣。 我寫作的原因很簡單，就是我前端做了幾年了，大部分時間都在寫業務程式碼，技術上一直沒有太大的突破，最多也就是換個框架，換個UI庫，換來換去始終感覺似曾相識。為了不讓幾年工作經驗成為“第一年工作經驗的複製品”，我決定再深入，系統的學習下前端知識。所以對於我來說，寫作是我的學習方法，我的首要目的是學習知識，寫作帶來的社群聲望只是附帶的，有了當然好，沒有也沒必要刻意去刷。 ### “為學習而寫”與“為刷聲望而寫” 根據我的觀察，社群上的作者寫作目的主要分為兩種：“為學習而寫”與“為刷聲望而寫”。 大部分厲害的大佬其實都是“為學習而寫”，就是他們看到什麼好玩的，新奇的技術，去學習了，自然而然的總結出文章。或者覺得某個知識點大家很容易搞錯，想輸出自己的觀點，幫大家避坑，就將自己的見解寫成文章，這個過程作者雖然更多的是在輸出內容，但是寫作的過程其實也會強化作者自己的理解，其實也是一個學習方法。我個人認為“為學習而寫”寫出的文章才是正道，是社群良性發展的方向。 當然也有少部分作者想在短時間內獲取更多關注而刻意的去迎合讀者口味，也就是“為刷聲望而寫”。比較典型的一個例子就是，掘金曾經在某段時期被大量的面試題彙總佔據。大家出去面試了回來分享下心得其實是好事，但是刻意的去搜集面試題，相似的內容發了一遍又一遍，裡面的答案甚至還是錯的，會導致社群越來越功利，低質量面試題霸版，高質量技術文章反而沒機會展示，從而造成劣幣驅逐良幣的現象。我記得那會兒有個作者靠反覆發麵試題，短時間就刷了三四千掘力值，眼看就要到“優秀作者”了，結果被一個社群大佬懟了，然後就沒怎麼露面了。這樣，前面刷的幾千聲望不是都白費了嗎？後來掘金官方也整治了低質量的面試題文章，現在的情況已經好多了。 所以我說，寫作前想清楚“為學習而寫”與“為刷聲望而寫”很重要，如果是“為學習而寫”，那就可以寫出自己的心得體會，寫出高質量文章，如果單純是“為刷聲望而寫”，可能短期會有點收益，但是也有可能會被大佬懟，被官方整治，前功盡棄。 ## 寫什麼 在這個“系統學習計劃”開始之前，我其實沒怎麼寫過技術文章，甚至都沒怎麼逛過技術社群。平時如果需要學習一個東西，比如學習`React`，那我會直接去它的官方網站，把它的文件全部讀一遍，現在這些流行庫的文件都寫的很好，看一遍基本就能上手了。如果看完了還是不太知道怎麼用，那就去公司看看有沒有專案用過，公司沒用過，就去GitHub上找找，然後抄抄改改就能上手了。這個過程一般也就幾天，複雜的庫最多也就一兩週就能上手。使用的時候遇到問題就用Google搜，基本都會找到Stack Overflow上，答案拿過來一用就行。 前面幾年我的工作模式基本都是這樣的，這樣應付工作也沒啥問題，但是第一年是這樣，第二年是這樣，第n年還是這樣。。。就成了“一年工作經驗複用n年”，成了名副其實的“API工程師”，做專案沒問題，問原理似曾相識，但是卻說不太清楚。如果一直這樣，技術就會一直原地踏步，在現單位很容易被替代，出去找工作也可能會四處碰壁，或者找來找去找到的始終跟當前的差不多，很難實現大的突破。 我感到，我碰到瓶頸了。我想突破這個瓶頸，但是我不知道怎麼做！在沒有具體方向的時候，就看看手上能做啥吧，從簡單的，可見的開始做。於是，我決定，我要重頭整理自己的知識框架，把那些只是似曾相似的技術，原理全部吃透，於是我從網上找了一份“前端知識架構圖譜”，決定按照裡面的提綱，全部重新學習一遍。只是我再次學習不能是簡單的看看書，看看部落格，看看視訊就行了，這種事情我以前幹過了，作為一個有幾年工作經驗的前端，我對自己有更高的要求：**所有學過的知識點，必須自己全部寫成文章進行鞏固；所有框架的學習，必須學到原理或者原始碼層面**！ 所以，“寫什麼”這個問題的答案已經有了：**學習前端知識架構，將學習過程寫成文章**。 ## 怎麼寫 上面說了，我其實並沒有什麼寫作經驗，我最近一次寫作是大學論文，再往前就是高中作文了，寫作水平其實不咋地。但是技術寫作跟普通作文不一樣，一般不需要華麗的辭藻，更重要的是要把問題講清楚，看技術文章的讀者需要的是學習技術知識，而不是看風花雪月，所以技術文章的邏輯，層級遞進，由淺入深，好理解其實更重要。我剛開始時也不知道怎麼寫，也是在不斷寫作工程中，一邊寫，一邊總結，整體來說，我自己的文章其實都分了好幾個階段： 1. 就是記個筆記 2. 有自己理解的知識點解析 3. 深入原始碼，探究原理 4. 從工作中總結 ### 就是記個筆記 從小學開始，老師就會讓大家記筆記，大家應該都會，這也是最簡單的切入點。我剛開始的時候，不會寫文章，寫的基本都是筆記，比如[各種CSS居中方案](https://juejin.cn/post/6844904058193444871)，這就是我在其他地方學的，然後把他記錄下來，也就是個筆記而已。對於“CSS居中”這種問題來說，面試問爛了，網上資料也是一大堆，這篇文章也沒什麼出彩的地方，所以關注的人不多。其實對於“筆記型”來說，獲取關注少是很容易理解的，因為你寫的東西是筆記，也就是說你也是從其他地方學來的，整個文章的思路其實也是人家的，如果自己記筆記的水平不高，可能寫出來的效果還不如原文章。 ### 有自己理解的知識點解析 在寫了一些“筆記型”文章後，我發現效果不好，不僅僅是沒什麼人關注，甚至對自己幫助也不大。經常是寫了沒多久就忘了，需要的時候還要回過頭來看看筆記，我開始意識到，這個現象的本質是，你寫的東西是筆記，核心思想都是人家的，或者是自己東拼西湊的，整篇文章沒有自己的邏輯，沒有自己的見解。於是，我開始嘗試在文章中加入自己的見解，當時正好組內有小夥伴對“JS原型鏈”理解的不是很透徹，網上雖然有很多類似文章，但是很多都是從表面來解釋“原型鏈是什麼”，畫的圖也很複雜，不是很好理解。於是我嘗試自己寫一篇原型鏈的文章，因為我知道他可以實現“面向物件”的特徵，這是很多其他文章都沒怎麼提的，但卻是設計者最初可能想要實現的效果，於是我類比Java的面向物件，從面向物件的角度講述了原型鏈的作用以及他存在的意義，就是這個：[輕鬆理解JS中的面向物件，順便搞懂prototype和__proto__](https://juejin.cn/post/6844904069887164423)。這篇文章上了掘金首頁推薦，最終獲得了兩百多贊，一萬多閱讀，這讓我開始意識到，“有自己理解的知識點解析”在掘金可能更受歡迎。 在這之後，我開始有意識的在整理知識架構時加入自己的見解。那對於一個知識點，怎麼產生自己的見解呢？這需要在學習時多問自己幾個問題！比如，學習HTTPS時，除了跟大家一樣搞清楚HTTPS的加解密流程，握手過程外，我問了自己一個問題：“HTTPS有沒有可能被破解？假如我是個黑客，如果我想破解HTTPS，有哪些方法和途徑？”帶著這個問題，我從“破解HTTPS”的角度講述了HTTPS的原理，這篇文章也上了推薦，獲得了一百多贊和好幾千閱讀：[RSA初探，聊聊怎麼破解HTTPS](https://juejin.cn/post/6844904087205445640)。 嚐到點甜頭後，我更加註意在學習中反問自己問題，加入自己理解了。有時候在學習別人的東西時，我發現了別人沒發現的一些點，也可以從這個角度加入自己的獨到見解，寫成自己的文章，比如某視訊課程在講述JS的事件迴圈時說：“`setImmediate`比`setTimeout`先執行”。聽到這句話，我敏銳的感覺不太對，因為我曾經遇到過`setTimeout`比`setImmediate`先執行的情況，但是具體是啥情況我一時想不起來。於是我花了點時間把這個問題和原理徹底弄清楚了，並寫成了自己的文章：[setTimeout和setImmediate到底誰先執行，本文讓你徹底理解Event Loop](https://juejin.cn/post/6844904100195205133)。這篇文章最終也獲得了一百多贊，大幾千閱讀~ ### 深入原始碼，探究原理 JS知識體系雖然龐大，但是終究是有限的，很快我就寫了十幾篇JS的文章，內容包含了記憶體管理，深淺拷貝，面向物件(原型鏈)，`this`指向，事件迴圈，變數型別，作用域等等。這些已經囊括了JS的主要知識點，JS上我已經很難找到新的寫文章的點了。 於是我的文章內容開始轉向我使用的框架，這幾年我主要使用的`React`技術棧。於是我準備重新整理學習`React`技術棧，當然不是學習他的用法了，畢竟我用了幾年了，用法早就熟悉了，這次我要學的是他們的原始碼和原理。原始碼和原理相對於JS知識和框架使用方法來說要難得多，受眾也小的多，對於讀者來說也很難產生直接的收益。因為讀者可能看個JS知識點，出去面試就能應付大部分的JS面試了，除了些大廠外，也不是每個公司面試都會問原始碼，而且這些受歡迎的開源庫是各位大牛努力寫作的成果，裡面匯聚了各種JS的高階用法，各種高階程式設計思想和設計模式，所以即使我儘量寫得深入淺出，層層遞進，相較於其他文章來說仍然會顯得更加晦澀難讀。所以這類文章在掘金獲得的贊和閱讀並不可觀，我大量的原始碼解析都只有三四十個贊，這裡面還有一半左右是我厚臉求朋友同事們點的(這點我後面在講推廣的時候會說)。 對於作者來說，寫原始碼類文章需要去讀框架原始碼，也會很花時間。我寫一個JS知識點的文章，因為東西都是我熟悉的，可能幾天就搞定了，寫完了還會有上百的贊。但是一個複雜框架的原始碼解析，比如`Express.js`，我需要一點點的去讀，去除錯原始碼，成文可能需要兩三週，寫完後可能仍然只有三四十個贊。從社群聲望增長這個角度來說，價效比極低！**但是我一直沒有放棄這類文章，甚至現在成了我主要的寫作方向。為什麼？因為人總要突破自己的舒適區，探索未知的領域，最終才能學習到東西，獲得成長**！這其實回到了文章開頭就提出的問題：“你為什麼要寫技術文章？”對於我來說，這是我學習的途徑，所以如果這個過程我能夠學到東西，能夠感受到成長，我就會堅持去做，即使他在其他方面價效比很低！另外我的原始碼類文章雖然在掘金反響不是很好，但是在其他平臺，比如思否，還可以，所以其實也是有回報的。 好了，說了這麼多為什麼要寫原始碼解析，現在來談談怎麼寫原始碼解析。前面說了，在我從事技術寫作之前，我基本不懂原始碼，是名副其實的“API工程師”，那會兒我也是一提到原始碼就心慌，完全不知道從何下手。後來我忐忑的打破自己的心理障礙，多次嘗試之後找到了一個看原始碼的套路。其實再