隻有光頭才能變強。
我一直推崇學技術可以寫技術部落格去沉澱自己的知識，因為知識點實在是太多太多了，通過自己的部落格可以幫助自己快速回顧自己學過的東西。
我最開始的時候也是隻記筆記，認為自己能看得懂就好。但如果想驗證自己是不是懂了，可以寫成技術部落格。在寫技術部落格的過程中肯定會發現：“這個知識點，我好像還有些沒搞懂”。 從梳理/編寫的過程，自己也會成長不少
有不少的小夥伴曾經問過我：
“3y你是怎麼記筆記的阿？我一邊看視訊一邊記筆記，顧頭不顧腚的”
“你寫的部落格都是怎麼思考的阿？我不會寫部落格”
下面來談談我一些觀點（個人/主觀），每個人都有自己的方法論，我的觀點不适用于所有人。
開局一張圖，内容全靠編：
首先，我認為要把自己當做是一個分享者，而讀者是一個小白。然後模拟這個場景：如果你要把你學習到的技術分享給小白，你需要怎麼去做。
按照我的思路，我可能會這樣做：
首先，這項技術是什麼你得先告訴他。
接着，為什麼要學習這項技術，學習了這項技術有什麼好處。有沒有以前的技術跟這個較為相似的，為什麼我不用以前的，而要學新的。（這一步非常非常重要）
然後，這項技術的核心用法是什麼，給出一些小案例，讓小白體驗到這項技術。
最後，用這項技術可能會出現什麼問題，官方有沒有提供方案解決，如果沒有，可能的解決方案有哪些。
大白話來說，其實就是：
是什麼
為什麼
怎麼做
一般來說，我會把重點放在 為什麼 ，因為我一直認為學習一門技術一定得知道：為什麼要學。
舉個例子，我當初寫【消息隊列】的思路：
回顧一下什麼是隊列，java已經支援各種類型的隊列了，跟消息隊列有什麼不同。
為什麼要用消息隊列，不用行不行？用消息隊列的好處有哪些
用了消息隊列可能會帶來的問題
如果遇到邏輯可能較為複雜，或者認為讀者會看不太懂的時候，可以畫圖來描述一下，這樣整一篇文章看下來就不會太枯燥。
其實吧，我寫文章都是按自己學習時的思路來寫。如果我在學習時中途某個地方卡住了，我就認為可能讀者在學習的時候也會存在同樣的問題。是以，我就把我的了解給記錄下來，如果有必要就畫圖來講解。
我寫了兩百多篇java技術部落格，有需要的同學可以關注我的github，歡迎一起學習和交流：https://github.com/zhongfucheng3y/3y
每個人寫出來的部落格都有自己的風格。
比如說有漫畫型的：
比如說有故事型的：
比如說有騷氣型的：
比如說有純幹貨型的：
說了這麼多，其實我想說的是：寫部落格應該要帶有屬于自己的風格。而不是把網上的資料直接複制粘貼就完事了，這樣沒有感情，沒有靈魂。(當然了，如果網上可能的确有寫得很好的，可以這麼做，但不可能整一篇都是相同的嘛)
一篇好的技術文章，它的排版一般不會差。我認為寫技術文章有幾點可以提高一下閱讀體驗：
整篇文章不要90%都是代碼，适當減少代碼，貼關鍵的部分就好了。(完整的代碼可以上傳到github)
多分段，技術文章可能就相對枯燥，如果将技術的說明擠在一塊，可能閱讀起來沒那麼好的體驗
增加圖示說明 or 插入相關的圖檔
程式員寫文章一般都用<code>markdown</code>文法了，使用恰當的話，文章的排版自然也不會太差啦。是以還沒用<code>markdown</code>文法的同學可以趕緊用起來，這玩意特好學，從學到用起來就幾分鐘。
我當時連履歷都是<code>markdown</code>文法…
markdown編輯器我推薦使用<code>typora</code>，無論是在mac還是在windows上都很好用。使用markdown就肯定要考慮一個問題：圖床用哪家？
無論使用哪家圖都有可能會挂，自己搞個圖床可能會安全一些(相對來說會比較麻煩)，我自己是使用<code>掘金</code>的圖床的。而我的文章往往會分發到幾個部落格網站上，像<code>簡書/知乎</code>這種會單獨将圖檔上傳到他們的伺服器上。
是以，從我個人的使用角度而言，并不會擔心圖床會挂問題。如果你将文章隻發送到一個平台中，還是得關注一下圖床是否可能失效的問題。
至于你發哪個平台，我曾經寫過一篇【程式員可以選擇哪些平台寫技術部落格？】，當時的總結：
如果不嫌棄<code>部落格園</code>的風格，可以選擇<code>部落格園</code>。否則建議選擇：<code>掘金</code>/<code>segmentfault</code>。
隻想管理自己寫過的文章，選擇：<code>github/gitbook</code>
喜歡折騰：<code>hexo+github</code>或者<code>wordpress</code>
簡單的<code>流程圖/思維導圖/..</code>可以使用<code>processon</code>就解決掉了。
有的沒的扯了一些，希望能夠對「有想要寫技術部落格，但無從下手的同學」一些幫助。