软素质：如何写⼀篇技术博客-轻识

❝
⼀提到写作，我们中⼤多数⼈或多或少都会发愁，到底该怎么写，结构如何设计，如何破题，如何举例，如何博⼈眼球。⼯作中，我们写⽂档、写技术博客本身也是在进⾏写作。有的同学写的⽂档/博客图⽂并茂，条理清晰，⽽有些则就稍显逊⾊，总是或多或少存在各种问题。
那么，如何才能输出⼀篇有价值的技术博客呢？且听鄙⼈结合⼏年博客写作经验稍作总结，希望能够对你有所启发，抛砖引⽟。
❞

⼀篇技术⽂章的编写，主要从两⼤⽅⾯着⼿进⾏考虑，分别是：结构、内容。我们本次分享也会重点从这两⽅⾯⼊⼿进⾏，⾸先讲⼀下⽂章的结构是如何构建的。先看⼀张图，基本上刨除具体的内容和主题，单从结构上来说，我们主要从图中的这⼏⽅⾯进⾏考虑。

题材选择

⾸先是题材选择，先选定⾃⼰要写作的⽂章的题材，是针对什么问题的；给⼀个⼤的范围，⽐如说是：分析⼀个技术问题、分享⼀个新技术、对某个技术做宣讲、案例分析等等；

⽂章命名

对⽂章进⾏命名，写出好的题⽬，就是⽂章成功的⼀半，这么说并不是没有道理。如何对⽂章命名，是⼀个学问，缓存失效和命名是计算机科学两⼤难题, 放到⾮技术领域也同样适⽤，就好⽐给孩⼦起名，总是让爹妈焦头烂额，翻烂历史典籍，上下求索。这⾥给出⼏个参考的题⽬格式；

朴实⻛格

hashmap 的学习笔记

hashmap 原理&技术知识整理

正经⻛格

hashmap 源码分析

hashmap 的核⼼原理与应⽤

轻中度标题党

万字⻓⽂！带你从头梳理 hashmap 「（⾟苦了）」

吐⾎整理！！hashmap ⾯试题集 「（⾟苦了）」

⾼度标题党

⼀⽂带你彻底搞懂 hashmap 底层原理 **(失传已久的九阳神功秘籍吗？) **

全⽹最硬核解读 hashmap 底层原理 「(有核桃那么硬么)」

hashmap 看这篇⽂章就够了 **(我信你个⻤) **

贩卖焦虑标题党

今年三⼗⼆岁，还在被问 hashmap 「(........不易啊，真不易....)」

你知道现在的 hashmap ⾯试有多难么？「(不好意思，不知道)」

贩卖IP/TITLE标题党

阿⾥ p9 带你⼿撕 hashmap 源码 「(以前是P6，后来是P7，然后是P8，最后直接来个P9满地⾛)」

这 21 个刁钻的 hashmap ⾯试题，我把阿⾥⾯试官吊打了 「(求求你别打了)」

我个⼈倾向于就简简单单，稍微加点修辞，⽤陈述句⽅式命名，其他⽅式也不是不可以，但是搞多了容易审美疲劳。。。

⾏⽂结构

有了题⽬和题材，就需要确定⽂章的⾏⽂结构，这个结构⼀定程度上也反映出了作者的思考脉络。对于技术类⽂章⽽⾔，常⻅的⾏⽂结构为：总分总，总分。尤其是总分总，堪称写作结构通⽤利器；

叙事⻛格选择

接着进⾏叙事⻛格选择，通常来说，对于技术类⽂章，主要以说明⽂⽂体居多，我们⽇常阅读到的优秀⽂章、书籍本身其⽂体主要也是以说明⽂为主。因此模仿起来也容易得多；对于说明⽂⽽⾔，它的特点主要是：叙述严谨，对于内容的描写平铺直叙，较难以掀起情感上的波动，⽽且对于技术类⽂章，通常是为了介绍⼀个新技术，宣讲使⽤⽅法，深挖原理，通过说明⽂⽅式表现也能够增加⽂章的严肃性，对于问题的本质能够很轻松的定位。

⽐如这些⽂章，就属于严肃的说明⽂类：

❝
领域建模在有赞客户领域的实践
复杂环境下落地Service Mesh的挑战与实践
❞

当然也并不是绝对的，对于场景分析、技术科普类⽂章，我们也会使⽤记叙⽂⽅式进⾏表现。

⽐如通过场景中⼈物对话⽅式、通过场景还原⽅式，对⼀个问题进⾏引⼊，借助⽂章中⼈物之⼝进⾏问题的讨论和总结，通过情节来推动叙事，也不失为⼀种新奇的写法。

这种⽅式的优点是表达⽅式平易近⼈，不失诙谐，容易使读者带⼊，引发思考；缺点也⽐较明显，因为⽂章充斥⼤段故事情节，通过对话来推进技术的讨论，对于技术内容本身所占⽐例就少很多，不容易提炼出重点，不利于后续复盘学习，也就是存在理解成本。

总结来说，对于严肃的问题讨论、技术普及、原理分析，倾向于说明⽂；对于科普类、⼩⽩⽂、碎⽚时间阅读的⽂章，倾向于记叙⽂。

⽐如这些⽂章，就属于轻松的记叙⽂类：

❝
精通那么多技术，如何才能体现你的价值？
架构师写的BUG，⾮⽐寻常
❞

说点⼉私货，我始终认为深⼊学习技术，还是要以严肃、深⼊为主，轻松幽默、诙谐类的⽂章还是适⽤于碎⽚时间消遣，毕竟严肃的东⻄才是贴近本质的，诙谐的⽩话的，基本上都是拾⼈⽛慧，本身也不会太深⼊。「（可现实中往往这种⼝⽔⽂反⽽能够得到⼤量关注与阅读，严肃深⼊的技术⻓⽂却常常被冷落，可能这就是现实吧。但是技术的本质就是冰冷的，还是需要付出时间和精⼒去死磕⼀下的。）」

写作技巧

接着谈谈技巧相关的内容。

⾸先聊聊⽂章主旨/⽬的的抽象⽅法，我们写⼀篇技术⽂章，必然是带着⽬标来的，是要进⾏技术科普，还是想深⼊分析某个技术点，深挖⼀下问题核⼼，还是说要基于某个案例进⾏复盘讨论从⽽得出对后续有帮助的普适的结论。

选择好具体的⽬的，带着⽬的去进⾏⽂章的写作，能够使我们在叙述中不会因太发散⽽偏离重⼼。⽬的也就是语⽂课上常说的 “主旨” “中⼼思想”，有主旨的⽂章在全局上看是内聚的，每⼀部分都是为了主旨服务的。

如果阅读⽂章的时候总是觉得很散，或者说读不懂，不知道在说什么，那⼤概率这篇⽂章的主旨是不明晰的，⽽没有⼀个明确的主旨，是写作的⼤忌。

运用修辞

除了关键的主旨/中⼼思想，还可以适度的运⽤修辞⼿法，⽐如说通过设问的⽅式，促使读者进⾏思考，引起读者兴趣。常⻅的例⼦⽐如说：

❝
常有⼈说，⽤到了DDD分包就是落地了领域驱动设计。是这样吗？我可以肯定的告诉你，不是。
❞

⽐喻/类⽐/打⽐⽅⽅式，通过打⽐⽅的⽅式帮助读者进⾏理解，⽐如说：

❝
zookeeper之于分布式协调，就好⽐动物饲养员之于动物。
❞

反问⽅式，通过反问促使读者进⼀步思考，⽐如说：

❝
难道你不觉得这种思路对于提升系统性能有着显著作⽤吗？
❞

归根到底，技术⽂章也是写作的⼀种，我们在语⽂课堂上学到的技巧在编写技术⽂章的时候也同样适⽤。

内容编排

说完了结构如何把控，我们来接着讨论⼀下如何进⾏内容的编排。

「第⼀点是素材准备」，对于公司内部的技术博客⽽⾔，因为公司是业务优先，所以第⼀步，要先从实际的业务中抽象出来这个问题。也就是确定问题核⼼，对问题场景进⾏描述，对场景中的关键词汇、步骤进⾏提炼，划分问题领域的边界，如果能够提炼出通⽤模型的，提炼出抽象的问题模型；

如果这个问题它是⼀个新问题且没有⼈去解决，就可以尝试⽤新⽅法来解决。如果有不⽌⼀种⽅案的，按照⼀定的策略（如：重要性、相关性等⽅式）顺序罗列分析。解决完问题之后，还要在业务层⾯进⾏验证。

对于⽅案分析，有⼀个我认为的通⽤⽅法论：

先对⽅案本身的思路进⾏宏观概述
对⽅案中涉及到的关键技术点进⾏详述
通过demo、案例、实验验证⽅案的可⾏性
回归到问题域，结合具体业务场景，寻找到⽅案的切⼊点，并落地到业务场景中
根据业务中具体的效果，进⾏综合客观的评价。如果有多种⽅案，则对多种⽅案进⾏横向⽐较，包括但不限于成本，收益，复杂度等维度的⽐较；如果有反例，则可以进⼀步给出正例反例之间的对⽐，提出反思与警示
进⾏全局总结，对整个⽅案进⾏梳理，得出通⽤性的结论和反思，对全⽂进⾏收束

图⽂并茂

正如本⽂中⽤到的⼀样，技术⽂章因为专业性、问题复杂性所限制，仅仅通过语⾔、代码描述，较难吸引读者眼球。

⼤多数情况下，⼀图胜千⾔，因此合理的绘图往往能够提升表达效率。

我们在⽂章的编写中，可以通过引⼊图⽚辅助我们进⾏问题的分析，提升读者理解的同时还能够增加趣味性。同时图⽚本身对于写作者写作⾏⽂本身也有着积极的促进作⽤。

我们可以运⽤：流程图、泳道图、架构图、⽤例图、漫画脑图（思维导图）......等图例来为⽂章增加趣味性，辅助写作。

对于公司内部⽽⾔，多多使⽤学成的流程图、脑图⼯具，对于提升⽂档可读性有着明显的作⽤。

最后，我们通过⼏句顺⼝溜，再回顾⼀下写出⼀篇好的技术⽂章都需要注意哪些点:

❝
选题很重要（突出价值所在，明确问题域）
思路需清晰
⼤纲得明确
⾏⽂要流畅
叙述易⼊胜（论述平易近⼈娓娓道来）
⽂法可上⻢（使⽤修辞）
总结不可缺
❞

本⽂更多的是思路/⽅法层⾯的分享，具体如何运⽤这些策略去知道写作，就需要我们在实际过程中不断运⽤与反思。

⽂章中提到的也并⾮都是对的，我们最终应当形成⼀套⾃⼰的⽅法论，使⾃⼰的⽂章独具特⾊，别具⼀格。