做者 | 许晓斌 来源 | 阿里巴巴云原生公众号程序员

写做动机

咱们为什么写做？对于许多技术同窗来讲，写做是一件比写代码困难许多的事情，和电脑相顾无言数小时，发现本身写不出什么像样的东西来，着实不是一种很好的体验。即使对于有些经验的人来讲，写四千字质量尚可的文章，我估计也要花 6 小时以上的时间，这还不算平时素材积累的时间消耗。spring

这么费事费力的事情，为何要去作呢？我认为此事有着极大的价值，这个价值分两层，我暂且称之为表层价值和深层价值。编程

表层价值是极其功利的，例若有同窗想晋升，而晋升的一项指标是我的影响力，那么写文章就能提高我的影响力；例若有团队 Team Leader 想招聘，那怎么让别人了解你及你的团队呢，写文章也是个不错的方法；再有一些就是冲着上级或者利益相关方写的文章，以相似项目汇报的方式写的文章。表层价值的核心关注点其实并不在文章自己，而在于文章背后的人，做者对读者的指望每每不在于读者承认文章内容，也不指望读者参与对内容的讨论，而仅仅是指望读者快速地承认做者这我的。网络

只关注表层价值去写文章，很是的本末倒置。就比如写一篇讨论 PM 2.5 的科普文章，若是你一上来就冲着推销本身的空气净化器这个动机去写，其恶臭很快会从字里行间流露出来。架构

与表层价值相对的，我认为任何一篇文章都应该从深层价值出发。这个所谓深层价值就是文章的内容，文章的观点，文章须要尽量地客观，要向学术真理的态度逼近。写一篇文章是由于对一个问题有着本身的思考，而且去详细了解了不少人的思考，发现了一些观点的冲突，而且不会为了政治正确去迎合别人的观点；尽我所能把那些我认为有价值的想法，总结下来，用清晰、有趣的方法传播给他人；我能体会到写做的热情，这种热情来自于思惟的乐趣，来自于观点的碰撞。这个写做的过程，本身的思惟有成长，经过大量的逻辑思考，个人思惟获得提高；其次写出来的文章，对读者有着很高的价值，由于有价值的知识获得了传播。app

还有一种写做动机就是想要传播有价值的技术，例如 Pivatal 公司的布道师 Josh Long 就写了大量的技术介绍文章，也有不少精彩的演讲。我曾问他为何可以作的如此出色，以至于多年被评为全球 Java 领域最有影响力的 20 人之一。他的回答是这样的：编程语言

I think that people don’t trust technology, they trust people. So, while it is possible that the spring team could just publish good documentation and leave it for the world to find, it’s far more compelling when u feel u can ask questions of someone. And u can see that they’re having fun.I love Spring because it has made millions of lives easier. It makes me happy to think about its application, to see people happy with its possibilities.工具

一篇文章写出来，是由于做者喜好一项技术，从心里承认技术的价值，相信技术的潜力；仍是由于做者想兜售什么东西。这二者动机的差别，稍微细心的读者很快就能发现。固然，上述动机常常混合在一块儿，可是若是写做的主要动机都在表层，那么基本上这样的文章也就没什么价值了。性能

影响力

Josh 是 Java 领域在全世界有影响力的人，他经过演讲，写书，博客，影响着全世界数百万的 Java 程序员，帮助了 Spring 等优秀的技术在全世界的推广。我写了一本关于 Maven 的书，这本书也得以卖书了几万册，再加上盗版 PDF 的数量，那是影响了全国十多万的 Java 程序员了，帮助了 Maven 这一技术在中国的推广。我加入阿里 8 年多，在内部技术社区 ATA 发表了 60 多篇文章，累计的阅读数大概也有五万以上，我相信这些文章也给阿里的技术带来了一些微小的正面改变。从这些角度看，写优质的文章虽然耗费很大的精力，可是因为其很是便于分享传播，所以可以快速地影响许多人，并且这种影响可以持续的存在。学习

固然时代在改变，之前因为网络技术的限制，文字的传播比较方便，视频的制做及传播成本比较高，所以演讲的实际影响力相比文章和书籍会弱不少。而今天的网络和视频技术已经很是成熟，制做高质量的视频也许更容易传播了。

文章也好，视频也好，影响力应该是被用来作正确的事情。今天控制影响力的不少流量入口，已然造成了一种新的权力，他们能控制什么声音容易被你们听见，什么画面容易被你们看见，什么文字容易被你们阅读，什么态度容易被你们感觉。权力的造成进而演变成了权力寻租，而后这个事情就每每和所谓“正确的事情”无关了。

经过影响力作正确的事情，我以为最好的例子就是张瓅玶（花名：谷朴）的这两篇文章了，第一篇是「API 设计最佳实践的思考」，第二篇是「警戒复杂度困局：关于软件复杂度的思考」。文章的内容都是工程师喜闻乐见的关于软件设计的深度分析和思考，但我以为在这个例子中，比内容更重要的是这两篇文章中传递了一个很是重要的信息，那就是，“在阿里巴巴，即使是研究员级别，也是有人在仔仔细细认认真真看技术的，那些层级更低的却早已脱离一线的，张口闭口都说技术只是细节的管理者，见鬼去吧。”（固然，这个信息只是我我的观点，不能表明谷朴）

写做方法

咱们的基础教育彷佛在写做的培养方面颇有问题，我印象中市面上常见的那些优秀做文选，每每都是注重形式和套路，每每缺少逻辑和观点，用一个成语总结就是“无病呻吟”，什么事情都要拔高抒情，以小见大，最终的结果就是假大空成灾。你们总体的基础已经薄弱了，而从事技术工做的同窗，每每在读书的时候语文仍是个弱项，那么结果就可想而知了。写出来的东西，要逻辑逻辑不严密，要形式形式乱糟糟，基本的分段、标点、用词更是问题颇多。好在写做这个能力不是只在学校才能训练的，工做中也能够训练，并且明显有章可循。

1. 阅读量

郑子颖（花名：南门）在他的文章中强调了“多看”的重要性，他用豆瓣记录了年均 50 本以上的阅读量，这至关于平均每周至少一本书，这是一个比较很是惊人的数字。我回顾了一下本身的豆瓣记录，阅读量大概是他的一半，也就是年均 25 本的样子。阅读的益处自没必要说，我这里想强调的一点是，不断阅读优质图书能提高本身的文字鉴赏力，书读多了，拿起一本翻翻目录，其中找几个段落读一下，对于此书的质量，内心大概就有个谱了。本身写做的时候，其实大多数时间也是在参考现有例子的结构和方法，若是你照着大量优秀的案例学习，那么天然也不会差到哪里去。

我在写《Maven 实战》以前，阅读了大量的 O‘Reilly，Pragmatic Bookshelf，和 Manning 的计算机图书，这些公司出版的图书大都有很是高的质量保证，在介绍技术的时候，有清晰的由浅入深的结构，辅以大小适中的案例，以及不枯燥的理论分析。能够说，我就是参考着那些优秀的书籍的写做结构和写做方法，写了本身的书，最终个人书也获得了总体不错的评价。

除了写做方法上的受益，阅读更重要的是从内容受益。再举例来讲，我在「如何作好技术 TL」这篇文章中，提到了本身在作 TL 的这些年阅读了好多本讲管理的书籍，包括《赢》、《驱动力》、《门后的秘密》、《非暴力沟通》等等，这些书籍极大程度上帮助我补充了本身的思考脉络。写做即思考，而思考不是凭空出现的，思考须要原料，常见的原料就是咱们实际的工做经验，然而一我的的体验毕竟是很是有限的，而阅读他人的体验及思考，以谦卑的态度为本身的思考提供更多原料，显然是明智的作法。

「如何作好技术 TL」收到过一条颇有意思的评论，评论是这样的：

我的认为管理相关的书籍都是鸡汤，没必要看，若是须要靠着“教你怎么作管理”的书才能作管理，那么说明这我的不适合作管理。

这句话隐含的意思是，有些知识，例如管理的知识，是没法传承的，只能靠本身天性领悟。对于此评论，我只能说无知者无畏了，咱们写文章必不可持有这种心态，即使本身的想法有多么独特、多么原创，也必定不能自建藩篱，坐井观天。

2. 素材

我最近一年一直在作云原生相关的工做，期间我一直在思考，到底什么才是云原生架构，目前行业里对这个词有很是多的解释，可是全部这些解释都无法给让我满意，它们都过于偏重技术和云厂商的视角，而缺少应用架构的视角。对于这个情况，我想基于过去一年，以及将来的相关工做，对云原生架构这个概念写一些东西，对其概念作一些补充阐述，帮助你们更好的使用技术，文章还没写出来，可是动机就这样造成了。

有了这个动机，再结合我本身我的的一些兴趣，过去一年我一直在积累素材，这些素材很是有意思。例如，我直接深刻参与了国际化中台和考拉的项目，他们的架构基于云原生的技术，以及许多阿里云的产品，作了很是大的升级；我也详细了解了菜鸟如何在云上构建平台服务他的合做方公司；学习了解钉钉、IoT 这些自己在公有云上售卖服务的部门，自身是如何在云上架构。我经过 IM，电话或者面对面的方式和相关的同窗沟通，他们都很是友好地知无不言，而后我整理相关的材料，再从中分析相同的模式。人脑很是喜欢模式识别的刺激，我在作这些事情的过程当中也是乐在其中。除了实际的案例，行业资深人员的观点也是我平时收集素材的来源，例如林昊（花名：毕玄）最近写了一篇名为「云原生的进一步具象化」的文章，他们的文章一般不会人云亦云，仔细阅读会发现一些比较原创的观点。

除了上述和目标主题关联度很是大的素材外，我还发现跨学科的阅读也每每会给本身带来意向不到的收获。仍是以云原生为例，虽然我在这个领域工做，可是最近一两年我一直在断断续续的阅读一些经济学的书籍，包括曼昆的《经济学原理》等（我估计好多人买了这套书了，可是真正认真读完的非专业人士仍是比较少的）。在学习经济学的思惟方式时，我就想从经济学的视角去解释云原生这个事情，本来自建的技术基础设施，在云的时代在逐渐演变的基于云的基础设施，这背后的选择对于业务来讲，从经济学的角度应该怎样去分析？自建的成本和效用是什么？购买的成本和效用是什么？将复杂的业务技术架构拆分红一层一层以后，或许能够逐层分析，在每一层作一个从经济学角度最优的选择。

3. 思惟导图

我最先了解思惟导图是由于读了「Pragmatic Thinking and Learning」这本书，书中介绍思惟导图的核心用途是把一个主题相关的全部内容，不管重要次要，都在一个图中写出来，那些不断拓展延伸的线，不是为了构成一个清晰的结构，而是为了给大脑显示什么地方思惟能够进一步拓展。所以画思惟导图的方式应该是尽可能开放自由，目标是把主题相关的内容所有展示出来，思惟导图的目的不是创建清晰的逻辑结构。所以，当我看到不少画的思惟导图其实是一个目录的时候，我以为他们基本都用错了。

写文章（作演讲也是相似的），都是一个先开放后收敛的过程，在前期不断积累素材，使用思惟导图拓展思惟，创建材料的关联，就是开放的阶段。这个阶段中能够适当让逻辑思惟退到幕后，把目光打开，不要过多评价（创建结构，分主次其实就是一种评价），用一种相似空杯的心态去倾听和观察现实世界及他人想法。我在作演讲或者作文章以前，总会先找个安静的地方，准备好咖啡，打开 MindNode，或者直接找拿出 A4 白纸和笔，给本身半小时到一小时的时间，把主题相关的思惟导图画一画。安静免打扰的环境、没有时间的压力、富有精力的大脑，这些条件放在一块儿，才可以让本身从手头事务的聚焦中移开，让大脑中平时得不到关注的意识浮现出来，而后落到纸上。

4. 结构

将大量的材料胡乱堆砌在一块儿做成文章天然是不行的，做品必然要有一个清晰的结果。在建筑中，咱们耳熟能详的有古希腊建筑的柱式结构，也有哥特式建筑以尖拱券、肋拱、飞扶壁等要素为核心的结构；在程序中，常见的 MVC、分层、微内核等模式也是清晰的结构。文章的结构能帮助做者把本身的观点清晰地表达，引导读者在清晰的路径中阅读。在有了思惟导图以后，我一般会从那些纷繁复杂的材料中提取出一个最合适的结构，而后再基于这个结构组织材料。

写技术文章仍是有一些常见的结构的，如下是几种范式：

• 解决问题型结构。这种范式一般围绕解决一个具体问题出发，常见逻辑是：背景介绍 -> 提出问题 -> 讨论解决问题的思路 -> 解决问题 -> 价值总结。这种结构多是工程师最熟悉的了，由于你们都擅于解决具体问题。
• 知识介绍型结构。这种范式一般用于新技术的介绍，常见逻辑是：行业背景 -> 技术提出 -> 简单 Demo -> Core Conecpts -> 概念深刻及 Demo （1-N次）-> 前景分析。你们平时看到的不少技术介绍文章一般使用的是这样的结构，这样的结构的好处是能够由浅入深地介绍新技术和新概念。
• 观点输出型结构。这种范式相较于前面的两种会更有挑战，常见的逻辑是：整体观点 -> 子观点 1 -> 子观点 1 阐述 -> 子观点 2 -> 子观点 2 阐述 … -> 总结。这种结构的文章写好了力度是很是强的，可是写起来很是有挑战，由于观点的阐述须要丰富的素材以及严密的逻辑推导，稍有不慎就有胡扯之嫌。

固然，咱们在写做的时候没必要拘泥于这些范式，也能够琢磨本身的范式，但不论何种范式，背后老是存在一个有逻辑关系的结构的。有一本书叫「金字塔原理」，我听到不少人推崇（尤为是在绩效季的时候），我看了下介绍和评价，讲的就是如何用高效地方式让对方理解你，我没读过这本书，但应该就是讲行文的结构和逻辑的，有兴趣的同窗能够买来看看。

5. 观点

不是全部的文章都有观点的，例如你写文章总结本身如何解决一个性能问题，不必定须要有观点；介绍一项技术，如 Rust，不是非要表达观点。可是可以表达本身观点的文章一般会更有吸引力，例如解决性能问题的时候强调理解排队论的重要性，这就是一个观点，容易让人印象深入；介绍 Rust 的时候，断言其在性能敏感的场景将来会占据统治地位，也更容易让这门技术吸引人的目光。固然，观点是须要论证的，其坚固性和你论证的投入度成正比，逻辑推导、数据支撑、案例分析都是很是好的论证手段。

咱们也看到有一些文章满篇观点，但基本都是引用，一会是乔布斯，一会是张小龙，一会是马云等等；固然，更常见的是引用公司高管的话，谁谁谁在何时说过什么等等，而后用这些内容来支持本身的材料。我以为偶有引用无伤大雅，老是引用就只能说明本身没有观点，或者观点无力，须要强力给本身支撑。

更有勇气，能体现本身素材丰富，思考深度的观点，反而是那些勇于说出皇帝的新衣的文字。技术文章应该是具有科学精神的，科学是基于对过去不断的 say no 发展出来的，技术文章也应该勇于表达 say no 的观点，不用怕得罪人，咱们应该明白，正确的技术/架构/方案，应该是经得起质疑的，由于若是技术是错误的，即使当下环境没人敢质疑，时间长了，现实会让错误须要付出的代价呈指数倍上升。所以，相比于通篇正确的废话，勇于对现状 say no 并提出本身反面观点的文章，更值得推崇。

6. 故事

严格来讲，给本身的内容添油加醋的整故事，对于逻辑论证没有任何帮助。然而要让本身的文章/演讲有吸引力，故事的元素是必不可少的。人类进化到今天，大脑对逻辑的反应是很是慢的，并且须要通过训练后才能理解逻辑，可是对于故事的反应，三四岁的小孩就有，人类早期流传下来的精神，例如希腊神话和圣经，都充满了精彩的故事。直至今天，不管公司内网，仍是微博，你们对吃瓜的热情之高，岂是逻辑论证能点燃的。故事很容易引发人的共情，让人设身处地联想，而后大脑皮层就容易嗨了，神经网络被激活，各类激素开始分泌……

这是人类生理的现实，因此咱们写文章的时候要尊重（利用）这个现实。要讲一下程序性能很差致使身边的同事半夜 3:20 分电话惊醒了；出了故障致使超市收银机被砸了，介绍新编程语言的时候要秀一段代码，顺便搞个对比说 Java 不行；介绍 Mesh 的时候就要说你原来升级中间件得这么干这么干，之后不须要了，等等……

我介绍本身「Maven 实战」的时候喜欢讲一个真实的故事：

在我书出版的前些年，由于虚荣心做祟，我特别喜欢去各大售书的网站刷评论，什么亚马逊，豆瓣，京东啊等等，一条条的去看，看到 5 星评价就喜滋滋，看到低1星或者 2 星的就很生气，固然，大部分评价都是很正面的。直到有一天，我在京东刷到一条 1 星的评论，我就一边难过一边打开评论，但读罢我就乐了，那个读者打 1 星的缘由是这样的“让大家老板泡奶茶，差评！”原来是由于那阵子刘强东奶茶爆出了恋爱的新闻，伤了这位读者的心了，而后我就躺枪了。

这个故事其实和我在书中介绍的技术没有任何关系，可是我却喜欢讲这个故事，由于他会让听众会心一笑，而后记住我写过一本关于 Maven 的书。

烂文章是怎样的

讲了那么多怎么写好文章的方法，我也想说一下烂文章都长什么样。所谓烂文章，就是指那些对于读者来讲，几乎没什么任何正面价值的文章，更有甚之，不只没有正面价值，还存在负面价值。如下我稍做总结：

• 我的笔记成文章。本身解决了一个技术问题，作了一些记录，而后写成文章发出来了。这类文章充其量只能称之为素材，由于没有总结提炼，并且彻底是从一我的的视角出发写的，读者读起来，不只感受不到体系，有价值的部分更一般是少的可怜。
• PPT 贴成文章。做者在某个地方做了一次演讲，由于想传播给更多的人，所以就用贴图的方式整理成了文章，好心点的，在图片的中间在补充一些解释文字，就这么成文了。我先假设这个演讲自己的质量是不错的，有逻辑，有观点，有案例，可是即使如此，这样的所谓文章，其阅读体验也是很是差的。在演讲中，PPT 是辅助“讲”的，若是只有 PPT，那真正核心的“讲”的部分就丢失了，所以，更负责任的作法，应该是演讲者用丰富的文字把所讲，用清晰的方式写下来，而不只仅是那几页干瘪的 PPT。
• 用宣传战功的方式写文章。组织内部此类文章家常便饭，标题会带着不少常见的如“总结”，“年度”，“体系”，“反思”，“展望”等词，一般这类文章既没有体系，也罕见反思，其主要的目的是邀功。基本套路就是，写在在一年中作了不少事情，结果很是好，配几个看起来差很少的框框“架构”图，再直白点，就要上合影了。这类文章后面一般会有不少赞，但基本没有讨论，讨论个啥嘛？做者来邀功了，莫非你说他作的很差得罪人？从知识传播，促进思考的角度来看，这类文章价值几乎为零。
• 各种贴图成文章。相比用 PPT 贴图，还有用各类其余图贴成文章的，思惟导图直接贴，设计图直接贴，流程图直接贴，监控图直接贴，一顿看下来就是没见几行字。好的图，的确是一图胜千言，可是那也仅仅应该是点睛之笔采用，若是篇所谓文章全是图，就彻底看不出重点，也看不到体系。文字是很是有力量的，文字能够把读者拉入到做者的思考体系中，用逻辑和修辞去引导读者的思考。或概括，或推导，让本来隐蔽的知识展示；或雄辩，或幽默，让做者的观点闪光。写做应该充分发挥文字的力量，不是只有图才有架构，不是只有图才能体现思考，相反，图每每由于其不精确性，成为不少人掩饰其思考不足的工具。
• 正确的废话成文章。官话套话，动辄抽象到极高的高度，从公司战略提及，洋洋洒洒一顿分析，满眼就是最近被抨击得厉害的那类字眼，什么“顶层设计”，“底层逻辑”，“赋能”，“抓手”之类；若是找不到清晰的逻辑，就来个 1.0，2.0，3.0，4.0，5.0，6.0，反正主版本号加 1 就是比前面牛逼了，至于为何小版本号历来没人用，不知道，反正 N.0 就对了，直接 N 是不行的，直接 N.0.0 也是不行的。读罢这类文章你说不清楚哪里是错的，你惟一明白的就是这文章啥价值都没有，你又浪费了几分钟生命。