给我一些写作上的建议

[zhangyifei216]

本人很喜欢写博客，从 2011 年开始写博客，博客也一步步在改进，先后在 51CTO ， CSDN ，新浪 SAE ，基于 gitcafe 的 hexo ，买的虚拟主机等等，最后不想折腾了从去年开始在 CSDN 上写博客，阅读量一般，自己觉得写的还可以，希望大家给我的博客提点建议，主要是从内容上，文笔上。我会好好吸取改正。

博客地址: http://blog.csdn.net/zhangyifei216

[monkeyk]

感觉你写的太深了, 没几个人能懂.

[monkeyk]

很多的博客都是在遇到问题时去寻找具体的解决办法, 个人觉得能解决具体的问题的阅读量会好许多.

[hanzichi]

题目，国内就不要用英文了吧

[jackal]

blog 上的，如果真的想让别人看， 它就是文章。 而文章不是内容的罗列。

内容的罗列或者说流水账，当然是重要的，作者自己通过罗列来获得知识的梳理，但是拿来当成文章是非常不合适的。

你说想让别人提几个意见， 我意见只有一个：多看一下优秀的博客作家。

[TanLian]

一天一更，甚至一天几更，看得出来确实很喜欢写

[zhangyifei216]

@jackal 有感触，但是限于自己的水平，目前文章内容的来源主要还是自己看的一些国外博客，和一些自己的学习笔记，后面工作了，会把工作中遇到的一些问题写成博客。

[zhangyifei216]

@monkeyk 的确是这样的，我以前坐运维开发的时候会写这类文章，目前做 c++服务器端开发，工作年限不长，遇到的问题也比较少，不好写成文章

[zhangyifei216]

@hanzichi 有的时候对英文的把握不够，不敢轻易翻译，让人误解。

[muziki]

个人感觉在解释某些机制原理的时候可不可以引入表图，看了几篇文章，代码解析的时候提到好多关键字，不太熟悉的情况下有点头大。
毕竟计算机编程这种东西抽象性还是比较强，能具现化，可能对读者理解有一定帮助

[zhangyifei216]

@muziki 好的，之前画图比较多，因为考虑到时间问题，有的时候就选择用文字代替了，后面我写文章会多引入一些图表示意

[M80]

技术文章如果想要读者喜欢，一般无非遵循这样的一个讲故事的流程：
1.在某些情况下我碰到了什么问题 /存在某些问题，所以要想办法解决
2.思考的流程，原有方法的缺陷，存在的问题
3.解决方法的思路展示，然后过渡到最终的结果，技术细节的展示

楼主的博客给人感觉是，一上来就和你罗列 1 ， 2 ， 3 ，那为什么人家需要去看你的博客，而不是自己自己去查文档呢？

以《 Chromium base 库介绍》为例，楼主一上来罗列了各个模块，各个类的作用，然后有些地方直接扔了代码出来。
那么这篇文章是面向读者还是面向自己（只是为了做备忘）。

如果是面向读者，那么问题来了：什么样的读者需要这篇文章的介绍
1.面向 Chromium base 毫无概念的读者？如果是这种读者，这种罗列根本让他们摸不到头脑， AtExitManager 是什么，到底在 base 里出于什么位置，为了解决什么问题，和其他的东西又是什么关系？
2.面向 Chromium base 有使用经验的读者甚至有自己上手 fork 并做一些代码调整的用户？如果是这种读者，这篇文章的深度又不够，并没有过多的自己的深入理解，纯粹是介绍而已。

如果是面向 1 用户，需要介绍的点就是：什么是 base 库，做 base 库要解决什么问题，解决这些问题需要哪些模块，具体的模块的设计和互相的交互是怎么样的，有哪些亮点设计

如果是面向 2 用户，可以考虑突出技术细节

[di94sh]

我觉得阅读量大的比如说 github 入门教程啊， postgresql 新手教程啊，这种。。哎，，我是新手，别打我。。。。

[z0z]

楼主的标题如果再加个"请“字就完美了。

[visonme]

技术文章要吸引读者无非就是要能解决读者的遇到的问题或者帮助读者进步。简化下：
1. 文章明确某个技术点
2. 文章中提到的技术需要考虑应用场景，以及要解决哪些场景下的问题
3. 如果需要，务必提供案例链接或者提供测试 demo （并附上 demo 的运行环境）
4. 内容要突出自己的见解，不能太多大众化的知识，一篇好技术文章不能没有自己的见解，这才真个文章吸引人的关键。
5.最后如果存在类似的技术，最后能在文章的结尾做个简单的对比

[mingyun]

@M80 说的很好，我也喜欢看这种博客