如何写一篇好的技术博客

　　当制作软件然，并不是所有博客都能够先从"实践遇到问题"最先，由于许多情形下都是先从书籍理论最先学习的（这也就发生了一定的局限性，有时间你学的很好，反而陷入了固有的框架；有时你学的欠好，显得自己越发无知）。这种情形，问题是需要自己总结出来的，好比ULK上会先容中止和异常的处置惩罚机制，这包罗中止的历程、CPU的事情、内核的事情、软中止的处置惩罚、tasklet等等，我们学习中止，不仅仅是一旦发生中止，Linux内核是根据什么流程行止理，而是要找到这么处置惩罚的缘故原由，也就是解决了什么问题。有时，实践验证的成本过高，在有条件的条件下做吧。

　　知识最先学习的时间，经常是只见树木，不见森林。俗话说：”孤木不成林“，弄上三五棵树，才会有”森林“的感受。        

　　四、只管拒绝三手手艺

　　在现实学习或者事情中，一个问题不明确，那么就需要讨教别人。若是能够从周围的妙手、牛人那获得简朴、直接的回复，那是最好的。若是不能，就需要自己在网上查找资料，可能一个问题，林林总总的在网上能搜出许多，选择看哪些就是个问题。只管去选择原发性的质料，若是你在查gcc的一个编译选项是什么意思，可以使用man手册，若是还不清晰，就去gnu的官方站点去查，最好不要随便从某个转载的手艺博客上获取。若是你要找x86平台CPU会见内存的方式，应该从Intel的官方站点去找CPU的资料，最好不要随便在网上找篇博客看了拉到（最少应该先看官方质料）。

　　别人的博客自然带有别人的明白，而这种明白可能带有一定的主观性，有时甚至是错误的，应该养成从原产地采购的习惯。若是哪天能够发现一项手艺，那么这算一手手艺；若是你在学习一项成熟的手艺，那么该手艺就属于二手手艺了，若是你再从一个非源发性的地方去学习，那么很可能就是“三手手艺”。固然，需要思量实践成本，有时着实找不到源发性的质料，也不要太委曲自己了。另外，英文文章的水平整体高于国人的文章水平，应该只管看英文文章。

　　五、分清主次、落脚要害点

　　天下万事万物都有联系，通常和本篇博客的主题有联系的问题，都在本篇博客中形貌，是不现实的，也是没须要的。小我私家以为，一篇手艺博客应该不凌驾两个主题，若是凌驾了，就应该拆分。可是次要问题可能会有不少，这些次要问题纷歧定都要解决掉，但一定要分扫除优先级，和主题关系比力大的，应首先解决，关系小的，应其次解决，甚至并不在本篇博客中解决。对于没有解决的问题，可以列在”遗留问题“中，对于在其他博客中讨论的问题，给予链接。

　　凭据自己的能力，耕作到合适的条理。我将掌握一项手艺划分为如下条理，在博客中通常应该到达第三个条理：

听说过该手艺，相识该手艺解决什么问题；使用过该手艺，熟悉该手艺的使用要领；解构过该手艺，熟悉该手艺的架构、原理；领悟过该手艺，将该手艺与自己的以有知识完全融合，可以使用该手艺架构或解决其他问题。　　六、手艺博客的气势派头手艺博客不是论文，手艺博客由实在用性。固然，也有将论文发在博客上的，好比手艺博客的作者大部门应该是工程师，而不是学院派。一篇手艺博客可以是小到的一个编程技巧，可以写该技巧的原理、实现要领、利益，但不要写前500后300年的历史先容和展望未来。手艺博客通常体贴手艺的适用性，而非手艺背后理论的庞大性。手艺博客也不应该太过责备叱责，把文章写的大而全，而应该追求小而精。手艺博客应以陈述语气，小我私家情感色彩应该过滤掉，手艺不是生涯的所有。有人写手艺博客，常喜欢加入自己的心情，“xxx让我好烦啊”、“xxx很难，我一直连续搞了两天没睡觉”，我小我私家拒绝这种“呻吟”的气势派头。忌枚举代码。代码是实现的历程，而不是原理，列代码是为了看清流程，而非为了列代码而列代码。我小我私家的习惯是只管少列代码，若是能够使用校小的篇幅就能说明原理，绝不使用大篇幅的代码。可是若是简朴的枚举代码能够一目了然，也绝不铺张过多的文字去形貌历程。图片胜过文字。图片配文字比单纯的文字越发利便明白，甚至一张图就可以省略文字了，多绘图，少写字是个原则。思量时间成本。博客基本上是以时间换知识，因此需要越来越快，记载时间也很须要。列出时间遗留问题，以备以后解决。

 2/3   首页 上一页 1 2 3 下一页 尾页