在工作過程中，發現對很多東西都一知半解，不是很透澈，到頭來很容易模糊，如果有一篇好的技術部落格予以總結，一來即使忘記了，回國頭來再看，仍然能夠從自己的思路中恢復；二來總結一下，還會發現一些潛在問題；三來，有利於大家交流技術。很多大公司都有自己的內部技術部落格平臺，寫好自己的技術部落格，對一個技術人員來說，也有一定的成就感。

在網上查閱資料，經常可以看到一些技術部落格，要麼廢話連篇、排版紊亂，要麼程式碼佔了篇幅的60%，有些甚至是錯的，會讓人產生誤解。因此，在這總結一下一篇好的技術部落格應該是怎樣的，同時也規整自己的不良習慣。本篇部落格純屬個人的一點想法，是個原則性的東西，切忌逐條對號入座啊。

本篇部落格耗時2小時。

一、帶著明確的目的寫部落格

經常看到這種部落格，為了寫部落格而寫部落格。比如一篇介紹socket介面的使用方法的部落格，羅列了一堆程式碼，湊上幾句話：“首先…，其次….，最後…”，就算OK。如果你的目的是“練習如何使用寫部落格的軟體”，或者“羅列介面”，甚至“練習寫作的方法”，那麼可能達到了目的。但是我想，寫一篇技術部落格，首先是要明確該部落格的目的，通常是學習一項技術、解決一個技術問題什麼的，比如“學習Linux記憶體管理機制”，“解決kernel pannic的問題”，“打發時間”等。

不是所有的的事情都要寫一篇部落格來記錄，要有自己的判斷什麼東西值的寫，什麼東西不值的寫。

二、寫自己的部落格

網上相互轉載的帖子很多，一篇寫的不錯的部落格經常會被轉載，建議不要輕易轉載別人的帖子，要寫自己的部落格。同樣一個知識點，或者同樣一個問題，你的理解和別人的理解的程度很可能是不一樣的，如果輕易的看過以後轉載了別人的部落格，可能意味著一次自我學習或體會的機會的放棄。可能有人會說：”同樣一個GFS的架構圖，我畫也是這樣，他畫也是這樣，因為GFS就是這樣設計的“，這裡並不是要求任何一個細節都自己去做，而是要有自己的想法、自己的理解，比如GFS分層的原則是什麼？為什麼這樣分層，分層的好出？如果我要是去做的話，我會怎麼搞？

寫自己的部落格可不是意味著不轉載別人的，比如說我看了一篇部落格，並且經過實驗，卻是與部落格裡面寫的完全一致，不多也不少，如果要是自己的寫的話，也會寫的基本一樣，那就沒必要再花費時間自己寫了。另外，以及純粹記錄性的部落格，可以轉載，比如“C語言運算子的優先順序”，當然轉載還是原創都不重要了。

另外，把別人的好的部落格作為自己的原創，不但沒品，而且自欺欺人。

如果在部落格中參考了別人的部落格，可以在參考資料裡面提及，如果是完全轉載，也應註明轉載出處。

三、部落格是總結，不是過程

寫部落格有的時候是一個解決問題的過程。為了解決一個問題，今天採用了a方法，發現不行，明天採用了b方法，發現也不行，後天採用c方法，發現行了，那麼最終的部落格應該是在c方法解決問題後，開始寫的。當然，前面的a，b方法，是需要做記錄的，但只是部落格的原始材料，而不是部落格本身。

在剛開始寫部落格時，我經常出現這種情況：對一個技術不清楚，想了解一下，就開一篇技術部落格，邊查資料邊填寫部落格，結果基本上就是讀、複製、貼上、讀、複製、貼上…的過程。最後落到自己手裡也是空空如也，想起一句諺語：“狗熊掰梆子——掰一個丟一個”，在懊惱自己的快取為什麼這麼少的同時，我也想是否是方法不對？後來我想過，要想掌握一項技術、知識，大概需要這樣一個過程：實踐遇到問題——理論學習問題——實踐解決問題——理論總結問題。我想很多情況我是缺少了其中的三個部分，只有“理論學習問題”的過程。

後來，我就改成按下列步驟寫部落格了：

• 碰到了問題，如果解決不了，而又比較有價值的話，就先記錄下來，作為一篇部落格的開篇。
• 首先，先自己分析問題，基於已有的現象，思考，在筆記本上記錄問題與可能的思路。
• 其次，從外界獲取經驗或者知識，比如請教別人，google等，學習他們，在筆記本上記錄關鍵點。
• 然後，在實際中用學來的方法去解決問題，筆記本做好記錄，要像水流過水渠一樣流淌前面記錄的思路。
• 最後，拿過筆記本，將以上過程再總結成一篇部落格。

當然，並不是所有部落格都能夠先從”實踐遇到問題”開始，因為很多情況下都是先從書本理論開始學習的（這也就產生了一定的侷限性，有時候你學的很好，反而陷入了固有的框架；有時你學的不好，顯得自己更加無知）。這種情況，問題是需要自己總結出來的，比如ULK上會介紹中斷和異常的處理機制，這包括中斷的過程、CPU的工作、核心的工作、軟中斷的處理、tasklet等等，我們學習中斷，不僅僅是一旦發生中斷，Linux核心是按照什麼流程去處理，而是要找到這麼處理的原因，也就是解決了什麼問題。有時，實踐驗證的成本過高，在有條件的前提下做吧。

知識開始學習的時候，經常是隻見樹木，不見森林。俗話說：”孤木不成林“，弄上三五棵樹，才會有”森林“的感覺。

四、儘量拒絕三手技術

在實際學習或者工作中，一個問題不明白，那麼就需要請教別人。如果能夠從周圍的高手、牛人那得到簡單、直接的答覆，那是最好的。如果不能，就需要自己在網上查詢資料，可能一個問題，林林總總的在網上能搜出很多，選擇看哪些就是個問題。儘量去選擇原發性的材料，如果你在查gcc的一個編譯選項是什麼意思，可以使用man手冊，如果還不清楚，就去gnu的官方站點去查，最好不要隨便從某個轉載的技術部落格上獲取。如果你要找x86平臺CPU訪問記憶體的方式，應該從Intel的官方站點去找CPU的資料，最好不要隨便在網上找篇部落格看了拉到（起碼應該先看官方材料）。

別人的部落格自然帶有別人的理解，而這種理解可能帶有一定的主觀性，有時甚至是錯誤的，應該養成從原產地採購的習慣。如果哪天能夠發明一項技術，那麼這算一手技術；如果你在學習一項成熟的技術，那麼該技術就屬於二手技術了，如果你再從一個非源發性的地方去學習，那麼很可能就是“三手技術”。當然，需要考慮實踐成本，有時實在找不到源發性的材料，也不要太勉強自己了。另外，英文文章的水平整體高於國人的文章水平，應該儘量看英文文章。

五、分清主次、落腳關鍵點

世界萬事萬物都有聯絡，凡是和本篇部落格的主題有聯絡的問題，都在本篇部落格中描述，是不現實的，也是沒必要的。個人認為，一篇技術部落格應該不超過兩個主題，如果超過了，就應該拆分。但是次要問題可能會有不少，這些次要問題不一定都要解決掉，但一定要分清除優先順序，和主題關係比較大的，應首先解決，關係小的，應其次解決，甚至並不在本篇部落格中解決。對於沒有解決的問題，可以列在”遺留問題“中，對於在其他部落格中討論的問題，給予連結。

根據自己的能力，耕耘到合適的層次。我將掌握一項技術劃分為如下層次，在部落格中通常應該達到第三個層次：

• 聽說過該技術，瞭解該技術解決什麼問題；
• 使用過該技術，熟悉該技術的使用方法；
• 解構過該技術，熟悉該技術的架構、原理；
• 貫通過該技術，將該技術與自己的以有知識完全融合，可以利用該技術架構或解決其他問題。

六、技術部落格的風格

• 技術部落格不是論文，技術部落格由其實用性。當然，也有將論文發在部落格上的，比如技術部落格的作者大部分應該是工程師，而不是學院派。一篇技術部落格可以是小到的一個程式設計技巧，可以寫該技巧的原理、實現方法、好處，但不要寫前500後300年的歷史介紹和展望未來。技術部落格通常關心技術的實用性，而非技術背後理論的複雜性。技術部落格也不應該過分求全責備，把文章寫的大而全，而應該追求小而精。
• 技術部落格應以陳述語氣，個人感情色彩應該過濾掉，技術不是生活的全部。有人寫技術部落格，常喜歡加入自己的心情，“xxx讓我好煩啊”、“xxx很難，我一直持續搞了兩天沒睡覺”，我個人拒絕這種“呻吟”的風格。
• 忌羅列程式碼。程式碼是實現的過程，而不是原理，列程式碼是為了看清流程，而非為了列程式碼而列程式碼。我個人的習慣是儘量少列程式碼，如果能夠使用校小的篇幅就能說明原理，絕不使用大篇幅的程式碼。但是如果簡單的羅列程式碼能夠一目瞭然，也絕不浪費過多的筆墨去描述過程。
• 圖片勝過文字。圖片配文字比單純的文字更加方便理解，甚至一張圖就可以省略文字了，多畫圖，少寫字是個原則。
• 考慮時間成本。部落格基本上是以時間換知識，因此需要越來越快，記錄時間也很必要。
• 列出時間遺留問題，以備以後解決。