自己也写技术分享文章，也经常看别人的分享文章，本篇就简单梳理梳理个人的一些看法，希望能给一些准备写技术分享的同学一点帮助。

优先确定技术文章面向的受众。是初级、中级还是高级、资深人员，面向不同的人群，所需措辞也不同，同一个词因人不同的知识结构会导致不同的解读，所以尽量减少这种不必要的消化损耗。文章真正被阅读的受众，这个是无法控制的，事先定好基调就比较容易把握文章深度，浅显易懂最好不过了。

其次要考虑到技术应用的上下文环境，这个要交待清楚，能解决什么问题，适用在什么场景下，如果能把类似的解决方案顺便提一下，更能阅读受众的知识面。

多使用图表。一图胜千言，对于晦涩的算法、流程、结构等，一张漂亮的图，那怕是草图，也能使读者很容易走近文章的世界，吸收文章的精华内容。相比满屏的文字，图表会花费较少的时间被阅读接受。

新名词的使用要引出简要的注释，便于读者消化吸引。由于知识诅咒的存在(通俗地说，就是一旦你知道了一个信息（学会了一样东西），你就很难想象你不知道该信息（没学会该东西）的情景。)，总会有一些我们常用但别人却不懂的名词存在，这会加大阅读的难度，也会给读者一个放弃文章不再阅读的选择。

如果我在一篇文章中碰到了一个新名词，一般来讲我会去检索弄懂，如果另外的文章中还有，则会引起一连串的检索，那本来我要读的那篇文章就会越为越远离我的视线。当然，我没读完的有兴趣文章，一般也不会关闭，至到把所有新名词弄懂。

要不要贴代码。不少同学的博客里出现大篇的详细代码，但读者去用的话，有时候完全不能运行，导致错误百出。自己的环境里上下文里有的东西，别人不一定有。

如果你决定贴代码，就要顺便把代码中的引用一并讲清楚，这对有帮助的人来讲，将会对你感激不尽。（一般有现成的代码，大家普遍喜欢直接Copy，而不是自己消化后自己写一篇，这不符合Ctrl+c/Ctrl+V编码的风格）当然有些读者会要求人，为什么不这样那样，这是当事人涉及的另外一回事了。

如果不贴具体代码，可以采用伪代码替代。即讲清楚了实现的逻辑，也避免了读者直接copy代码导致的各种问题。

文章的延伸性。一篇好文，读完酣畅淋漓，受益匪浅。不过有时候总有意犹未尽的感受，这个时候如果能适当的扩展一下，引申出更多的方向

题图 from unsplash

说完里子，再说面子，一篇条理清晰、结构融洽的文章读起来总能事半功倍，富文本编辑也好，Markdown编辑也好，较适当的内容以适当的格式表现出来，文字大小适中，段落控制得当等，多写几次基本就轻车熟路了。

行文的可读性。有些文章比较晦涩，但通过形象的比喻，能够助于读者更好的理解接受，远比一篇全是生硬的术语堆积起来的文章更加能够吸引人的。原理总是枯燥的，但小故事永远总会吸引人的。

虽然这篇文章质量高在读者看来高低未可知，但是我也总希望别人写的文章能达到以上的条件，一同努力。

往期推荐：

突破自己的技术思维

程序员，假如你当下赖以生存的技能失效了会怎样

我只想安心的搞技术，不想做管理

程序员之间的距离是怎么拉开的

学习新技术时你应当掌握的『最少必要知识』

30多岁挨踢人要转行的焦虑，是真的吗

你经常使用的技术真的掌握了吗

一线人员忙着学习技术，二线人员忙着技术变现

什么时机学习一项技术最高效

那些会阻碍程序员成长的细节[7]

长按2秒，识别二维码，关注我