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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本日作者简介

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