本站由职业开发人员倾情打造,完美适应所有屏幕
当前位置:首页 - 文章教程 -

写一篇好的技术文章有多难?

写一篇好的技术文章有多难?

2019-08-27 01:14 作者:织梦园 围观:55

  就我而言,一年里我也没写出几篇让自己满意的文章。因为写一篇好的技术文章真的很难。

  注意:这里所指的技术文章,不是某个问题的相关回答。而是着重于一些知识要点、架构等等,复杂的文章。

  博客,光只是每天的用到知识点,那么一星期下来,怕是能记录满一本书。写篇文章可不像写代码那么轻松,首先要理清、整理自己的思路——为什么当时自己想的是 A 方法,然后才是 B 方法,又或者怎么找到 C 方法。如果能写下这个 Debug 过程,读者也许更能从中学到一些思想。而一本书吧,则是一系列相关的文章构成的合集,再加之以代码实践,以便于让读的人能更深刻的理解。写一本书的时间,可能是要上几个月,乃至几年的时间。

  将生产领域的代码知识整理成体系,那就更加的困难。如在我写电子书 《Serverless 架构应用开发指南》的时候,我几乎把能买到的相关中文书籍都买了,以及 Packt 出版社旗下相关的电子书。尽管只是一本托(reng)管在 GitHub 电子书,但是作为我的作品,它在某种程度上代表着我。

  写文章前吧,总是得把思路理清楚。技术文章嘛,归根还是在做学问,好的技术文章必然是实践出来的。与一般的八卦文章不一样的是,技术文章必然需要有数据、实践基础,而不是道听途说或者 Copy/Paste From Google。

  可是做起来并不容易,如我在写《我是如何为技术博客设计一个推荐系统》三步曲之前的文章时,大概花了一个月的时间,在设计这样一个推荐系统上。而为了验证文章的用词及算法准确性,又翻阅了一系列的文章和书籍,编写了两三个算法的 DEMO,最后才总算确认下了文章的大概。

  有了一个明确的主题和想法之后,我们就需要验证它的可行性。这就好比是有一些咨询项目一样,客户已经在心里有想法,但是还需要你去实现。如我在设想 “编辑-开发-发布” 架构时,花了差不多半个月去用 GitHub + Travis CI 构建一个 DEMO 应用程序。

  一般的代码验证,都还是蛮容易的。可是,有些验证则是感性的。譬如,我们要去验证 Windows、macOS 和 Linux 哪个更好用的问题,必是要找到这三个操作系统,亲自用上个把月的时间。才能知晓我说的: Windows 适合游戏与工程设计,macOS 设备进行设计与编程,Linux 用作服务器,这句话到底是不是对的?

  结论有了,那么证据也是要有的。这个时候我们就需要去证明:Mac 上没有多少游戏,又缺乏一些专业的工程软件。然后只得把相关的软件一个个的罗列出来,一对比。哦,结论真的是这样的,或者结论可能不是这样的。

  结论不对,评论区里就会相当的热闹。为了评论区的热闹,总会有些人抛出错误的结论,“PHP 是全世界最好的语言”。

  没有一篇文章能让所有的人觉得满意。试图去写一篇让所有人满意的文章,看上去四不像,结果又让所有的人都不满意。

  故,一篇文章应该着重于表达作者自己的观点,观点应该是有理论依据的,如 “为什么 Angular 更适合于大型前端应用”,而不是重复的表达 Angular 更适合于大型前端应用。如若不想得罪那些喜欢某个框架的人,在表达的时候需要含蓄一些。如我没有使用 xxx 开发过大型应用程序的经验,或者它缺乏这些 xx 的要求。

  讨论 PHP 是不是最好的语言,本身是没有意义的。我们只是想去说服对方,而去说服对方,证明自己是的。我们讨论的从来不是 PHP 是最好的语言,而是我的观点是对的。

  容纳别人的观点,并不是一件容易的事。多数时候,可能是我们无法站在对方的角度,因为我们想象不到对方经历了什么,比如说,贫穷限制了我们的想象力。

  成为键盘侠很容易,只需要接上网络即可。多数的论战都是没有意义的,了解一件事情的上下文很难,所以多数人懒得去了解。哪怕是你在文中反复强调了,也是如此。随后,哪怕是对方后来了解了,要在这个时候让他/她去承认错也很难。事件就变得越发的糟糕,失控就难以避免。

  争论的时候,双方都觉得自己的观点是对的,对方是错的。只要是有一方觉得,“咦,好像也点道理,但是应该试一试”,那么这个时候,争论就此结束了。

  良好的排版,语法高亮样式,这两个要素可以上我们披上专业的外衣。对于我而言,保持设计的一致性,而自定义了前端显示的样式。

  排版,它是一种细琐的活动,做好它并不容易。而针对于大部分技术人员来说(也包含我),天生缺乏这种美感。外加之,一般的技术写作都是先用 Markdown + Git 管理,随后再使用特定的编辑工具,如 Word、微信编辑器,最后再体验上容易出现平台的不一致。我则是使用自制的工具和主题,来统一不同平台的排版。

  配图。技术文章和长的文章类似,有一个不容易阅读的问题。改善用户阅读体验的一种方式是,在多个段落之间插入相关的插图,或许是可以起到视觉过渡的效果。考虑到版权问题,我开始自己去造图。

  代码语法高亮,技术文章往旆少不了代码来体验真理。故,代码是检验理论和架构的标准。在文章中穿插的代码,得对读者友好,而对读者友好的常见方式是:代码语法高亮。这也是我去年,写了自己的微信公号编辑器的原因,市面上没有支持微信公号语法高亮的 markdown 编辑器。

  高质量的文章,对于我来说,我的文章一直存在一个错别字的问题。但是,在不影响文章本身的阅读,它可能不影响文章的质量。可是关键时候,它往往还是影响了文章的质量了。

  以前总觉得呢,以后有时间去修改错别字,可并没有。但凡是说以后改的东西,在未来基本上是不会改。因为我们觉得,它是可以忍受的,因此优先级并没有那么高。只当我们聊胜于无,才会找一些事情出来。

  那些在 GitHub 的电子书经验告诉了我,读者往往才是那些更容易找出错别字的人。我大抵是已经习惯了,这个词语是怎么写的,比如说要分清楚怎么用连接、联接,并不是一件容易的事。大部分情况下,我用的是联接。

  Java 8、java 还是 j8,这个问题的答案我想大家都很清楚。作为一个工程师,要最大限度的保证用词的准确性。如 Java 8 指的是 Java 这门语言的第 8 代,java指的应该是 Java 语言的命令行工具,j8 是用来骂人的。对于其它语言、构架,如 Python、Ruby 也是类似的,python是指在 Python 命令行工具,可以进入 Python 语言的命令行械。

  追求阅读量,对于技术博客和技术公众号来说是一件可怕的事。出于同样的追求,未来作者可能会将技术文章变成技术八卦,因为只有热点和八卦才受人们的欢迎。为了流量和利益,追逐热点,无非只是将别人的观点,整理成文章,再看看读者评论里的回复。时间一久吧,怕是终将写不出有思想的文章。

  换而言之,有思想的文章并不是指文章有思想,而是能促进读者去思考。不可避免地,大部分人都已经习惯不去思考,因此也就阅读量下降了。

  大部分时候,我们并不关心东西南北发生了什么事,因为离自己太遥远了。人们一般只关心和自己及身边相关的事,或者一些可以用于聊天的八卦琐事。

  过去,我也追求文章的阅读量。在偶然间接触了 Content Strategy,我才意思到我需要高质量的文章。高阅读量的文章基本上都有很高的时效性。这篇文章过了几星期、几个月,可能没有一点儿的用处。而高质量的文章,往往不会有这个问题。

  当我开始理解高质量重要性的时候,我的思维发生了一些变化。我开始记录了成长过程中的一些变化,阅读量一点也不理想。可每当看到这些文章,会冒出一些新的想法。这些文章,大抵是未来的自己而写的。我不再去刻意地追求阅读量,开始提升文章的质量。

  于是,在平衡阅读量和质量的时候,我成了一个 “标题党”。好的标题,往往能提升文章的打开率的。

  嗯,多关注我的微信公众号(phodal-weixin),获取更多及时有用的技术知识。

  ❤️调伏身心:热敷、泡脚 ❤️布施之道:颜布施,微笑处事,微笑面对一切人和事;言布施,说赞美安慰的话;心布施,敞开心扉,对人和蔼;眼布施,善意地看着他人;身布施,以行动帮助别人;座布施,谦让座位;房布施,有容人之心。 ❤️经典诵持:诵读《晨祈》《六和敬》 《四无量心颂》《心...

  瓜藤果树旱鸭,木桥绿水农家,猫道清风竹马。骄阳晒下,庄稼人在田涯。 附马致远原词: 枯藤老树昏鸦,小桥流水人家,古道西风瘦马。夕阳西下,断肠人在天涯。

本文章的作者
本周阅读排行 文章推荐
友情链接
申请友链