如何寫(xiě)一篇好的技術(shù)博客
在工作過(guò)程中，發(fā)現(xiàn)對(duì)很多東西都一知半解，不是很透澈，到頭來(lái)很容易模糊，如果有一篇好的技術(shù)博客予以總結(jié)，一來(lái)即使忘記了，回國(guó)頭來(lái)再看，仍然能 夠從自己的思路中恢復(fù)；二來(lái)總結(jié)一下，還會(huì)發(fā)現(xiàn)一些潛在問(wèn)題；三來(lái)，有利于大家交流技術(shù)。很多大公司都有自己的內(nèi)部技術(shù)博客平臺(tái)，寫(xiě)好自己的技術(shù)博客，對(duì) 一個(gè)技術(shù)人員來(lái)說(shuō)，也有一定的成就感。
在網(wǎng)上查閱資料，經(jīng)?？梢钥吹揭恍┘夹g(shù)博客，要么廢話(huà)連篇、排版紊亂，要么代碼占了篇幅的60%，有些甚至是錯(cuò)的，會(huì)讓人產(chǎn)生誤解。因此，在這總結(jié) 一下一篇好的技術(shù)博客應(yīng)該是怎樣的，同時(shí)也規(guī)整自己的不良習(xí)慣。本篇博客純屬個(gè)人的一點(diǎn)想法，是個(gè)原則性的東西，切忌逐條對(duì)號(hào)入座啊。
本篇博客耗時(shí)2小時(shí)。
一、帶著明確的目的寫(xiě)博客
經(jīng)?？吹竭@種博客，為了寫(xiě)博客而寫(xiě)博客。比如一篇介紹socket接口的使用方法的博客，羅列了一堆代碼，湊上幾句話(huà)：“首先…，其次….，最 后…”，就算OK。如果你的目的是“練習(xí)如何使用寫(xiě)博客的軟件”，或者“羅列接口”，甚至“練習(xí)寫(xiě)作的方法”，那么可能達(dá)到了目的。但是我想，寫(xiě)一篇技術(shù) 博客，首先是要明確該博客的目的，通常是學(xué)習(xí)一項(xiàng)技術(shù)、解決一個(gè)技術(shù)問(wèn)題什么的，比如“學(xué)習(xí)Linux內(nèi)存管理機(jī)制”，“解決kernel pannic的問(wèn)題”，“打發(fā)時(shí)間”等。
不是所有的的事情都要寫(xiě)一篇博客來(lái)記錄，要有自己的判斷什么東西值的寫(xiě)，什么東西不值的寫(xiě)。
二、寫(xiě)自己的博客
網(wǎng)上相互轉(zhuǎn)載的帖子很多，一篇寫(xiě)的不錯(cuò)的博客經(jīng)常會(huì)被轉(zhuǎn)載，建議不要輕易轉(zhuǎn)載別人的帖子，要寫(xiě)自己的博客。同樣一個(gè)知識(shí)點(diǎn)，或者同樣一個(gè)問(wèn)題，你的 理解和別人的理解的程度很可能是不一樣的，如果輕易的看過(guò)以后轉(zhuǎn)載了別人的博客，可能意味著一次自我學(xué)習(xí)或體會(huì)的機(jī)會(huì)的放棄?？赡苡腥藭?huì)說(shuō)：”同樣一個(gè) GFS的架構(gòu)圖，我畫(huà)也是這樣，他畫(huà)也是這樣，因?yàn)镚FS就是這樣設(shè)計(jì)的“，這里并不是要求任何一個(gè)細(xì)節(jié)都自己去做，而是要有自己的想法、自己的理解，比 如GFS分層的原則是什么？為什么這樣分層，分層的好出？如果我要是去做的話(huà)，我會(huì)怎么搞？
寫(xiě)自己的博客可不是意味著不轉(zhuǎn)載別人的，比如說(shuō)我看了一篇博客，并且經(jīng)過(guò)實(shí)驗(yàn)，卻是與博客里面寫(xiě)的完全一致，不多也不少，如果要是自己的寫(xiě)的話(huà)，也 會(huì)寫(xiě)的基本一樣，那就沒(méi)必要再花費(fèi)時(shí)間自己寫(xiě)了。另外，以及純粹記錄性的博客，可以轉(zhuǎn)載，比如“C語(yǔ)言運(yùn)算符的優(yōu)先級(jí)”，當(dāng)然轉(zhuǎn)載還是原創(chuàng)都不重要了。
另外，把別人的好的博客作為自己的原創(chuàng)，不但沒(méi)品，而且自欺欺人。
如果在博客中參考了別人的博客，可以在參考資料里面提及，如果是完全轉(zhuǎn)載，也應(yīng)注明轉(zhuǎn)載出處。
三、博客是總結(jié)，不是過(guò)程
寫(xiě)博客有的時(shí)候是一個(gè)解決問(wèn)題的過(guò)程。為了解決一個(gè)問(wèn)題，今天采用了a方法，發(fā)現(xiàn)不行，明天采用了b方法，發(fā)現(xiàn)也不行，后天采用c方法，發(fā)現(xiàn)行了， 那么最終的博客應(yīng)該是在c方法解決問(wèn)題后，開(kāi)始寫(xiě)的。當(dāng)然，前面的a，b方法，是需要做記錄的，但只是博客的原始材料，而不是博客本身。
在剛開(kāi)始寫(xiě)博客時(shí)，我經(jīng)常出現(xiàn)這種情況：對(duì)一個(gè)技術(shù)不清楚，想了解一下，就開(kāi)一篇技術(shù)博客，邊查資料邊填寫(xiě)博客，結(jié)果基本上就是讀、復(fù)制、粘貼、 讀、復(fù)制、粘貼…的過(guò)程。最后落到自己手里也是空空如也，想起一句諺語(yǔ)：“狗熊掰梆子——掰一個(gè)丟一個(gè)”，在懊惱自己的緩存為什么這么少的同時(shí)，我也想是 否是方法不對(duì)？后來(lái)我想過(guò)，要想掌握一項(xiàng)技術(shù)、知識(shí)，大概需要這樣一個(gè)過(guò)程：實(shí)踐遇到問(wèn)題——理論學(xué)習(xí)問(wèn)題——實(shí)踐解決問(wèn)題——理論總結(jié)問(wèn)題。我想很多情 況我是缺少了其中的三個(gè)部分，只有“理論學(xué)習(xí)問(wèn)題”的過(guò)程。
后來(lái)，我就改成按下列步驟寫(xiě)博客了：
- 碰到了問(wèn)題，如果解決不了，而又比較有價(jià)值的話(huà)，就先記錄下來(lái)，作為一篇博客的開(kāi)篇。
- 首先，先自己分析問(wèn)題，基于已有的現(xiàn)象，思考，在筆記本上記錄問(wèn)題與可能的思路。
- 其次，從外界獲取經(jīng)驗(yàn)或者知識(shí)，比如請(qǐng)教別人，google等，學(xué)習(xí)他們，在筆記本上記錄關(guān)鍵點(diǎn)。
- 然后，在實(shí)際中用學(xué)來(lái)的方法去解決問(wèn)題，筆記本做好記錄，要像水流過(guò)水渠一樣流淌前面記錄的思路。
- 最后，拿過(guò)筆記本，將以上過(guò)程再總結(jié)成一篇博客。
當(dāng)然，并不是所有博客都能夠先從”實(shí)踐遇到問(wèn)題”開(kāi)始，因?yàn)楹芏嗲闆r下都是先從書(shū)本理論開(kāi)始學(xué)習(xí)的（這也就產(chǎn)生了一定的局限性，有時(shí)候你學(xué)的很好， 反而陷入了固有的框架；有時(shí)你學(xué)的不好，顯得自己更加無(wú)知）。這種情況，問(wèn)題是需要自己總結(jié)出來(lái)的，比如ULK上會(huì)介紹中斷和異常的處理機(jī)制，這包括中斷 的過(guò)程、CPU的工作、內(nèi)核的工作、軟中斷的處理、tasklet等等，我們學(xué)習(xí)中斷，不僅僅是一旦發(fā)生中斷，Linux內(nèi)核是按照什么流程去處理，而是 要找到這么處理的原因，也就是解決了什么問(wèn)題。有時(shí)，實(shí)踐驗(yàn)證的成本過(guò)高，在有條件的前提下做吧。
知識(shí)開(kāi)始學(xué)習(xí)的時(shí)候，經(jīng)常是只見(jiàn)樹(shù)木，不見(jiàn)森林。俗話(huà)說(shuō)：”孤木不成林“，弄上三五棵樹(shù)，才會(huì)有”森林“的感覺(jué)。
四、盡量拒絕三手技術(shù)
在實(shí)際學(xué)習(xí)或者工作中，一個(gè)問(wèn)題不明白，那么就需要請(qǐng)教別人。如果能夠從周?chē)母呤?、牛人那得到?jiǎn)單、直接的答復(fù)，那是最好的。如果不能，就需要自 己在網(wǎng)上查找資料，可能一個(gè)問(wèn)題，林林總總的在網(wǎng)上能搜出很多，選擇看哪些就是個(gè)問(wèn)題。盡量去選擇原發(fā)性的材料，如果你在查gcc的一個(gè)編譯選項(xiàng)是什么意 思，可以使用man手冊(cè)，如果還不清楚，就去gnu的官方站點(diǎn)去查，最好不要隨便從某個(gè)轉(zhuǎn)載的技術(shù)博客上獲取。如果你要找x86平臺(tái)CPU訪問(wèn)內(nèi)存的方 式，應(yīng)該從Intel的官方站點(diǎn)去找CPU的資料，最好不要隨便在網(wǎng)上找篇博客看了拉到（起碼應(yīng)該先看官方材料）。
別人的博客自然帶有別人的理解，而這種理解可能帶有一定的主觀性，有時(shí)甚至是錯(cuò)誤的，應(yīng)該養(yǎng)成從原產(chǎn)地采購(gòu)的習(xí)慣。如果哪天能夠發(fā)明一項(xiàng)技術(shù)，那么 這算一手技術(shù)；如果你在學(xué)習(xí)一項(xiàng)成熟的技術(shù)，那么該技術(shù)就屬于二手技術(shù)了，如果你再?gòu)囊粋€(gè)非源發(fā)性的地方去學(xué)習(xí)，那么很可能就是“三手技術(shù)”。當(dāng)然，需要 考慮實(shí)踐成本，有時(shí)實(shí)在找不到源發(fā)性的材料，也不要太勉強(qiáng)自己了。另外，英文文章的水平整體高于國(guó)人的文章水平，應(yīng)該盡量看英文文章。
五、分清主次、落腳關(guān)鍵點(diǎn)
世界萬(wàn)事萬(wàn)物都有聯(lián)系，凡是和本篇博客的主題有聯(lián)系的問(wèn)題，都在本篇博客中描述，是不現(xiàn)實(shí)的，也是沒(méi)必要的。個(gè)人認(rèn)為，一篇技術(shù)博客應(yīng)該不超過(guò)兩個(gè) 主題，如果超過(guò)了，就應(yīng)該拆分。但是次要問(wèn)題可能會(huì)有不少，這些次要問(wèn)題不一定都要解決掉，但一定要分清除優(yōu)先級(jí)，和主題關(guān)系比較大的，應(yīng)首先解決，關(guān)系 小的，應(yīng)其次解決，甚至并不在本篇博客中解決。對(duì)于沒(méi)有解決的問(wèn)題，可以列在”遺留問(wèn)題“中，對(duì)于在其他博客中討論的問(wèn)題，給予鏈接。
根據(jù)自己的能力，耕耘到合適的層次。我將掌握一項(xiàng)技術(shù)劃分為如下層次，在博客中通常應(yīng)該達(dá)到第三個(gè)層次：
- 聽(tīng)說(shuō)過(guò)該技術(shù)，了解該技術(shù)解決什么問(wèn)題；
- 使用過(guò)該技術(shù)，熟悉該技術(shù)的使用方法；
- 解構(gòu)過(guò)該技術(shù)，熟悉該技術(shù)的架構(gòu)、原理；
- 貫通過(guò)該技術(shù)，將該技術(shù)與自己的以有知識(shí)完全融合，可以利用該技術(shù)架構(gòu)或解決其他問(wèn)題。
六、技術(shù)博客的風(fēng)格
- 技術(shù)博客不是論文，技術(shù)博客由其實(shí)用性。當(dāng)然，也有將論文發(fā)在博客上的，比如技術(shù)博客的作者大部分應(yīng)該是工程師，而不是學(xué)院派。一篇技術(shù)博客可以 是小到的一個(gè)編程技巧，可以寫(xiě)該技巧的原理、實(shí)現(xiàn)方法、好處，但不要寫(xiě)前500后300年的歷史介紹和展望未來(lái)。技術(shù)博客通常關(guān)心技術(shù)的實(shí)用性，而非技術(shù) 背后理論的復(fù)雜性。技術(shù)博客也不應(yīng)該過(guò)分求全責(zé)備，把文章寫(xiě)的大而全，而應(yīng)該追求小而精。
- 技術(shù)博客應(yīng)以陳述語(yǔ)氣，個(gè)人感情色彩應(yīng)該過(guò)濾掉，技術(shù)不是生活的全部。有人寫(xiě)技術(shù)博客，常喜歡加入自己的心情，“xxx讓我好煩啊”、“xxx很難，我一直持續(xù)搞了兩天沒(méi)睡覺(jué)”，我個(gè)人拒絕這種“呻吟”的風(fēng)格。
- 忌羅列代碼。代碼是實(shí)現(xiàn)的過(guò)程，而不是原理，列代碼是為了看清流程，而非為了列代碼而列代碼。我個(gè)人的習(xí)慣是盡量少列代碼，如果能夠使用校小的篇幅就能說(shuō)明原理，絕不使用大篇幅的代碼。但是如果簡(jiǎn)單的羅列代碼能夠一目了然，也絕不浪費(fèi)過(guò)多的筆墨去描述過(guò)程。
- 圖片勝過(guò)文字。圖片配文字比單純的文字更加方便理解，甚至一張圖就可以省略文字了，多畫(huà)圖，少寫(xiě)字是個(gè)原則。
- 考慮時(shí)間成本。博客基本上是以時(shí)間換知識(shí)，因此需要越來(lái)越快，記錄時(shí)間也很必要。
- 列出時(shí)間遺留問(wèn)題，以備以后解決。
