如何做一次高质量的技术分享

[Jocs]

在开始分享之前想说，这不是严格意义的分享，更多是关于如何做好技术分享的讨论会，所以我们就从一个问题开始

问题 1：分享之前，问大家一个问题，我们为什么要做技术分享？

技术分享和个人成长的关系

• 分享是学习知识最高效的方式，收益最大的是自己而非观众。这句话也是费曼学习法最直接的诠释，费曼学习法的理念就是把复杂的知识简单化，以教代学，让输出倒逼输入。所以说分享也是一个对已知知识、认知、思想升华的过程
• 分享可以为听众打开知识的大门，但是否愿意跨进大门（对分享内容感兴趣进而进一步了解）还是取决观众自身。很多分享者都有一个心理负担，认为一场高质量的分享就是在 40 分钟内，将自己在某个领域的知识向观众倾囊相授。首先，一个领域的知识不可能短时间讲述清楚，并做到面面俱到。其次，观众对于一场技术分享，第二天能够记住的通常只剩下 10% 了，所以说，分享更多是知识的索引，观众想进一步了解还需自行阅读更多相关资料和文献
• 提升技术影响力，也是认识业界大佬的机会。分享不仅能够升华我们对某领域知识的理解、加深技术项目的思考，在参与技术大会过程中，也会认识很多业界大佬，交流心得和体会

了解分享的规模和观众画像

不同场合的技术分享，对分享主题和分享时长都是有要求的，比如 QCon 就要求分享的主题不能在其他会议上分享过。FDCon 就有不同会场，那 FDCon 2018 来说，就有 H5 小程序专场、全端与全栈专场、前端基础设施专场等。所以当我们被邀作为嘉宾参会时，我们所选的主题也就需要所涉会场之一相关。一般的技术大会，单场分享时间一般需控制在 40 分钟，分享后会有大约 10 分钟的观众提问时间。JSConf(Conferences for the JavaScript Community)在分享间隙有个 lighting talk 的环节，在常规分享间隙插入 5 分钟的即兴演讲，如果你想在下一年作为演讲嘉宾登上 JSConf，那么 lighting talk 是个很好展示自己的机会

问题2：我们为什么需要事先了解一场分享时长？

是的，分享内容长度是和分享时长息息相关的，普通人演讲的语速大概在 150 字 ~ 180 字 / 分钟，所以一场 40 分钟的演讲，演讲稿字数大约在 6000 字 ~ 7200 字，这样我们在准备演讲稿的时候，也就知道大概准备多少内容了。

问题3：下一个问题，为什么我们需要去了解分享的规模（单场参与人数）和受众群体（观众画像）？

一个 1000 人的会场和一个 100 人的会场，所需要的控场能力不全一样，1000 人的会场，在灯光的照射下，我们几乎看不清下面的观众，我们可能就需要减少一些与观众的互动，不然选择观众、传递话筒等都会耗费比较长的时间。而 100 人的会场，几乎可以看清每个人，可以加强一些与观众互动的环节

受众群体也决定了我们分享的侧重点，举例说明下，比如电商分享，我们就不应该去分享纯前端相关的技术，而应该分享电商业务、与电商相关的技术及架构设计，比如营销系统的设计，推荐算法在电商业务中的运用等，尽量少的涉及源码分析，如果一定需要源码来说明的话，我们也尽可能使用伪代码。又比如电商消费侧前端的技术分享，面向的受众都是前端同学，大家更关心的是前端技术如何赋能业务，想了解底层原理，在做前端技术分享时，就可以侧重系统设计及架构，源码分析等

挑选合适的分享主题

问题4：我们如何选择分享主题？

选择小的主题，在选择主题上，除了需要和会议会场相关，比如前端技术分享，那至少应该和前端技术相关。我们应该选择一些小的主题，大的主题容易不聚焦，同时使得我们的分享变得泛泛而谈，缺乏深意。举个例子：

Bad Case：性能优化在前端项目的应用
Good Case：我们如何在商超项目进行图片性能优化

下面一个主题比上面一个主题更加具体，也更能引起观众的兴趣和共鸣

选择自己参与或主导的技术项目，我们在做技术建设，一定遇到过很多问题，踩过很多坑，通过对过往遇到的问题的总结，不仅能够加深自己对问题的思考和理解，同时也会帮助到别人

准备分享稿

分享模型

其实技术分享都是有规律可循的，我将技术分享归为两种模型：复杂模型和简单模型

复杂模型：[发现问题 - 背景梳理] - [架构总览 - 方案对比 - 核心模块分析] - 展望未来
简单模型：发现问题 - 方案陈诉 - 总结陈词

选择不同的模型，主要根据分享时长来决定，比如 20 分钟的一个分享，那么我们就可以使用简单模型，而 40 分钟的技术分享，相对时间比较充裕，那我们就可以选择复杂模型。不论是哪种模型，都遵循了发现问题 -> 解决问题的思路，其实这也是为了将观众带入第一视角，使观众能够沉浸其中

这儿将以我之前的一次技术分享来分析复杂模型的应用。

一种自动化生成骨架屏的方案，这是我在 FDCon2018 的分享

发现问题

一份是 Akamai 的研究报告，当时总共采访了大约 1048 名网上购物者，得出了这样的结论：

• 大约有 47% 的用户期望他们的页面在两秒之内加载完成
• 如果页面加载时间超过 3s，大约有 40% 的用户选择离开或关闭页面
• ......

背景梳理

通常方案，我们会在首屏、或者获取数据时，在页面中展现一个进度条，或者转动的 Spinner。

• 进度条：明确知道交互所需时间，或者知道一个大概值的时候我们选择使用进度条。
• Spinner：无法预测获取数据、或者打开页面的时长。
  ......
  其实，骨架屏（Skeleton Screen）已经不是什么新奇的概念了，Luke Wroblewski 早在 2013 年就首次提出了骨架屏的概念，并将这一概念成功得运用到他当时的产品「Polar app」中，2014 年，「Polar」加入 Google，Luke Wroblewski 本人也成为了Google 的一位产品总监。
  他是这样定义骨架屏的，他认为骨架屏是一个页面的空白版本，通过这个空白版本传递信息，我们的页面正在渐进式的加载过程中。
  苹果公司已经将骨架屏写入到了 iOS Human Interface Guidelines ,只是在该手册中，其用了一个新的概念「launch images」。在该手册中，其推荐在应用首屏中包含文本或者元素基本的轮廓。
  2015 年，Facebook 也首次在其移动端 App 中使用了骨架屏的设计来预览页面的加载状态。

架构总览

通过 puppeteer 在服务端操控 headless Chrome 打开开发中的需要生成骨架屏的页面，在等待页面加载渲染完成之后，在保留页面布局样式的前提下，通过对页面中元素进行删减或增添，对已有元素通过层叠样式进行覆盖，这样达到在不改变页面布局下，隐藏图片和文字，通过样式覆盖，使得其展示为灰色块。然后将修改后的 HTML 和 CSS 样式提取出来，这样就是骨架屏了。
架构图示意

方案对比

在选择骨架屏之前，我们也调研了其他两种备选方案：服务端渲染（ssr）和预渲染（prerender）。
......
核心模块分析（最好进行源码分析）
下面我将通过 page-skeleton-webpack-plugin 工具中的代码，来展示骨架屏的具体生成过程。
正如上面基本方案所描述的那样，我们将页面分成了不同的块：

• 文本块：......
• 图片块：......(不同图片块方案对比)
• 按钮块：......
• Webpack 插件：......

  async makeSkeleton(page) {
      const { defer } = this.options
      // ...
  }

展望未来

Page Skeleton webpack 插件在我们内部团队已经开始使用，在使用的过程中我们也得到了一些反馈信息。
首先是对 SPA 多路由的支持......
其次，玩过服务端渲染的同学都知道，在 React 和 Vue 服务端渲染中有一种称为 Client-side Hydration 的技术，指的是在 Vue 在浏览器接管由服务端发送来的静态 HTML，使其变为由 Vue 管理的动态 DOM 的过程。
......
还有，在页面启动后，我们可能还是会通过 AJAX 获取后端数据，这时候我们也可以通过 骨架屏 来作为一种加载状态。也就是说，其实我们可以在「非首屏骨架屏」上做一些工作。
最后，在项目中可能会有一些性能监控的需求，比如骨架屏什么时候创建，什么时候被销毁，这些我们可能都希望通过一些性能监控的工具记录下来，以便将来做一些性能上面的分析。......

技术分享合理使用图表

问题5：再问大家一个问题，合理使用图表对我们的技术分享有什么帮助？

“Programming without an overall architecture or design in mind is like exploring a cave with only a flashlight: You don’t know where you’ve been, you don’t know where you’re going, and you don’t know quite where you are.”
Danny Thorpe（Danny Thorpe was an American programmer noted mainly for his work on Delphi）

1. 一张好的架构图能够让观众对整个技术项目有个整体的感知，后面再拆模块讲技术方案时，能够清晰的知道该模块在整个系统中的地位和作用
2. 一图胜千言，图表往往比文字更具表现力和感染力，比如数据的变化我们用折线图就比较直观，能力模型我们用雷达图就很清晰，市场份额占比我们用饼状图来变现就很明了

问题6：下一个问题，既然图表在技术分享中如此重要，那么我们怎样去合理使用图表呢？

“Incorrect documentation(diagram) is often worse than no documentation(diagram).”
Bertrand Meyer（编程语言专家，Eiffel 语言的创造者）

首先我们应该知道有哪些架构图类型可用，比如分层架构图、时序图、流程图等，其次我们应该了解目前有哪些软件架构模式，最后根据我们架构模式选择最合适的架构图（这儿的架构图是广义的架构图，不单指分层架构图）

架构图的类型（不止下面三种类型，这儿只列举了常见的三种）：

分层架构图

时序图

流程图

关于如何画好架构图、时序图、流程图，推荐大家阅读以下几篇文章：

如何画好架构图_架构_Hockor_InfoQ写作社区
如何画好一张架构图?(内含知识图谱) - 掘金
快速学习时序图:时序图简介、画法及实例 | 人人都是产品经理
如何画好流程图_前端_Hockor_InfoQ写作社区

常见的软件架构模式

分层架构（Layered (N-tier) architecture）

我们经常在业务架构或者服务端上见到分层架构模式，分层架构将业务拆分成水平向的几层，层与层之间有逻辑依赖和信息交互，每一层都有自己独立的角色或功能，比如在上面分层架构图示例中，最上层是展现层，展现层和服务层之间通过通信层来沟通交流，最底层是数据层。分层架构突出了软件架构的一个核心思想，关注点分离（separation of concerns (SoC)）。

问题7：又一个问题，你还知道哪些和前端相关的分层架构的系统？

客户端-服务端架构（Client-server architecture）

这个应该是我们最熟悉不过的一种架构模式了，目前我们做的浏览器应用、客户端应用都属于该模式（去中心化应用 DAPP 不属于该架构模式），客户端-服务端架构主要包含两个组成部分：服务发起者和服务提供者。

微内核架构（Microkernel architecture）

微内核架构通常也被称作插件化架构模式，也是前端领域比较常见的一种架构模式了。在该架构模式中主要有两个组件： core system 和 plug-in modules。这也就支持了第三方去开发一些插件，在前端领域比如 webpack、Koa 都属于微内核架构。

Core system 包含了应用能够运行起来的最小逻辑部分，通过 Plug-in 模块来扩展 Core system，从而提供更多的功能。

问题8：在我们熟悉的开源项目，或者我们目前的技术建设中，你还知道哪些微内核架构？

软件工程还有其他的一些架构模型，由于和前端领域关系比较小，还有分享时间限制，这儿就不赘述了

• 事件驱动架构
• 微服务架构

有兴趣大家可以看看 Software architecture diagramming and patterns 这篇文章，总结得很好

讲解技术方案的要点

首先，把复杂的问题讲解的很简单也很清楚，关于怎么将复杂问题简单化，其实有方法论可循的，开篇一张架构图固然是好，但也只能让观众有个全局感知，对各个模块的理解还是不够深入，这个时候我们就可以举一个具体的 case，来阐述我们的技术方案，还是拿上面自动化生成骨架屏的分享为例，在说完整个原理之后，就会拆解到不同的模块，比如图片模块或者文本模块，并且通过关键代码来解释不同模块的实现。另外一个将复杂问题简单化的方法就是，我们尽量通过最小例子来解释，抛开一切和主流程不相关的分支。其实这个思想也类似于微内核架构的思想，比如我们要阐述 babel 的原理，那么我们只需说清楚 babel 处理代码的三个阶段：Parser -> Transformer -> Generator 就行，关于 babel plugin、presets 在解释明白核心原理上就不那么重要了

其次、有各种各样的推导和方案的比较，让观众知其然知其所以然，相信我们在做技术方案的时候，都做技术方案的选型（比较），以及从发现问题到解决问题该技术方案是推演出来的，这可能比我们直接陈述技术方案要更能打动观众，也能带领观众进入你的第一视角，重演一次发现问题到解决问题的整个过程

最后、原理、思路、方法论会让人一通百通，当我们把原理和思路讲清楚后，我们就可以在分享的最后部分，对其进行升华，形成一套方法论，计算机科学中很多架构模式、设计模式都是相通的，就拿操作系统进程调度来说，有不同的调度策略，先来先服务调度算法、最高优先级调度算法、最短作业优先调度算法、高响应比优先算法、时间片轮转调度算法、多级反馈队列(Multilevel Feedback Queue)，当时我在看操作系统进程调度这部分的时候就在思考，进程的调度策略和我们接需求开发其实是类似的，最简单的模型就是我们按照先来先服务的算法，一段时间后，有产品说这是 P0 优先级的项目，其他项目先暂停，按照项目优先级来定容，这个时候我们可能会和产品 argue，虽然目前这个需求优先级不高，但是开发周期比较短，短时间上线是否可以先拿到一些收益？这就是最短作业调度算法，当有研发团队服务于多个产品团队时候，是否需要采用高响应比优先算法呢？谁等待时间长，优先服务，因为不同的产品团队也比较难排出一个准确的需求优先级。当我们同时开发多个需求的时候，就可以采用时间片轮转调度算法，这周前三天把 A 需求开发完成，后两天开发 B 需求。当然多级反馈队列是最合理的，首先将需求划分成不同的优先级，按照优先级来进行调度，需求结束后 PMO 组织产研进行价值回溯，对业务收益大的项目提升优先级，收益不那么明显的项目降低优先级。这儿扯得有点远了，收一下，其实想表达核心点就是我们在技术分享结束部分，对我们的技术项目做一些升华和拓展，方法论一通百通，解决 A 问题的思路是否可以用来解决 B 问题？

观众问题准备及话术

一般技术分享都会有 QA 环节，针对我们的分享内容，我们从观众的角度出发，或者从一个对该分享的技术方案小白的角度出发，他们会问些什么问题，整理一个问题列表（不用展示给观众），针对这些问题，我们思考一下怎么回答，并且事先准备好问题答案，这样在分享后的 QA 环节就可以避免因为紧张而回答不上来

如果观众问到的问题，是我们之前没有想到过，并且现场也没有答案时，我们需要准备一个话术，比如：“这个问题很有深度，由于 QA 环节时间有限，很难通过几句话解释清楚，会后我们单独讨论一下”

其他有助于提升分享质量的点

1. 分享稿用语避免太过书面，应该更加口语化，因为分享是一个互动的过程，口语化更适合沟通，拉近分享中和观众的距离
2. 向其他有过分享经验的同学请教，如何准备一场技术分享，分享的各个环节应该注意什么

排练和预演

确定分享中各个模块时间分配，找个安静的地方，排练，并进行录音，通常现场更不可控，有突发的提问，紧张时语速会过快，所以现场可以放一个计数器，准确控制分享进度。播放录音，看语速是否过快，发音是否准确，也看看分享中是否有节奏，而不是平铺直叙的背诵文章，预演也是为了最终脱稿

分享过程中的注意事项

分享中的 checklist：

• 自我介绍（我是谁、履历、基于什么原因我来做这次分享）
• 现场准备一个计时器，来精确控制整个分享过程的进度，各个模块的时间分配
• 在分享前先介绍一下分享分哪几个部分，每个部分包含哪些内容，最忌讳一上来就进入正题，在介绍分享分哪几个部分时，观众会对本次分享有个大局观
• 和观众互动、注意留白（提醒观众需要注意了），但是不要让观众误以为是忘词了
• 分享结束，留社交账号，用于进一步沟通交流，致谢关注

分享后

• 在技术分享大会，我们可以利用分享间隙、晚宴等场合，这是认识业界大佬很好的机会，主动沟通交流
• 收集反馈，如果正好有朋友、同事在场，可以问问他们分享得怎么样，哪些地方可以改进
• 分享现场一般都会有技术书籍出版社（图灵社区）的同学，他们一般都会主动找分享嘉宾加微信，问是否有出书的需求，如果你有出版技术书籍的打算，和出版社保持联系是有用的

絮叨许久，感谢大家，这是我在做技术分享后的一些经验之谈，希望对大家有所帮助，最重要的一点，适合自己的才是有用的