怎樣去總結(jié)寫出好的技術(shù)博客

在工作過程中，發(fā)現(xiàn)對很多東西都一知半解，不是很透徹，到頭來很容易模糊。如果有一篇好的技術(shù)博客予以總結(jié)，一來即使忘記了，回過頭來再看，仍然能夠從自己的思路中恢復(fù)；二來總結(jié)一下，還會發(fā)現(xiàn)一些潛在問題；三來，有利于大家交流技術(shù)。很多大公司都有自己的內(nèi)部技術(shù)博客平臺，寫好自己的技術(shù)博客，對一個技術(shù)人員來說，也有一定的成就感。在網(wǎng)上查閱資料，經(jīng)�？梢钥吹揭恍┘夹g(shù)博客，要么廢話連篇、排版紊亂，要么代碼占了篇幅的60%，有些甚至是錯的，會讓人產(chǎn)生誤解。因此，在這總結(jié)一下一篇好的技術(shù)博客應(yīng)該是怎樣的，同時也規(guī)整自己的不良習(xí)慣。本篇博客純屬個人的一點想法，是個原則性的東西，切忌逐條對號入座啊。

本篇博客耗時2小時。

一、帶著明確的目的寫博客

經(jīng)�？吹竭@種博客，為了寫博客而寫博客。比如一篇介紹socket接口的使用方法的博客，羅列了一堆代碼，湊上幾句話：“首先...，其次....，最后...”，就算OK。如果你的目的是“練習(xí)如何使用寫博客的軟件”，或者“羅列接口”，甚至“練習(xí)寫作的方法”，那么可能達到了目的。但是我想，寫一篇技術(shù)博客，首先是要明確該博客的目的，通常是學(xué)習(xí)一項技術(shù)、解決一個技術(shù)問題什么的，比如“學(xué)習(xí)Linux內(nèi)存管理機制”，“解決kernel pannic的問題”，“打發(fā)時間”等。

不是所有的的事情都要寫一篇博客來記錄，要有自己的判斷什么東西值的寫，什么東西不值的寫。

二、寫自己的博客

網(wǎng)上相互轉(zhuǎn)載的帖子很多，一篇寫的不錯的博客經(jīng)常會被轉(zhuǎn)載，建議不要輕易轉(zhuǎn)載別人的帖子，要寫自己的博客。同樣一個知識點，或者同樣一個問題，你的理解和別人的理解的程度很可能是不一樣的，如果輕易的看過以后轉(zhuǎn)載了別人的博客，可能意味著一次自我學(xué)習(xí)或體會的機會的放棄�？赡苡腥藭�說：”同樣一個GFS的架構(gòu)圖，我畫也是這樣，他畫也是這樣，因為GFS就是這樣設(shè)計的“，這里并不是要求任何一個細節(jié)都自己去做，而是要有自己的想法、自己的理解，比如GFS分層的原則是什么？為什么這樣分層，分層的好出？如果我要是去做的話，我會怎么搞？

寫自己的博客可不是意味著不轉(zhuǎn)載別人的，比如說我看了一篇博客，并且經(jīng)過實驗，卻是與博客里面寫的完全一致，不多也不少，如果要是自己的寫的話，也會寫的基本一樣，那

就沒必要再花費時間自己寫了。另外，以及純粹記錄性的博客，可以轉(zhuǎn)載，比如“C語言運算符的優(yōu)先級”，當然轉(zhuǎn)載還是原創(chuàng)都不重要了。

另外，把別人的好的博客作為自己的原創(chuàng)，不但沒品，而且自欺欺人。

如果在博客中參考了別人的博客，可以在參考資料里面提及，如果是完全轉(zhuǎn)載，也應(yīng)注明轉(zhuǎn)載出處。

三、博客是總結(jié)，不是過程

寫博客有的時候是一個解決問題的過程。為了解決一個問題，今天采用了a方法，發(fā)現(xiàn)不行，明天采用了b方法，發(fā)現(xiàn)也不行，后天采用c方法，發(fā)現(xiàn)行了，那么最終的博客應(yīng)該是在c方法解決問題后，開始寫的。當然，前面的a，b方法，是需要做記錄的，但只是博客的原始材料，而不是博客本身。

在剛開始寫博客時，我經(jīng)常出現(xiàn)這種情況：對一個技術(shù)不清楚，想了解一下，就開一篇技術(shù)博客，邊查資料邊填寫博客，結(jié)果基本上就是讀、復(fù)制、粘貼、讀、復(fù)制、粘貼...的過程。最后落到自己手里也是空空如也，想起一句諺語：“狗熊掰梆子——掰一個丟一個”，在懊惱自己的緩存為什么這么少的同時，我也想是否是方法不對？后來我想過，要想掌握一項技術(shù)、知識，大概需要這樣一個過程：實踐遇到問題——理論學(xué)習(xí)問題——實踐解決問題——理論總結(jié)問題。我想很多情況我是缺少了其中的三個部分，只有“理論學(xué)習(xí)問題”的過程。后來，我就改成按下列步驟寫博客了：

? 碰到了問題，如果解決不了，而又比較有價值的話，就先記錄下來，作為一篇博客

的開篇。

? 首先，先自己分析問題，基于已有的現(xiàn)象，思考，在筆記本上記錄問題與可能的思

路。

? 其次，從外界獲取經(jīng)驗或者知識，比如請教別人，google等，學(xué)習(xí)他們，在筆記本

上記錄關(guān)鍵點。

? 然后，在實際中用學(xué)來的方法去解決問題，筆記本做好記錄，要像水流過水渠一樣

流淌前面記錄的思路。

? 最后，拿過筆記本，將以上過程再總結(jié)成一篇博客。

當然，并不是所有博客都能夠先從"實踐遇到問題"開始，因為很多情況下都是先從書本理論開始學(xué)習(xí)的（這也就產(chǎn)生了一定的局限性，有時候你學(xué)的很好，反而陷入了固有的框架；有時你學(xué)的不好，顯得自己更加無知）。這種情況，問題是需要自己總結(jié)出來的，比如ULK上會介紹中斷和異常的處理機制，這包括中斷的過程、CPU的工作、內(nèi)核的工作、軟中斷的處理、tasklet等等，我們學(xué)習(xí)中斷，不僅僅是一旦發(fā)生中斷，Linux內(nèi)核是按照什么流

程去處理，而是要找到這么處理的原因，也就是解決了什么問題。有時，實踐驗證的成本過高，在有條件的前提下做吧。

知識開始學(xué)習(xí)的時候，經(jīng)常是只見樹木，不見森林。俗話說：”孤木不成林“，弄上三五棵樹，才會有”森林“的感覺。

四、盡量拒絕三手技術(shù)

在實際學(xué)習(xí)或者工作中，一個問題不明白，那么就需要請教別人。如果能夠從周圍的高手、牛人那得到簡單、直接的答復(fù)，那是最好的。如果不能，就需要自己在網(wǎng)上查找資料，可能一個問題，林林總總的在網(wǎng)上能搜出很多，選擇看哪些就是個問題。盡量去選擇原發(fā)性的材料，如果你在查gcc的一個編譯選項是什么意思，可以使用man手冊，如果還不清楚，就去gnu的官方站點去查，最好不要隨便從某個轉(zhuǎn)載的技術(shù)博客上獲取。如果你要找x86平臺CPU訪問內(nèi)存的方式，應(yīng)該從Intel的官方站點去找CPU的資料，最好不要隨便在網(wǎng)上找篇博客看了拉到（起碼應(yīng)該先看官方材料）。

別人的博客自然帶有別人的理解，而這種理解可能帶有一定的主觀性，有時甚至是錯誤的，應(yīng)該養(yǎng)成從原產(chǎn)地采購的習(xí)慣。如果哪天能夠發(fā)明一項技術(shù)，那么這算一手技術(shù)；如果你在學(xué)習(xí)一項成熟的技術(shù)，那么該技術(shù)就屬于二手技術(shù)了，如果你再從一個非源發(fā)性的地方去學(xué)習(xí)，那么很可能就是“三手技術(shù)”。當然，需要考慮實踐成本，有時實在找不到源發(fā)性的材料，也不要太勉強自己了。另外，英文文章的水平整體高于國人的文章水平，應(yīng)該盡量看英文文章。

五、分清主次、落腳關(guān)鍵點

世界萬事萬物都有聯(lián)系，凡是和本篇博客的主題有聯(lián)系的問題，都在本篇博客中描述，是不現(xiàn)實的，也是沒必要的。個人認為，一篇技術(shù)博客應(yīng)該不超過兩個主題，如果超過了，就應(yīng)該拆分。但是次要問題可能會有不少，這些次要問題不一定都要解決掉，但一定要分清除優(yōu)先級，和主題關(guān)系比較大的，應(yīng)首先解決，關(guān)系小的，應(yīng)其次解決，甚至并不在本篇博客中解決。對于沒有解決的問題，可以列在”遺留問題“中，對于在其他博客中討論的問題，給予鏈接。

根據(jù)自己的能力，耕耘到合適的層次。我將掌握一項技術(shù)劃分為如下層次，在博客中通常應(yīng)該達到第三個層次：

? 聽說過該技術(shù)，了解該技術(shù)解決什么問題；

? 使用過該技術(shù)，熟悉該技術(shù)的使用方法；

? 解構(gòu)過該技術(shù)，熟悉該技術(shù)的架構(gòu)、原理；

? 貫通過該技術(shù)，將該技術(shù)與自己的以有知識完全融合，可以利用該技術(shù)架構(gòu)或解決

其他問題。

六、技術(shù)博客的風(fēng)格 ? 技術(shù)博客不是論文，技術(shù)博客由其實用性。當然，也有將論文發(fā)在博客上的，比如

技術(shù)博客的作者大部分應(yīng)該是工程師，而不是學(xué)院派。一篇技術(shù)博客可以是小到的一個編程技巧，可以寫該技巧的原理、實現(xiàn)方法、好處，但不要寫前500后300年的歷史介紹和展望未來。技術(shù)博客通常關(guān)心技術(shù)的實用性，而非技術(shù)背后理論的復(fù)雜性。技術(shù)博客也不應(yīng)該過分求全責(zé)備，把文章寫的大而全，而應(yīng)該追求小而精。 ? 技術(shù)博客應(yīng)以陳述語氣，個人感情色彩應(yīng)該過濾掉，技術(shù)不是生活的全部。有人寫

技術(shù)博客，常喜歡加入自己的心情，“xxx讓我好煩啊”、“xxx很難，我一直持續(xù)搞了兩天沒睡覺”，我個人拒絕這種“呻吟”的風(fēng)格。

? 忌羅列代碼。代碼是實現(xiàn)的過程，而不是原理，列代碼是為了看清流程，而非為了

列代碼而列代碼。我個人的習(xí)慣是盡量少列代碼，如果能夠使用校小的篇幅就能說明原理，絕不使用大篇幅的代碼。但是如果簡單的羅列代碼能夠一目了然，也絕不浪費過多的筆墨去描述過程。

? 圖片勝過文字。圖片配文字比單純的文字更加方便理解，甚至一張圖就可以省略文

字了，多畫圖，少寫字是個原則。

? 考慮時間成本。博客基本上是以時間換知識，因此需要越來越快，記錄時間也很必

要。

? 列出時間遺留問題，以備以后解決。

來源：網(wǎng)絡(luò)整理 免責(zé)聲明：本文僅限學(xué)習(xí)分享，如產(chǎn)生版權(quán)問題，請聯(lián)系我們及時刪除。

《怎樣去總結(jié)寫出好的技術(shù)博客》由互聯(lián)網(wǎng)用戶整理提供,轉(zhuǎn)載分享請保留原作者信息,謝謝!
鏈接地址：http://m.hmlawpc.com/gongwen/365128.html

• 上一篇：八年級如何撰寫工作總結(jié)
• 下一篇：如何寫銷售工作總結(jié)及計劃