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

怎样去总结写出好的技术博客怎样去总结写出好的技术博客在工作过程中,发现对很多东西都一知半解,不是很透彻,到头来很容易模糊。如果有一篇好的技术博客予以总结,一来即使忘记了,回过头来再看,仍然能够从自己的思路中恢复;二来总结一下,还会发现一些潜在问题;三来,有利于大家交流技术。很多大公司都有自己的内部技术博客平台,写好自己的技术博客,对一个技术人员来说,也有一定的成就感。在网上查阅资料,经常可以看到一些技术博客,要么废话连篇、排版紊乱,要么代码占了篇幅的60%,有些甚至是错的,会让人产生误解。因此,在这总结一下一篇好的技术博客应该是怎样的,同时也规整自己的不良****惯。本篇博客纯属个人的一点想法,是个原则性的东西,切忌逐条对号入座啊。本篇博客耗时2小时。一、带着明确的目的写博客经常看到这种博客,为了写博客而写博客。比如一篇介绍socket接口的使用方法的博客,罗列了一堆代码,凑上几句话:“首先...,其次....,最后...”,就算OK。如果你的目的是“练****如何使用写博客的软件”,或者“罗列接口”,甚至“练****写作的方法”,那么可能达到了目的。但是我想,写一篇技术博客,首先是要明确该博客的目的,通常是学****一项技术、解决一个技术问题什么的,比如“学****Linux内存管理机制”,“解决kernelpannic的问题”,“打发时间”等。不是所有的的事情都要写一篇博客来记录,要有自己的判断什么东西值的写,什么东西不值的写。二、写自己的博客网上相互转载的帖子很多,一篇写的不错的博客经常会被转载,建议不要轻易转载别人的帖子,要写自己的博客。同样一个知识点,或者同样一个问题,你的理解和别人的理解的程度很可能是不一样的,如果轻易的看过以后转载了别人的博客,可能意味着一次自我学****或体会的机会的放弃。可能有人会说:”同样一个GFS的架构图,我画也是这样,他画也是这样,因为GFS就是这样设计的“,这里并不是要求任何一个细节都自己去做,而是要有自己的想法、自己的理解,比如GFS分层的原则是什么?为什么这样分层,分层的好出?如果我要是去做的话,我会怎么搞?写自己的博客可不是意味着不转载别人的,比如说我看了一篇博客,并且经过实验,却是与博客里面写的完全一致,不多也不少,如果要是自己的写的话,也会写的基本一样,那就没必要再花费时间自己写了。另外,以及纯粹记录性的博客,可以转载,比如“C语言运算符的优先级”,当然转载还是原创都不重要了。另外,把别人的好的博客作为自己的原创,不但没品,而且自欺欺人。如果在博客中参考了别人的博客,可以在参考资料里面提及,如果是完全转载,也应注明转载出处。三、博客是总结,不是过程写博客有的时候是一个解决问题的过程。为了解决一个问题,今天采用了a方法,发现不行,明天采用了b方法,发现也不行,后天采用c方法,发现行了,那么最终的博客应该是在c方法解决问题后,开始写的。当然,前面的a,b方法,是需要做记录的,但只是博客的原始材料,而不是博客本身。在刚开始写博客时,我经常出现这种情况:对一个技术不清楚,想了解一下,就开一篇技术博客,边查资料边填写博客,结果基本上就是读、复制、粘贴、读、复制、粘贴...的过程。最后落到自己手里也是空空如也,想起一句谚语:“狗熊掰梆子——掰一个丢一个”,在懊恼自己的缓存为什么这么少的同时,我也想是否是方法不对?后来我想过,要想掌握一项技术、知识,大概需要这样一个过程:实践遇到问题——理论学****问题——实践解决问题——理论总结问题。我想很多情况我是缺少了其中的三个部分,只有“理论学****问题”的过程。后来,我就改成按下列步骤写博客了:?碰到了问题,如果解决不了,而又比较有价值的话,就先记录下来,作为一篇博客的开篇。?首先,先自己分析问题,基于已有的现象,思考,在笔记本上记录问题与可能的思路。?其次,从外界获取经验或者知识,比如请教别人,google等,学****他们,在笔记本上记录关键点。?然后,在实际中用学来的方法去解决问题,笔记本做好记录,要像水流过水渠一样流淌前面记录的思路。?最后,拿过笔记本,将以上过程再总结成一篇博客。当然,并不是所有博客都能够先从"实践遇到问题"开始,因为很多情况下都是先从书本理论开始学****的(这也就产生了一定的局限性,有时候你学的很好,反而陷入了固有的框架;有时你学的不好,显得自己更加无知)。这种情况,问题是需要自己总结出来的,比如ULK上会介绍中断和异常的处理机制,这包括中断的过程、CPU的工作、内核的工作、软中断的处理、tasklet等等,我们学****中断,不仅仅是一旦发生中断,Linux内核是按照什么流程去处理,而是要找到这么处理的原因,也就是解决了什么问题。有时,实践验证的成本过高,在有条件的前提下做吧。知识开始学****的时候,经常是只见树木,不见森林。俗话说:”孤木不成林“,弄上三五棵