如何写一篇好的技术博客

标签: 技术 博客 | 发表时间:2013-12-08 14:31 | 作者:
出处:http://kb.cnblogs.com/

  在工作过程中,发现对很多东西都一知半解,不是很透彻,到头来很容易模糊。如果有一篇好的技术博客予以总结,一来即使忘记了,回过头来再看,仍然能够从自己的思路中恢复;二来总结一下,还会发现一些潜在问题;三来,有利于大家交流技术。很多大公司都有自己的内部技术博客平台,写好自己的技术博客,对一个技术人员来说,也有一定的成就感。

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

  本篇博客耗时2小时。

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

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

  不是所有的的事情都要写一篇博客来记录,要有自己的判断什么东西值的写,什么东西不值的写。

  二、写自己的博客

  网上相互转载的帖子很多,一篇写的不错的博客经常会被转载,建议不要轻易转载别人的帖子,要写自己的博客。同样一个知识点,或者同样一个问题,你的理解和别人的理解的程度很可能是不一样的,如果轻易的看过以后转载了别人的博客,可能意味着一次自我学习或体会的机会的放弃。可能有人会说:”同样一个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很难,我一直持续搞了两天没睡觉”,我个人拒绝这种“呻吟”的风格。
  • 忌罗列代码。代码是实现的过程,而不是原理,列代码是为了看清流程,而非为了列代码而列代码。我个人的习惯是尽量少列代码,如果能够使用校小的篇幅就能说明原理,绝不使用大篇幅的代码。但是如果简单的罗列代码能够一目了然,也绝不浪费过多的笔墨去描述过程。
  • 图片胜过文字。图片配文字比单纯的文字更加方便理解,甚至一张图就可以省略文字了,多画图,少写字是个原则。
  • 考虑时间成本。博客基本上是以时间换知识,因此需要越来越快,记录时间也很必要。
  • 列出时间遗留问题,以备以后解决。

相关 [技术 博客] 推荐:

创建GitHub技术博客全攻略

- - 开源软件 - ITeye博客
说明: 首先,你需要注册一个 github 账号,最好取一个有意义的名字,比如姓名全拼,昵称全拼,如果被占用,可以加上有意义的数字. 本文中假设用户名为  tiemaocsdn. 地址:  https://github.com/. 输入账号、邮箱、密码,然后点击注册按钮.. 注册完成后,选择 Free免费账号完成设置.

20个值得开发人员关注的jQuery技术博客

- Andy - ITeye资讯频道
毫无疑问,jQuery的缔造者的博客是你首先必须关注的. 这个也是必看之一,因为jQuery UI类库就出自这个网站. 老牌的学习jQuery的网站之一,这个网站是由几个作者联合建立. 非常酷的一个jQuery设计和分享网站,风格非常酷,里面的教程和插件实现非常有艺术感,本人这里强烈推荐. 老牌的网页设计网站,里面包含了非常多的jQuery教程和技巧.

如何写一篇好的技术博客

- - 博客园_知识库
  在工作过程中,发现对很多东西都一知半解,不是很透彻,到头来很容易模糊. 如果有一篇好的技术博客予以总结,一来即使忘记了,回过头来再看,仍然能够从自己的思路中恢复;二来总结一下,还会发现一些潜在问题;三来,有利于大家交流技术. 很多大公司都有自己的内部技术博客平台,写好自己的技术博客,对一个技术人员来说,也有一定的成就感.

CTO谈豆瓣网和校内网技术架构变迁 - Mainz - 博客园

- Sepher - FeedzShare
来自: 博客园-首页原创区 - FeedzShare  . 发布时间:2011年05月19日,  已有 2 人推荐. 豆瓣网CTO洪强宁讲述网站架构变迁. 罗马不是一天建成的,豆瓣的技术架构也是随着用户规模的增长一直在持续变化中. 洪强宁,2002年毕业于清华大学,现任北京豆瓣互动科技有限公司首席架构师.

如何当好炮友 (技术贴)_所长别开枪是我_新浪博客

- 振 - FeedzShare
来自: blog.sina.com.cn - FeedzShare  . 发布时间:2011年09月23日,  已有 2 人推荐. Shared by 月七. (2011-09-22 16:48:29)转载. 副高帅的区别只是炮友的分数高一点点而已. 如果你还纠结于没有女朋友,或者纠结于与女朋友的关系和相处,或者纠结于快圝感和麻烦之间,那么你看这个贴就对了.

20个值得开发人员关注的jQuery技术网站和博客

- Linker Lin - 博客园新闻频道
日期:2011/09/23           作者:Terry li - GBin1.com. 毫无疑问,jQuery 的缔造者的博客是你首先必须关注的. 这个也是必看之一,因为 jQuery UI 类库就出自这个网站. 老牌的学习 jQuery 的网站之一,这个网站是由几个作者联合建立. 非常酷的一个 jQuery 设计和分享网站,风格非常酷,里面的教程和插件实现非常有艺术感,本人这里强烈推荐.

关于删除MySQL Logs的一点记录 - 刘浩de技术博客

- - 博客园_首页
五一前,一个DBA同事反馈,在日常环境中删除一个大的slow log文件(假设文件大小10G以上吧),然后在MySQL中执行flush slow logs,会发现mysqld hang住. 今天尝试着重现了此问题,这里简要分析下原因. 构造slow log (将long_query_time设成了0);.

我当初是怎么管理技术团队的 - 旁观者 - 博客园

- -
关键词:管理技术人才、管理技术团队、技术传承、对题集/错题集、研发哲学. 窝窝技术团队大约两三百人左右,主要是五大块:研发、数据、无线、质量、运维. 2012年年初,一个大项目结束后,我召开了飞行研讨会,经过这次深刻反思,形成了几个影响深远的管理观点:. 管理者要向下提供工具,以形成干部的简单、易记忆、易执行的工作套路.

GBin1分享:20个值得开发人员关注的jQuery技术网站和博客

- Shark - ITeye论坛最新讨论
日期:2011/09/23           作者:Terry li - GBin1.com. 毫无疑问,jQuery的缔造者的博客是你首先必须关注的. 这个也是必看之一,因为jQuery UI类库就出自这个网站. 老牌的学习jQuery的网站之一,这个网站是由几个作者联合建立. 非常酷的一个jQuery设计和分享网站,风格非常酷,里面的教程和插件实现非常有艺术感,本人这里强烈推荐.