欢迎光临亚游平台官网,亚游会游戏平台,亚洲最佳游戏平台
亚游平台官网,亚游会游戏平台,亚洲最佳游戏平台 > 技术文章 >
技术文章
如何写好技术性文章?

  我( 帅气可爱魔理沙 - 知乎 )有的时候会在知乎专栏里面写文章,或者写回答,但是一般都耗时很久,比如往往要用12小时或以上。其中,大部分时间都花在把论据组合成段(并且在过程中移除用不上的论据),然后文章有时候(从一点跳到另一点)会有点生硬。 请问, 0:如何更高效的组合论据? 1:起承转合如何写流畅? 2:更一般的说,如何使文章耗时更短,写得更简练,流畅?

  谢题主邀请,我的文章目前只有很少的人看而且大多数都是我的好朋友,他们跟我说我写的还不错。

  那么我说下我写文章的路子。首先要有一个想写的东西,这种东西有可能是义务性地写(我博客的Kotlin/IntelliJ系列文章),有可能是突然有了新发现而写(矩阵快速幂斐波那契的矩阵数量与参数的谜之函数关系等)有可能是总结经验和踩坑记录,记录思想而写(解释型语言作用域实现等),有可能是自己写出了优雅有趣的东西而写(函数式dfs等)。

  这基本就是我写文章的全部契机,可以看到我不会为了观众写文章,我是出于自己开心的目的而写,然后才是让读者能够看懂。不然写着写着就不想写了。

  其次,我是个很爱幻想的人,我经常在脑中想象,我作为一个演讲者,给一群比我小的孩子讲怎么编程,然后就涉及很多比如如何组织语言,如何让他们更直观的理解概念,等。这样的思考有助于让人说话更富有逻辑性,我的班主任每次遇到说话扯不称头的人都会嘲笑他,如果我哪一天能成为值得尊重的,开玩笑不会被记恨的人,我也会这样的。

  比如我写过的MPS/IntelliJ系列,就有大量截图来确保读者操作跟我一致(而不是给出按键的步骤和用语言描述操作方法,歧义非常严重),而且就算软件版本更新,按钮位置变化,稍有常识(迫 真)的人也能根据旧版本的截图来摸到新版本的操作方法。

  而Kotlin教程等涉及语言的,就需要代码示例,尽可能写那种只体现一个语言特性的例子,不然读者会困惑,比如你跟读者讲啥是extension,然后代码用例里面搞一堆操作符重载,读者会嘤嘤嘤的。

  再者,外部链接作为参考和拓展阅读是好的,但是要求必须读的话,可能会让一些时间少的读者望而却步。

  我写博客还有一些注重的地方。比如,文章开头写,为什么我们需要xxx,为什么我选择xxx语言。文章结束写,你学到了什么。这些东西有助于读者系统地整理刚刚阅读获得的东西,也有助于写作者本身对自己进行反思。

  我现在写东西的文风和2016年截然不同,以前写东西还经常穿插一些无意义的嘤嘤嘤来掩饰自己实际上也不是很清楚自己在写什么的事实,但现在这种情况已经有了明显的改善,虽然废话最好还是有一些分布的,但是应该做到适度。比如我现在正在啃vczh的博客,他也会写一些情绪性的东西和少量废话,但我觉得读起来就比我去年的技术博客更轻松愉快。我自己读自己的博客也有这种感觉其实,但我真的没法评判自己写的东西的优劣,这不是我吹自己牛逼,我只是说我自己纵向对比觉得有很多提升。

  最后说说错误,我经常因为脑子发生segmentation fault或者StackOverflow而写错,但几乎没有人给我纠错。这就证明很多人看你的文章还是路人式的,所以遇到或者以及李登淳(艾特失败,傻逼知乎)这种真正会在读完后和你进行内容上详细的讨论的读者我会很开心,而且遇到一个关注一个。他们不少也是作者,我也是他们的读者,形成相互学习的关系后,就有了很纯粹的友谊,这也是我十分重视的。

  在我写《React.js 小书》(强势硬广,详情看签名,)的时候遵循了一些原则,因为这些原则得到了不少读者的正反馈。在这里分享一下。

  其实一篇好的技术文章,无非是两样东西:看得懂、能学到东西。其中要写得看得懂是难,很难,我在写的时候一直在苦苦思索这样的方法,怎么才能让你看得懂,而且最好是无痛看懂。最后可以让你做到不知不觉之中看完了,学到东西的同时还能轻松愉悦。当然我也做不到,这只是终极目标。但是我发现有几个原则是非常有用的。

  1. 确定好你要写什么内容以后就确定你的目标读者群体。了解你的读者群体是极其重要的一步,他们是怎么样的人,有什么背景知识(或者你希望你的读者群体需要什么知识),这些人需要什么思维方式(对某种事情需要拥有什么 sense)。这是极其重要的一步,最好是能够把你对读者的要求写在文章的前面,这样对你和读者都有好处(例如写 React.js 小书的时候我就要求读者需要掌握所有关于 ES6 的语法知识等)。了解目标群体就像产品经理了解目标用户需求,切身体会到了才能做出好的产品。

  2.从问题出发,带着问题一步步引出要讲解的内容。所有技术都是用来解决问题的,它的存在就是问题解决特定的问题。不要一开始就把技术内容、细节抛出来,要把问题先抛出来。你自己得先研究透彻,我需要讲的这个技术到底是解决什么问题的。然后在写内容之前,先把这个问题描述清楚。带着问题来讲解是最好的,这样读者就会中套了:“你讲得很有道理,好像确实存在这个问题,应该怎么解决呢?” 这样就引发了他们的思考,他们思考了后面就很容易灌输内容了。

  3.基于问题用逻辑推演引导内容。把问题抛出来以后就用思考问题的方式进行推演,一种类似于你跟朋友进行一个问题的探讨的方式。就像这么一个过程:“现在我得回家了,应该怎么回呢?” “打车吧,比较快”“但是好像也不是很远,我用个共享单车得了”“现在好像要下雨了,你还是打车吧”“我这里有一把伞..”。在你推进知识讲解的过程里面,就是解决一开始提出的问题,解决问题有很多方案,不同方案有不同的利弊,在权衡和优化的过程里面我们把解决方案一步步推向你需要给读者灌输的内容。每一步优化都是有一定的依据和推理的,每次推进一点点,就会让整个过程比较流畅。

  4.斐波那契原则。这是我生造出来的一个原则,简而言之,给读者的新内容要基于读者已有的知识。一开始对读者的知识储备是 (1, 1),你不能把 3 加进去,你得先把 2 加进去,(1, 1, 2),读者掌握了二以后就再把 3 加进去 (1, 1, 2, 3...),就像斐波那契数列一样,新的结果是旧的结果累加。所以为什么了解读者很重要,了解读者是什么样的一个群体,并且他们掌握什么知识,你讲内容的时候要基于他们已有的知识。让后慢慢地往读者的“斐波那契数列”加新知识,每次都是基于他们已有的知识。这样读者就不会有“这是什么鬼”的感觉,而是有一种“哦,这个我懂”的感觉。

  所以总结就是:了解目标群体,给他们抛出问题,通过逻辑推演引导他们思考解决方案,推演过程每一步都要基于用户已有的认知。这种方式有个坏处就是,写出来的东西非常精简,读者读起来也很顺畅,以至于他们很快就读完了(然后再也不回来了)。

  《React.js 小书》()就是通过这种方法写成的,当然前面写得还是挺顺,但是后面就写崩了(根据读者对不同部分的反馈总结),前三章节是评价最高的章节。

  我写博客的时间很短(几个小时一篇),但是我隔很久才会写一次博客。我一直认为,准备的时间越久,对知识的掌握越深入。

  譬如,我高一的时候,如果要我给别人讲“牛顿-莱布尼茨定理”,我会乱七八糟讲一些证明。虽然看上去很天衣无缝,但是这些话并不是很容易懂。然而讲课的目的、写文章的目的,不是为了显示自己的强大,而是让别人理解。

  在理解了这件事之后,再去了解牛顿-莱布尼茨定理就易如反掌了。(可惜,实际上这个例子并不是普通意义上微积分,而是“有限微积分”,详见《具体数学》)

  如果你面向的是国人,还是说母语为好吧。“二分查找”之类的有明确翻译的词,为什么要装腔作势一番呢:)

  多写写文章总有好处的吧。我喜欢看梁实秋、林语堂等人的文章,可能对我产生过帮助。

  我在自己的知乎专栏 《进击的React》上文章的时候,多是思考了一些事情,不吐不快,不写出来心里难受,这种情况下写出来的东西,自然抓住了上面这些点。

  至于如何如何组合论据,作为计算机行业的好处就是不用太多嘴炮,直接上Code说话,道理都在运行代码中。

  我个人观点,技术性文章并不等同于学术论文。学术论文要求十分严密的逻辑,要经受住各方面考验;技术性文章要的是给予读者启发,说明一个道理、一个观点、一种做法,没有必要耗费精力做到滴水不漏。实际上,在网络上发表的技术文章,无论怎么说都会引来反对意见,有反对意见没问题,但是写技术文章的

  至于写作时间问题,好的文章需要更多时间投入是必然的,我在《进击的React》一篇文章写大约两小时,但是为了构思这个文章,实际上投入了几天甚至几周几个月的思考。既然想写出影响人的作品,投入时间是绝对必须的。

  我的相关心得都整理在 GitHub 上:phodal/beautiful-content在线阅读地址见:内容之美 -

  看了看题主的专栏,发现这种写作方式和我日常是不一样的,题主的专栏多数是以研究性为主。研究性工作,多以深入某部分内容为主,写作性质和写书差不多。对于我而言,我的写作方式是这么几种:

  前三者可以让你在Google上有一个好位置,后者可以让你在用户心中有个好位置。

  第四种类型,没有大V的光环,偶尔文章被转企业V转转也能多个几十个粉丝。所以我没有第四种类型的文章太多的经验哈。

  因为我的日常主要是开发工作,不是各种研究性的内容,所以写起一篇文章来,也很快。按不同类型来说的话,大概是下面这么一些时间:

  对于我这种搬砖的工程师来说,日常技术文章的开头一般是,今天在做 xxx 的时候,遇到 xxx 问题,然后 xxx 怎么了,最后 xxx。