怎样去总结写出好的技术博客

怎样去总结写出好的技术博客怎样去总结写出好的技术博客

怎样去总结写出好的技术博客

在工作过程中，发觉对许多东西都一知半解，不是很透彻，到头来很简单模糊。假如有一篇好的技术博客予以总结，一来即使遗忘了，回过头来再看，仍旧能够从自己的思路中恢复；二来总结一下，还会发觉一些潜在问题；三来，有利于大家沟通技术。许多大公司都有自己的内部技术博客平台，写好自己的技术博客，对一个技术人员来说，也有肯定的成就感。在网上查阅资料，常常可以看到一些技术博客，要么废话连篇、排版紊乱，要么代码占了篇幅的60%，有些甚至是错的，会让人产生误会。因此，在这总结一下一篇好的技术博客应当是怎样的，同时也规整自己的不良习惯。本篇博客纯属个人的一点想法，是个原则性的东西，切忌逐条对号入座啊。

本篇博客耗时2小时。

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

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

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

二、写自己的博客

网上相互转载的帖子许多，一篇写的不错的博客常常会被转载，建议不要轻易转载别人的帖子，要写自己的博客。同样一个学问点，或者同样一个问题，你的理解和别人的理解的程度很可能是不一样的，假如轻易的看过以后转载了别人的博客，可能意味着一次自我学习或体会的机会的放弃。可能有人会说：”同样一个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很难，我始终持续搞了两天没睡觉”，我个人拒绝这种“呻吟”的风格。

?忌排列代码。代码是实现的过程，而不是原理，列代码是为了看清流程，而非为了

列代码而列代码。我个人的习惯是尽量少列代码，假如能够使用校小的篇幅就能说明原理，绝不使用大篇幅的