歡迎來到Linux教程網
Linux教程網
Linux教程網
Linux教程網
您现在的位置: Linux教程網 >> UnixLinux >  >> Linux基礎 >> Linux教程

如何寫一篇好的技術博客?

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

在網上查閱資料,經常可以看到一些技術博客,要麼廢話連篇、排版紊亂,要麼代碼占了篇幅的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很難,我一直持續搞了兩天沒睡覺”,我個人拒絕這種“呻吟”的風格。
  • 忌羅列代碼。代碼是實現的過程,而不是原理,列代碼是為了看清流程,而非為了列代碼而列代碼。我個人的習慣是盡量少列代碼,如果能夠使用校小的篇幅就能說明原理,絕不使用大篇幅的代碼。但是如果簡單的羅列代碼能夠一目了然,也絕不浪費過多的筆墨去描述過程。
  • 圖片勝過文字。圖片配文字比單純的文字更加方便理解,甚至一張圖就可以省略文字了,多畫圖,少寫字是個原則。
  • 考慮時間成本。博客基本上是以時間換知識,因此需要越來越快,記錄時間也很必要。
  • 列出時間遺留問題,以備以後解決。
原文:http://rock3.info/?p=894
Copyright © Linux教程網 All Rights Reserved