写好技术文章的几点小技巧
 并不代表文章本身的质量。 前几天无意翻到一篇《超长用户行为建模在躺平家居内容推荐中的应用实践》，我觉得写得不错，但是内容我完全看不懂，是专业领域的文章，受众不多，有上千的阅读量就已经很不错了。但是另一篇 《如何画好一张架构图？》 就有超过 3W 的阅读量。当然反例也有很多，就不再列举了。我自己写的几篇讲技术细节的文章，就没有讲技术对比、讨论技术发展的文章阅读量高。内容越专越细，能读下来的人就越少，但并不代表文章质量不高，反之亦然。 技术文章盲目追求阅读量和点赞数不是件好事，所以第一个小建议就是不要太关注阅读量和点赞数，写的文章对别人有用，才是最有成就感的。至于除了阅读量和点赞数以外，还有什么指标可以衡量一篇文章的好坏，欢迎大家留言讨论。 2. 文章要长长长长长长长长长长长长长长长（也别太长）我翻了几篇阿里技术公众号里阅读量较高的文章，各种话题都有，风格差异很大，但是有一个共同点：文章写得很长。这并不代表文章写了很多字就是好文章，背后的真实含义是：好文章的内容足够丰富。 内容丰富详实，这是一篇好文章的必要条件。还有一个条件是要包含真正有价值的内容，不能含太多水分。 提供一个小技巧：如果你写了一篇文章但是觉得内容很单薄，可以先当成一篇笔记存起来，等有了更丰富的积累之后再整理成文章。扩展文章内容的方法，并不是添加无意义的空话套话，而是根据文章探讨的问题延展开来。 比如说介绍自己解决的一个老大难 Bug，可能真正修改的代码并没有几行，把过程讲出来也不过寥寥几段。这时候你就可以再分析一下 Bug 存在的原因，为什么一直拖到现在，再思考一下如何避免这类问题，遇到同类 Bug 怎样快速排查。这样自己想问题的角度更全面了，文章内容也更丰富了。 比如你想介绍一项自己在学的新技术，发现自己写的东西其实就是官方文档的简化版，去重之后几乎什么都不剩了。这时候不要再继续抄文档了，把自己的思考总结先记下来，继续学习技术，持续记录新的内容，有更全面的了解之后，再写文章。 3. 清晰的叙事结构优秀的技术文章，结构一定是清晰的，有可能目录就代表了某个技术体系，或者代表了解决问题的思路。 优秀的内容 + 清晰的结构 = 好文章 能把技术问题讲清楚，就很考验表达能力，这是大部分程序员比较欠缺的。对于技术类文章，常见套路也不多，我简单介绍两类吧：
4. 线性叙事，逐步推进对于这类文章，读者是应该按顺序一段一段看的，写的时候脑海中模拟读者的视角来写。这类文章的小技巧就是：模拟读者视角，设定一条主线，有节奏的向前推进。和讲故事差不多，每一步的推进要有逻辑，要保持思路不要断掉。 有时候稍微加点趣味也是不错的，比如 《Flutter Widget 和 CSS 布局原理 PK》 这篇文章，目标是分析 Widget 和 CSS 的设计差异，我把文章写成一场比赛，先介绍参赛选手，然后分了 5 个 Round 开始 Battle，然后是 Love&Peace，最后一个 Happy Ending。 另外一篇 《记一次完整 C++ 项目编译成 WebAssembly 的实践》 介绍了自己尝试新技术的心路历程，先介绍背景，再分析需求做拆解，然后讲尝试了什么方案，遇到了什么坑，又继续试其他方案，最终是什么结果。读起来比较流畅。 5 结构化叙事，层层展开除了按顺序看的，还有不按顺序看的文章吗？有的，尤其在专业的技术文章里很常见，大部分是“总-分”的结构，先讲整体框架，再分章节介绍各个部分。 比较常见的是那种总结型的文章，比如 《平台建设的7大问题：蚂蚁AI平台实践深度总结》 和 《救火必备！问题排查与系统优化手册》 ，就是翻阅性质的书，可以通读一遍，也可以只看其中一段，之后遇到相关的问题，根据目录跳着阅读。 对于文思泉涌的人，可以一口气把整篇文章写完。但实际情况是，很多时间被碎片化，可能还要引用一些专业内容，可能需要查资料，写文章的过程会被中断。这类文章不是一口气写完的，是先搭架子再填充完整的。其实写起来也很简单：先想好标题，再划分好目录结构，再一段一段的填充内容，最后再润色一下连接部分。文章可以不按顺序看，也可以不按顺序写。 （编辑：南通站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
