论好文章和烂文章
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 设计最佳实践的思考」，第二篇是「警惕复杂度困局：关于软件复杂度的思考」。文章的内容都是工程师喜闻乐见的关于软件设计的深度分析和思考，但我觉得在这个例子中，比内容更重要的是这两篇文章中传递了一个非常重要的信息，那就是，“在阿里巴巴，即便是研究员级别，也是有人在仔仔细细认认真真看技术的，那些层级更低的却早已脱离一线的，张口闭口都说技术只是细节的管理者，见鬼去吧。”（当然，这个信息只是我个人观点，不能代表谷朴）
=========================================================================
我们的基础教育似乎在写作的培养方面很有问题，我印象中市面上常见的那些优秀作文选，往往都是注重形式和套路，往往缺乏逻辑和观点，用一个成语总结就是“无病呻吟”，什么事情都要拔高抒情，以小见大，最终的结果就是假大空成灾。大家整体的基础已经薄弱了，而从事技术工作的同学，往往在读书的时候语文还是个弱项，那么结果就可想而知了。写出来的东西，要逻辑逻辑不严密，要形式形式乱糟糟，基本的分段、标点、用词更是问题颇多。好在写作这个能力不是只在学校才能训练的，工作中也可以训练，而且明显有章可循。
郑子颖（花名：南门）在他的文章中强调了“多看”的重要性，他用豆瓣记录了年均 50 本以上的阅读量，这相当于平均每周至少一本书，这是一个比较非常惊人的数字。我回顾了一下自己的豆瓣记录，阅读量大概是他的一半，也就是年均 25 本的样子。阅读的益处自不必说，我这里想强调的一点是，不断阅读优质图书能提升自己的文字鉴赏力，书读多了，拿起一本翻翻目录，其中找几个段落读一下，对于此书的质量，心里大概就有个谱了。自己写作的时候，其实大多数时间也是在参考现有例子的结构和方法，如果你照着大量优秀的案例学习，那么自然也不会差到哪里去。
我在写《Maven 实战》之前，阅读了大量的 O‘Reilly，Pragmatic Bookshelf，和 Manning 的计算机图书，这些公司出版的图书大都有非常高的质量保证，在介绍技术的时候，有清晰的由浅入深的结构，辅以大小适中的案例，以及不枯燥的理论分析。可以说，我就是参考着那些优秀的书籍的写作结构和写作方法，写了自己的书，最终我的书也得到了整体不错的评价。
除了写作方法上的受益，阅读更重要的是从内容受益。再举例来说，我在「如何做好技术 TL」这篇文章中，提到了自己在做 TL 的这些年阅读了好多本讲管理的书籍，包括《赢》、《驱动力》、《门后的秘密》、《非暴力沟通》等等，这些书籍极大程度上帮助我补充了自己的思考脉络。写作即思考，而思考不是凭空出现的，思考需要原料，常见的原料就是我们实际的工作经验，然而一个人的体验毕竟是非常有限的，而阅读他人的体验及思考，以谦卑的态度为自己的思考提供更多原料，显然是明智的做法。
「如何做好技术 TL」收到过一条很有意思的评论，评论是这样的：
个人认为管理相关的书籍都是鸡汤，不必看，如果需要靠着“教你怎么做管理”的书才能做管理，那么说明这个人不适合做管理。
这句话隐含的意思是，有些知识，例如管理的知识，是无法传承的，只能靠自己天性领悟。对于此评论，我只能说无知者无畏了，我们写文章必不可持有这种心态，即便自己的想法有多么独特、多么原创，也一定不能自建藩篱，坐井观天。
我最近一年一直在做云原生相关的工作，期间我一直在思考，到底什么才是云原生架构，目前行业里对这个词有非常多的解释，但是所有这些解释都没法给让我满意，它们都过于偏重技术和云厂商的视角，而缺乏应用架构的视角。对于这个状况，我想基于过去一年，以及未来的相关工作，对云原生架构这个概念写一些东西，对其概念做一些补充阐述，帮助大家更好的使用技术，文章还没写出来，但是动机就这样形成了。
有了这个动机，再结合我自己个人的一些兴趣，过去一年我一直在积累素材，这些素材非常有意思。例如，我直接深入参与了国际化中台和考拉的项目，他们的架构基于云原生的技术，以及许多阿里云的产品，做了非常大的升级；我也详细了解了菜鸟如何在云上构建平台服务他的合作方公司；学习了解钉钉、IoT 这些本身在公有云上售卖服务的部门，自身是如何在云上架构。我通过 IM，电话或者面对面的方式和相关的同学沟通，他们都非常友好地知无不言，然后我整理相关的材料，再从中分析相同的模式。人脑非常喜欢模式识别的刺激，我在做这些事情的过程中也是乐在其中。除了实际的案例，行业资深人员的观点也是我平时收集素材的来源，例如林昊（花名：毕玄）最近写了一篇名为「云原生的进一步具象化」的文章，他们的文章通常不会人云亦云，仔细阅读会发现一些比较原创的观点。
除了上述和目标主题关联度非常大的素材外，我还发现跨学科的阅读也往往会给自己带来意向不到的收获。还是以云原生为例，虽然我在这个领域工作，但是最近一两年我一直在断断续续的阅读一些经济学的书籍，包括曼昆的《经济学原理》等（我估计好多人买了这套书了，但是真正认真读完的非专业人士还是比较少的）。在学习经济学的思维方式时，我就想从经济学的视角去解释云原生这个事情，原本自建的技术基础设施，在云的时代在逐渐演变的基于云的基础设施，这背后的选择对于业务来说，从经济学的角度应该怎样去分析？自建的成本和效用是什么？购买的成本和效用是什么？将复杂的业务技术架构拆分成一层一层之后，或许可以逐层分析，在每一层做一个从经济学角度最优的选择。
我最早了解思维导图是因为读了「Pragmatic Thinking and Learning」这本书，书中介绍思维导图的核心用途是把一个主题相关的所有内容，无论重要次要，都在一个图中写出来，那些不断拓展延伸的线，不是为了构成一个清晰的结构，而是为了给大脑显示什么地方思维可以进一步拓展。因此画思维导图的方式应该是尽量开放自由，目标是把主题相关的内容全部展现出来，思维导图的目的不是建立清晰的逻辑结构。因此，当我看到很多画的思维导图实际上是一个目录的时候，我觉得他们基本都用错了。
写文章（做演讲也是类似的），都是一个先开放后收敛的过程，在前期不断积累素材，使用思维导图拓展思维，建立材料的关联，就是开放的阶段。这个阶段中可以适当让逻辑思维退到幕后，把目光打开，不要过多评价（建立结构，分主次其实就是一种评价），用一种类似空杯的心态去倾听和观察现实世界及他人想法。我在做演讲或者做文章之前，总会先找个安静的地方，准备好咖啡，打开 MindNode，或者直接找拿出 A4 白纸和笔，给自己半小时到一小时的时间，把主题相关的思维导图画一画。安静免打扰的环境、没有时间的压力、富有精力的大脑，这些条件放在一起，才能够让自己从手头事务的聚焦中移开，让大脑中平时得不到关注的意识浮现出来，然后落到纸上。
将大量的材料胡乱堆砌在一起作成文章自然是不行的，作品必然要有一个清晰的结果。在建筑中，我们耳熟能详的有古希腊建筑的柱式结构，也有哥特式建筑以尖拱券、肋拱、飞扶壁等要素为核心的结构；在程序中，常见的 MVC、分层、微内核等模式也是清晰的结构。文章的结构能帮助作者把自己的观点清晰地表达，引导读者在清晰的路径中阅读。在有了思维导图之后，我通常会从那些纷繁复杂的材料中提取出一个最合适的结构，然后再基于这个结构组织材料。
写技术文章还是有一些常见的结构的，以下是几种范式：
解决问题型结构。这种范式通常围绕解决一个具体问题出发，常见逻辑是：背景介绍 -> 提出问题 -> 讨论解决问题的思路 -> 解决问题 -> 价值总结。这种结构可能是工程师最熟悉的了，因为大家都擅于解决具体问题。
知识介绍型结构。这种范式通常用于新技术的介绍，常见逻辑是：行业背景 -> 技术提出 -> 简单 Demo -> Core Conecpts -> 概念深入及 Demo （1-N 次）-> 前景分析。大家平时看到的很多技术介绍文章通常使用的是这样的结构，这样的结构的好处是可以由浅入深地介绍新技术和新概念。
观点输出型结构。这种范式相较于前面的两种会更有挑战，常见的逻辑是：总体观点 -> 子观点 1 -> 子观点 1 阐述 -> 子观点 2 -> 子观点 2 阐述 … -> 总结。这种结构的文章写好了力度是非常强的，但是写起来非常有挑战，因为观点的阐述需要丰富的素材以及严密的逻辑推导，稍有不慎就有胡扯之嫌。
当然，我们在写作的时候不必拘泥于这些范式，也可以琢磨自己的范式，但不论何种范式，背后总是存在一个有逻辑关系的结构的。有一本书叫「金字塔原理」，我听到很多人推崇（尤其是在绩效季的时候），我看了下介绍和评价，讲的就是如何用高效地方式让对方理解你，我没读过这本书，但应该就是讲行文的结构和逻辑的，有兴趣的同学可以买来看看。
不是所有的文章都有观点的，例如你写文章总结自己如何解决一个性能问题，不一定需要有观点；介绍一项技术，如 Rust，不是非要表达观点。但是能够表达自己观点的文章通常会更有吸引力，例如解决性能问题的时候强调理解排队论的重要性，这就是一个观点，容易让人印象深刻；介绍 Rust 的时候，断言其在性能敏感的场景未来会占据统治地位，也更容易让这门技术吸引人的目光。当然，观点是需要论证的，其坚固性和你论证的投入度成正比，逻辑推导、数据支撑、案例分析都是非常好的论证手段。
我们也看到有一些文章满篇观点，但基本都是引用，一会是乔布斯，一会是张小龙，一会是马云等等；当然，更常见的是引用公司高管的话，谁谁谁在什么时候说过什么等等，然后用这些内容来支持自己的材料。我觉得偶有引用无伤大雅，总是引用就只能说明自己没有观点，或者观点无力，需要强力给自己支撑。
更有勇气，能体现自己素材丰富，思考深度的观点，反而是那些敢于说出皇帝的新衣的文字。技术文章应该是具备科学精神的，科学是基于对过去不断的 say no 发展出来的，技术文章也应该敢于表达 say no 的观点，不用怕得罪人，我们应该明白，正确的技术/架构/方案，应该是经得起质疑的，因为如果技术是错误的，即便当下环境没人敢质疑，时间长了，现实会让错误需要付出的代价呈指数倍上升。因此，相比于通篇正确的废话，敢于对现状 say no 并提出自己反面观点的文章，更值得推崇。
严格来说，给自己的内容添油加醋的整故事，对于逻辑论证没有任何帮助。然而要让自己的文章/演讲有吸引力，故事的元素是必不可少的。人类进化到今天，大脑对逻辑的反应是非常慢的，而且需要经过训练后才能理解逻辑，但是对于故事的反应，三四岁的小孩就有，人类早期流传下来的精神，例如希腊神话和圣经，都充满了精彩的故事。直至今天，无论公司内网，还是微博，大家对吃瓜的热情之高，岂是逻辑论证能点燃的。故事很容易引起人的共情，让人设身处地联想，然后大脑皮层就容易嗨了，神经网络被激活，各种激素开始分泌……
这是人类生理的现实，所以我们写文章的时候要尊重（利用）这个现实。要讲一下程序性能不好导致身边的同事半夜 3:20 分电话惊醒了；出了故障导致超市收银机被砸了，介绍新编程语言的时候要秀一段代码，顺便搞个对比说 Java 不行；介绍 Mesh 的时候就要说你原来升级中间件得这么干这么干，以后不需要了，等等……
我介绍自己「Maven 实战」的时候喜欢讲一个真实的故事：
评论