轉—如何寫一篇好的技術博客

在工做過程當中,發現對不少東西都只知其一;不知其二,不是很透澈,到頭來很容易模糊,若是有一篇好的技術博客予以總結,一來即便忘記了,回過頭來再看,仍然能 夠從本身的思路中恢復;二來總結一下,還會發現一些潛在問題;三來,有利於你們交流技術。不少大公司都有本身的內部技術博客平臺,寫好本身的技術博客,對 一個技術人員來講,也有必定的成就感。編程

在網上查閱資料,常常能夠看到一些技術博客,要麼廢話連篇、排版紊亂,要麼代碼佔了篇幅的60%,有些甚至是錯的,會讓人產生誤解。所以,在這總結 一下一篇好的技術博客應該是怎樣的,同時也規整本身的不良習慣。本篇博客純屬我的的一點想法,是個原則性的東西,切忌逐條對號入座啊。緩存

本篇博客耗時2小時。架構

1、帶着明確的目的寫博客

常常看到這種博客,爲了寫博客而寫博客。好比一篇介紹socket接口的使用方法的博客,羅列了一堆代碼,湊上幾句話:「首先…,其次….,最 後…」,就算OK。若是你的目的是「練習如何使用寫博客的軟件」,或者「羅列接口」,甚至「練習寫做的方法」,那麼可能達到了目的。可是我想,寫一篇技術 博客,首先是要明確該博客的目的,一般是學習一項技術、解決一個技術問題什麼的,好比「學習Linux內存管理機制」,「解決kernel pannic的問題」,「打發時間」等。框架

不是全部的的事情都要寫一篇博客來記錄,要有本身的判斷什麼東西值的寫,什麼東西不值的寫。socket

2、寫本身的博客

網上相互轉載的帖子不少,一篇寫的不錯的博客常常會被轉載,建議不要輕易轉載別人的帖子,要寫本身的博客。一樣一個知識點,或者一樣一個問題,你的 理解和別人的理解的程度極可能是不同的,若是輕易的看過之後轉載了別人的博客,可能意味着一次自我學習或體會的機會的放棄。可能有人會說:」一樣一個 GFS的架構圖,我畫也是這樣,他畫也是這樣,由於GFS就是這樣設計的「,這裏並非要求任何一個細節都本身去作,而是要有本身的想法、本身的理解,比 如GFS分層的原則是什麼?爲何這樣分層,分層的好出?若是我要是去作的話,我會怎麼搞?學習

寫本身的博客可不是意味着不轉載別人的,好比說我看了一篇博客,而且通過實驗,倒是與博客裏面寫的徹底一致,很少也很多,若是要是本身的寫的話,也 會寫的基本同樣,那就不必再花費時間本身寫了。另外,以及純粹記錄性的博客,能夠轉載,好比「C語言運算符的優先級」,固然轉載仍是原創都不重要了。google

另外,把別人的好的博客做爲本身的原創,不但沒品,並且自欺欺人。設計

若是在博客中參考了別人的博客,能夠在參考資料裏面說起,若是是徹底轉載,也應註明轉載出處。接口

3、博客是總結,不是過程

寫博客有的時候是一個解決問題的過程。爲了解決一個問題,今天採用了a方法,發現不行,明天採用了b方法,發現也不行,後天採用c方法,發現行了, 那麼最終的博客應該是在c方法解決問題後,開始寫的。固然,前面的a,b方法,是須要作記錄的,但只是博客的原始材料,而不是博客自己。圖片

在剛開始寫博客時,我常常出現這種狀況:對一個技術不清楚,想了解一下,就開一篇技術博客,邊查資料邊填寫博客,結果基本上就是讀、複製、粘貼、 讀、複製、粘貼…的過程。最後落到本身手裏也是空空如也,想起一句諺語:「狗熊掰梆子——掰一個丟一個」,在懊惱本身的緩存爲何這麼少的同時,我也想是 否是方法不對?後來我想過,要想掌握一項技術、知識,大概須要這樣一個過程:實踐遇到問題——理論學習問題——實踐解決問題——理論總結問題。我想不少情 況我是缺乏了其中的三個部分,只有「理論學習問題」的過程。

後來,我就改爲按下列步驟寫博客了:

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

固然,並非全部博客都可以先從」實踐遇到問題」開始,由於不少狀況下都是先從書本理論開始學習的(這也就產生了必定的侷限性,有時候你學的很好, 反而陷入了固有的框架;有時你學的很差,顯得本身更加無知)。這種狀況,問題是須要本身總結出來的,好比ULK上會介紹中斷和異常的處理機制,這包括中斷 的過程、CPU的工做、內核的工做、軟中斷的處理、tasklet等等,咱們學習中斷,不只僅是一旦發生中斷,Linux內核是按照什麼流程去處理,而是 要找到這麼處理的緣由,也就是解決了什麼問題。有時,實踐驗證的成本太高,在有條件的前提下作吧。

知識開始學習的時候,常常是隻見樹木,不見森林。俗話說:」孤木不成林「,弄上三五棵樹,纔會有」森林「的感受。

4、儘可能拒絕三手技術

在實際學習或者工做中,一個問題不明白,那麼就須要請教別人。若是可以從周圍的高手、牛人那獲得簡單、直接的答覆,那是最好的。若是不能,就須要自 己在網上查找資料,可能一個問題,林林總總的在網上能搜出不少,選擇看哪些就是個問題。儘可能去選擇原發性的材料,若是你在查gcc的一個編譯選項是什麼意 思,可使用man手冊,若是還不清楚,就去gnu的官方站點去查,最好不要隨便從某個轉載的技術博客上獲取。若是你要找x86平臺CPU訪問內存的方 式,應該從Intel的官方站點去找CPU的資料,最好不要隨便在網上找篇博客看了拉到(起碼應該先看官方材料)。

別人的博客天然帶有別人的理解,而這種理解可能帶有必定的主觀性,有時甚至是錯誤的,應該養成從原產地採購的習慣。若是哪天可以發明一項技術,那麼 這算一手技術;若是你在學習一項成熟的技術,那麼該技術就屬於二手技術了,若是你再從一個非源發性的地方去學習,那麼極可能就是「三手技術」。固然,須要 考慮時間成本,有時實在找不到源發性的材料,也不要太勉強本身了。另外,英文文章的水平總體高於國人的文章水平,應該儘可能看英文文章。

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

世界萬事萬物都有聯繫,凡是和本篇博客的主題有聯繫的問題,都在本篇博客中描述,是不現實的,也是不必的。我的認爲,一篇技術博客應該不超過兩個 主題,若是超過了,就應該拆分。可是次要問題可能會有很多,這些次要問題不必定都要解決掉,但必定要分清除優先級,和主題關係比較大的,應首先解決,關係 小的,應其次解決,甚至並不在本篇博客中解決。對於沒有解決的問題,能夠列在」遺留問題「中,對於在其餘博客中討論的問題,給予連接。

根據本身的能力,耕耘到合適的層次。我將掌握一項技術劃分爲以下層次,在博客中一般應該達到第三個層次:

  • 據說過該技術,瞭解該技術解決什麼問題;
  • 使用過該技術,熟悉該技術的使用方法;
  • 解構過該技術,熟悉該技術的架構、原理;
  • 貫經過該技術,將該技術與本身的以有知識徹底融合,能夠利用該技術架構或解決其餘問題。

6、技術博客的風格

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

原文出處:rock3 的博客

相關文章
相關標籤/搜索