一篇好的技术文章应该是啥样子的

  • 杨赛

2013 年 8 月 13 日

话题:语言 & 开发

一直以来,InfoQ 中文站在国内的技术社区当中所处的位置还是比较独特的:说是媒体,内容运营的方式却似社区;说是网站,内容审核的流程标准却往杂志、图书出版靠拢。

今天早上在跟 InfoQ 的领域编辑评估一篇投稿,经验分享类的,领域编辑反馈的修改意见较多,基本上整个文章都要重新调整,作者就问我们,是不是会有自己想要反馈给读者的内容不符合 InfoQ 网站定位的问题。我的回复是:

就这篇文章的题材而言,InfoQ 的原则是

1、内容不能炒冷饭,如果前人研究过的,就不用再折腾

2、实践类内容不能引人走弯路。我们要确保传递信息的作者本身对相关方案的优劣都已经分析过,在他所在的情景下,即使选择的不是最优方案,也要是一个相对优化的方案,而不是 work 了,run 起来的方案就行。

我相信你们在实施方案的时候,肯定做过各种方面的权衡。我们作为编辑要做的,是引导你们把这个权衡的过程也暴露出来,好让读者明白,为什么你们会这么做,这么做相对其他方案有啥好处:)

同时,这也意味着,如果你作为作者无法 convince 编辑,让编辑认为你这样做是一种最佳实践,那读者就更难买账啦。

其实仔细想想,这两条说起来虽然简单,但真要做到,其实并不容易。要想不炒冷饭,先要知道前人都炒过些什么饭,这些饭都是啥味道;想要提醒读者哪些是弯路,往往是自己先走过很多弯路,即使有的公司里有很多“前人踩过的那些坑”的文档记录,但很多时候,绕坑前行的能力还是要靠大量的实战积累。

下面分享一下 InfoQ 深度文章的择选标准,如果大家对给 InfoQ 投稿感兴趣,可以做个参考(投稿信箱是 editors@cn.infoq.com )。

对于比较成熟的技术,如 Java、.NET 等,在内容深度上需要达到细分领域的极致。

对于比较新鲜的技术,如新的语言、框架、工具等,作者对新技术的了解程度需要超越大部分业内人士。

对于比较成熟的概念,如敏捷开发、DevOps,需要有实际的经验分享。经验分享类文章需求见下两条。

对于项目经验分享,项目本身需要足够成熟,即,较稳定的运转了足够长的时间,权衡过各种方案的适用性。

对于流程、团队管理类经验分享,团队 / 团队成员本身需要足够成熟,即,踩过很多坑并知道如何绕过一些坑。

对于比较新鲜的概念,作者需要是概念发起人或早期实践者,并且在该概念所属的领域有充足的经验,充分了解新概念与旧概念之间的差异。

对于好的技术内容这个话题,可以讨论的东西还是挺多的,比如什么样的技术算是成熟了,怎样的新技术、新概念看起来像是有发展前景的,怎样的实践算是最佳实践(这在团队管理这样的领域尤其难以评估),等等。这些问题虽然没有绝对的标准答案,不过也不是完全无迹可寻,还是有些经验可以说的。以后有机会,慢慢跟大家分享:)

本日作者简介

杨赛(@lazycai),InfoQ 中文站编辑。到处串门的互联网信徒,相信规则的力量。

语言 & 开发