如何搭建文章结构——常见技术文章的逻辑框架
不知不觉,写博客 6 年了,在写博客的这些年里面,其实更多的是在技术上不断地学习,对于写作本身的总结,更多的体现在了文章本身的改变,而我还没有自我总结过一篇针对于技术写作的博客,正好最近有着这样的机会,需要做一个这方面的分享,下面就是分享的内容的讲稿,也正是我对于这些年写作的总结。
无论你现在处于写博客的什么阶段,希望下面的内容能帮助你这些:
- 逻辑清晰、快速成文
- 吸引读者、正向激励
开场白
输出倒逼输入
作为一个技术人,我们往往都沉浸于技术的海洋中学习。 在学习技术的过程中,我们不断的在输入知识,同时我们也需要关注输出。 输出是也一种学习的过程,无论是写博客、写文章、写书,还是做分享、做演讲,都是一种输出的过程。有时输出是你坚持学习的动力,有时是你巩固和总结学习的过程,有时是你向别人传递知识的方式。”费曼学习法” 其实就是输出的一种形式,它的核心思想是:如果你想要学习一件事,那么你就需要把这件事教给别人。
说到输出,其中一个非常重要的技能就是写作,写作是一种思考的过程,也是一种沟通的方式。 在写作的过程中,我们需要考虑的问题有很多,比如如何取标题、封面配图、如何搭建文章结构等等。
我也是一个技术博主,在写博客的 6 年时间里面, 我也不断地在积累和思考,如何去更好的写作。今天,就围绕着如何搭建文章结构,我将一个开发的视角分享一些我自己的经验和思考,希望能够帮助到你。
当然,下面的分享针对与文章、博客类型,对于书籍或是论文的写作有着更加专业的要求,这里就不做过多的讨论。 由于本人对于后端的知识更加熟悉一些,所以文章中具体的案例会偏向底层一些,但不用过多担心,你只需理解抽象的概念,具体的案例我相信你也就能理解了。
为什么要写好?
我相信,你既然看到了这里,一定已经解决了第一个问题,为什么要写。我觉得无论写作的内容是什么,只要你踏出第一步,那么我就觉得你比许多人要成功了,因为你已经开始了,而不是一直在想要开始。那么我主要来讨论为什么要写好。
虽然说技术文章,不像写散文、记叙文,需要华丽的词藻或者是一些倒序插叙的写作手法,所以我们常常看到的就是非平铺直叙。但并非说它的行文就可以没有章法。
有人可能会说:技术文章的重点不应该是内容吗?
没错,当然!技术文章的内容往往是吸引人的关键,作为一篇技术文章,别人想要读的前提就是他对你说的这个知识不了解,或者是对于你说的这个问题没有答案。所以我一开始就觉得,只要我的文章中有你想要的答案,就可以了。
但是当我拜读了许多的文章之后才发现,原来不是这样的。厉害技术文章不仅仅是内容,逻辑框架非常的重要。逻辑框架清晰的文章能让读者迅速理清思路获得知识,同时还有以下几个好处:
好处 1:方便回顾
技术写作的其中一个目的,应该是自己对于一个技术或者知识的当下理解,它很多时候承载了你的笔记这样一个功能。所以,当几个月或者是几年后,当你想要查询当时的解决问题的思路时,一个好的逻辑框架能非常快速的帮回忆起你当时的想法并找到答案。
好处 2:建立正向循环
写作写好的另一个巨大好处,就是能够获得读者的认可,当你的文章容易被别人阅读的时候,别人才会给你更多的意见和建议,这样的建议往往能促使你更好的写作,从而形成一个正向循环。写作 -> 建议 -> 写的更好。
好处 3:快速创作
有时候,当你想要写作时,往往只是一个念头或者想法,想要成文,还需要花费很多的时间。你需要围绕你想要写的主题,来构思整个文章的前因后果。而一个好的逻辑框架能够帮助你快速的把想法转化为文字,从而快速的创作。 有了一个好的骨架之后,你只需要不断填充,一篇逻辑清晰的文章就能迅速成型。
我经常会使用的一种创作思路就是,积累+总结。比如,当我对于一个新的认识有自己的看法时,我马上将它在笔记上记录下来,然后再一周内不断地积累相关联的知识、背景、资料等等,最后再周末的时候将它们整合到一起,从而形成一篇文章。因为很多时候当前你对某个知识的理解是片面的,不完整的,在寻找相关资料的过程中能让你对它有更加深刻的理解。
而在最后整合和总结的过程中,就需要用到我们下面要讲的逻辑框架了。
问题提示
提出问题不仅仅是为了吸引读者
第一个框架,也是我最常用的一个行文思路,就是提出问题。 许多的技术文章并非写的不好,而是没有一个好的逻辑框架,导致读者在阅读的过程中很难理解作者的思路,从而导致文章的阅读完成率很低。
而针对与技术文章,特别是一些困难的技术分析文章,往往就会有一个问题,就是我看着看着,就没有办法理解这个知识了,或者说我看完就看完了,但好像又没学到什么东西。
那么,或许使用问题提示法就能帮助你解决这个问题。
框架
- 提出问题
- 解决/回答 问题过程
- 总结和提升
你肯定会说,这么简单?这不就和我现在写的事故分析报告差不多吗?先列举问题,然后分析问题产生的原因,如何解决防止下次出现。
没错,很多时候简单的东西往往容易被人忽略使用。最关键的是它能用在何处?
举例:源码分析
如果,你对技术比较喜欢,对于一些开源的技术实现,学习源码往往能让你快速理解这个项目,并且能学到很多编码设计上的技巧。所以源码分析类的文章也挺常见,但是许多文章有一个一致的问题,他们的文章大多数就是将代码的跳转路线告诉你了:
入口在哪?从那个方法进来,到那个方法去,这个方法是做什么的…. 等等,当你看完之后,你就会发现,你剩下的几乎没有,回过头你发现你等于没看。或者是当整个项目非常复杂的时候,往往方法和类的扩展很多,导致你看到最后,你都不知道在哪里了。还不如自己运行代码,跟着断点调试来的方便。
那么,文章的问题出在哪里呢?我们要如何使用这个框架改进呢?没错,合理的设计问题,也是在考验你对于整个技术实现的理解。比如你可以这样设计问题:
在阅读源码之前,你可以思考一下,如果是你,你将会如何实现它?
再比如:
为什么这个技术能处理的如此迅速?原因是什么?
然后,当你在叙述整个源码实现的过程的时候,你就可以时时刻刻围绕这个重点去阐述:
比如:这里数据结构的设计对于整个实现是有很大帮助的,如果我设计,可能无法想到用这个结构,以后可以用到
比如:你可以写,不要忘记我们的问题,关键在于如何迅速处理,没错,这里就是问题的关键,由于这里用了….技术…能帮助它更快的处理…
最后,不要忘记,在总结的时候再次回答这个问题,让读者一定产生:哦,原来是这样的感觉。
优势
那么使用这个框架所构建的文章就很明显,让你原本平铺直叙的文章有了一个主心骨,原本无依无靠的零散的知识点,都是为了这个主心骨服务的。
这样,读者在阅读的过程中就会时时刻刻围绕着这个问题去思考。即使当我们有很多很复杂的项目时,我们的问题也有有多个,只要围绕着问题去写,读者就能迅速将思维更上,从而不乱。
并且,就像前面说的,当你很长一段时间回过头来复习的时候,你不需要看整个文章,你只需要口述回答你最前面提出的问题,你就能迅速回忆起来整个知识点。
扩展
当然这样的框架并非只能用在源码分析的文章中,还有类似的还有分析框架、分析中间实现等等,都可以尝试用这样的框架去构建,会让文章更加清晰。
开门见山
即使直接上结论,读者也不会逃跑
在学校的时候,老师总是会告诉我们,写作的时候要有一个开门见山的思路,也就是说,你的文章要有一个明确的主题,而不是一上来就开始写,然后到最后才说,这篇文章是关于什么的。
而在当下,厉害技术太多了,很多人都喊着学不动了,躺平了。并且在短视频,这样短频快的节奏之下,已经很少有人能耐心仔细的看完你的文章了。
那么,反应到技术文章,大多数人追求的是什么?答案,他们只需要一个结论,其他的全部略过,知道结论仿佛就知道了全部,如果在文章中,无法迅速找到结论,那么他们会迅速切换下一个搜索结果。
这也是为什么很多时候在搜索英文报错的时候,很多人看着英文文章无法找到答案,无法解决问题,其实答案就在其中。那么此时,我们就需要用到这个框架。
框架
- 直接上结论
- 理论论证
- 总结原因
直接上结论,会不会导致读者就看个结论然后就走了呢?让我们慢慢往下说
举例:技术选型
很多时候,在实现一个功能或者一个需求的时候,有很多的方案供我们选择。常见的就是两个开源项目的是实现,或者两种技术方案的对比。当我们在做选择的时候,往往就会去详细调研两种不同技术的优势和劣势。又或者是只有一种技术,用与不用也是一种选择。用是因为什么,不用是有什么原因。
那么对于这样的文章,我们就可以尝试运用这样的框架去写。
首先,我们可以上来就直接说明,我认为:应该选择使用这个技术,并且我已经将之实践了。
然后,你就开始从各个维度进行论证,为什么:
比如从使用角度
从代码的实现角度
从维护成本出发
…
在论证中,最能给到用户肯定的就是数据,如果你能拿出你的实际测试数据来说话,会更加有说服力。
最终,你是在什么样的场景下,做出了什么样的选择。并且可以总结很多实践过程中,出现的问题。
优势
这样的写作框架与说明文的写作有着类似的道理,优势在于:
- 快速让读者知道你的观点
- 清晰的论证让你有足够的靠山
- 最终让读者清晰的明白你选择的场景,是否他有参考的意义
原因
很多人就会说,别人肯定会看了开头就走了。但其实实际并非如此:很多人其实在看文章的时候一开始都是大致扫一眼,去搜索他们想要的信息,而当他们无法找到信息的时候就会走。
而看了这个开头的用户往往反馈就两个:
- 同意你的观点
- 不同意你的观点
对于同意你观点的人,无非就两种,一种是已经对这个知识非常熟悉了,这样的人其实并不是你的受众,你这样做非常可以节约别人的时间。还有一种就是他同意你的观点,但是,只是他的一个个人想法,并没有人支持,那么他会继续看下去,找到你这样说的理由。
同样的不同意你的人也是类似的道理。抓住了用户的第一眼,很多时候就能绑住用户。
扩展
当然 技术分析、项目分析、优势分析,等等文章都可以使用这样的方式去写作。
铺垫基础
让你的文章满足更多受众
对于特别难得知识点或者问题,我们往往需要一些前置的知识来做铺垫,铺垫的好与坏直接就决定了文章的阅读体验。
我也经常在看一些底层技术的文章,对于同一个内容,有的文章阅读很顺,从头到尾,读完就学会了;而有点文章就很难,看完之后你还需要去找别的文章,最终拼凑出你想要的结果。
于是乎,有时,对于特别困难的技术说明类型的文章,我就会尝试采用这样的写作框架来帮助我。
框架
- 前置逻辑/知识储备
- 推导中间状态
- 最终得出结论
- 引用各类观点
举例:难点技术
这里的案例我实在是找不到合适所有读者的说辞,只能以具体的一个案例进行说明,我会尽可能用大家都懂的语言来解释。
“IO 多路复用 ”是一个非常复杂的技术难点,如果直接上来就告诉读者,它是怎么做的,如何实现的,然后贴一贴代码,这样很难让人明白。或者说不太友好
那么,如何去做铺垫呢?你可以从以下几个方面着手:
- 用户空间和内核空间
- 进程切换与阻塞
- 文件描述符是什么
- 标准 I/O 怎样的
然后,你就可以顺理成章的推导出 IO 多路复用的实现原理,以及和标准 IO 相比它的优势在哪?为什么要用它。
当然,在得出结论之后,我的建议,这样类型的文章,你想要提升,一定要给一些文章站稳脚跟的链接,并且对于一些知识点,你可以引用你之前写过的博客链接,这样不仅能缩短用户的寻找时间,还能帮助你其他博客的引流,也算是一个小技巧吧。
原因
对于困难的知识,很多人其实难以理解的原因往往是由于前因后果没有搞清楚,前置的基础知识没有掌握,你直接告诉它最终的结论,往往会很难让人明白。
优势
这个框架对于读者来说非常的友好,相当于新手和一知半解都能真正在你的文章中 “顺理成章” 。
而这个框架我特别喜欢的还有一个原因是:在写作的过程中,它帮助我去回忆起之前很多的知识点,帮助我在不经意间构建了整个知识网络,让我明白这个知识点在我的整个网络中处于哪一个节点,与之相邻的问题是什么。
扩展
这样的框架不仅适用于较难知识或技术的说明,我还发现在一些框架和开源项目的说明中有所体现,他们会直接引用一开始别人基础的实现逻辑,然后说明其中的问题,推导到他们升级的原因,从而说明他们新技术或者新设计的优势,整体下来一气呵成。
容易被忽略的注意事项
在搭建文章结构,还有一些别的注意事项,我想做一些提醒
不同平台内容量各不同
首先在搭建文章结构之前,你应该确定这个文章想要发布在什么地方。在不同地方发布的时候,内容量是不一样的。我经常能在一些公众号的推文标题看到 “万文长字,分析 xxx 技术” 又或者是 “看这一篇就够了 xxxx” 然后点进去哗啦哗啦非常的长,在手机上观看极为不友好。
所以,针对与不同的平台,你在设计的时候需要考虑内容的不同,当内容过长时进行拆分。比如,针对一个特别系统的设计分析,你可以拆分成专栏的形式进行谋篇布局,将原本的内容拆分成为几个小部分,然后在前后增加衔接的内容,从而形成一个体系。
我在写博客的过程中,也经常会分析一些成体系的内容,将他们拆分后归类到一起,对于读者来说更加友好,每次看的不多,理解没有负担,而又在一起,相互只有有联系。
代码如何展示更优雅
不要截图!不要截图!不要截图!
重要的事情说三遍。我一开始写博客并且到后面有很长一段时间都是在截图,特别是对于一些源码分析。当时的想法是,截图一张图片能放下大段大段的代码,不用占用很多篇幅。直到有读者向我反馈问题:图片看起来有时候不清晰,太小或太大,最大的问题是无法复制粘贴,没有办法进行搜索。所以,从那之后我就基本告别截图了。
开源有外链
如果是对于开源的代码分析,记得加上外链,能方便用户迅速定位到代码段,找到原始方法进行追踪。
可运行的教程要完整
如果你给出的是一个教程或者一个可以运行的完整示例,请一定要保证完整性。我无数次会发现从网上拷贝过来的代码无法使用,而一些博客没有留言功能,最后一点点写才发现,哦,原来对方忘记上传了其中某个方法的实现,而这个方法非常关键….
开源代码分析可缩量
针对于开源的代码,没必要整段整段的拷贝,一方面确实篇幅太长了,占用了文章大量的资源。并且读者不好阅读,其实我们在分析代码的时候往往抓住的是主线,所以其中没有围绕主线的部分你可以手动删除并做注释,缩量之后会让整个结构更加清晰。
总结
当然,说了这么多,对于写作的框架还有很多,这里只是列举出我现在常用的一些,希望对你有所帮助。当然,写作框架固然非常重要,但是它需要你慢慢去总结和摸索。所以对于不同的人来说,我给出以下的建议:
- 刚开始写作的同学:无论是什么,只要你去写就好,尽量追求易懂。
- 写作了一段时间的同学:请尝试运用一些技巧和框架去让你的行文更加流畅,让你的文章能被更多人点赞。
- 写作了很久的的同学:慢慢积累自己的写作思路,建立起成熟的体系,形成自己的风格,能快速建立你形象,从而收获越来越多的粉丝。