转—如何写一篇好的技术博客

在工做过程当中，发现对不少东西都只知其一;不知其二，不是很透澈，到头来很容易模糊，若是有一篇好的技术博客予以总结，一来即便忘记了，回过头来再看，仍然能 够从本身的思路中恢复；二来总结一下，还会发现一些潜在问题；三来，有利于你们交流技术。不少大公司都有本身的内部技术博客平台，写好本身的技术博客，对 一个技术人员来讲，也有必定的成就感。

在网上查阅资料，常常能够看到一些技术博客，要么废话连篇、排版紊乱，要么代码占了篇幅的60%，有些甚至是错的，会让人产生误解。所以，在这总结 一下一篇好的技术博客应该是怎样的，同时也规整本身的不良习惯。本篇博客纯属我的的一点想法，是个原则性的东西，切忌逐条对号入座啊。

本篇博客耗时2小时。

1、带着明确的目的写博客

常常看到这种博客，为了写博客而写博客。好比一篇介绍socket接口的使用方法的博客，罗列了一堆代码，凑上几句话：“首先…，其次….，最 后…”，就算OK。若是你的目的是“练习如何使用写博客的软件”，或者“罗列接口”，甚至“练习写做的方法”，那么可能达到了目的。可是我想，写一篇技术 博客，首先是要明确该博客的目的，一般是学习一项技术、解决一个技术问题什么的，好比“学习Linux内存管理机制”，“解决kernel pannic的问题”，“打发时间”等。

不是全部的的事情都要写一篇博客来记录，要有本身的判断什么东西值的写，什么东西不值的写。

2、写本身的博客

网上相互转载的帖子不少，一篇写的不错的博客常常会被转载，建议不要轻易转载别人的帖子，要写本身的博客。一样一个知识点，或者一样一个问题，你的 理解和别人的理解的程度极可能是不同的，若是轻易的看过之后转载了别人的博客，可能意味着一次自我学习或体会的机会的放弃。可能有人会说：”一样一个 GFS的架构图，我画也是这样，他画也是这样，由于GFS就是这样设计的“，这里并非要求任何一个细节都本身去作，而是要有本身的想法、本身的理解，比 如GFS分层的原则是什么？为何这样分层，分层的好出？若是我要是去作的话，我会怎么搞？

写本身的博客可不是意味着不转载别人的，好比说我看了一篇博客，而且通过实验，倒是与博客里面写的彻底一致，很少也很多，若是要是本身的写的话，也 会写的基本同样，那就不必再花费时间本身写了。另外，以及纯粹记录性的博客，能够转载，好比“C语言运算符的优先级”，固然转载仍是原创都不重要了。

另外，把别人的好的博客做为本身的原创，不但没品，并且自欺欺人。

若是在博客中参考了别人的博客，能够在参考资料里面说起，若是是彻底转载，也应注明转载出处。

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 的博客