聊聊如何做技术分享

最近在组织公司内部的技术分享，简单的聊聊如何写 tech slide, 以及现场 present 时要注意的地方，希望对大家能有帮助。当然个人理解，难免有错误，欢迎讨论。

分享目的

要纯粹，不能有任何功利，初心错了，做任何事情都会变形。

通常准备一次分享，耗时至少一周时间，准备资料，查找相关文档文献，不但能巩固自己对技术的理解和认知，有时甚至是颠覆性的。唯其心中有泪，是以言之有物

分享会带来交流，尤其是和相关领域专业的人交流，都能带来意外的收获。人都会有知识盲区的，三人行，必有我师！！！

准备 Slide

Slide 和 Blog 区别还是很大的，Slide 篇幅受限于分享时间，一般以一小时为主，通常 35 页左右

写的同时还要注意 present 的效果，这是和 Blog 最大的区别。如果是内部培训，还需要提前把资料发给大家，提前预习

查找资料

首先要尽可能的使用 google, 技术人从屏蔽百度开始，最恶心的是百度搜索一般都会导向 CXXX

同时也要拒绝二手消息，比如以前做 DBA 时，就有开发说 innodb 不如 myisam, 他说百度上看到的 ...

尽可能的查找官网 doc, 或是直接读源码一探究竟，因为有时官网 doc 也有错误，没来得及更新等等。当然，身边有大牛就更好了。

受众

写的时候要注意受众，新人内部培训类的分享，可能写的要基础一些(也可以咨询下大家，想听什么内容)，起到很好的入门作用。

但是对于熟手，或是 tech share, 就需要即有广度也要有深度。举个例子：golang channel

如果只是讲 channel 的基本使用，语法，那就太基础了，非常小白，浪费大家的时间。

深度就要讲到 channel 底层的实现，如何与 go runtime GMP 模型交互。

广度就要横向对比其它类 channel 的方案与实现，比如 ringbuffer 的性能对比，使用场景区别等等

术语

与普通分享不同，技术会带有很多术语，强烈建议附带英文名词，或原文。

有些东西用中文翻译出来，就很难理解。比如前几天老曹分享的 Backup Request, 翻译成了对冲请求，就很难理解

准备阶段

一周准备时间刚刚好，先要脑海里想好大纲，写到 Slide 里，不着急写内容。举个例子，我为了写这篇文章，就列了如下大纲导图：

大纲要有层次，就像小学写作文一样，要么递进要么总分总，要有逻辑在里面。

图表要多一些，文字太多，很多人没有耐心看完，比如本次分享就是例子，全是文字，很少有人完成阅读^^

尽可能的少一些源码，这不是 Blog, 尤其是深入 linux kernel 的，很晦涩。

排版风格

首先要考虑分享的场景，大的广场还是公司内部会议室，还是 zoom online share

对于大的广场分享，排版一定要简洁，图要大，文字也要大，最好撑满整个屏幕。还要确认屏幕的尺寸，来选择 Slide 的比例，这些都是细节

公司会议室的分享，文字图表也要大一些，像我这样的近视眼还不带眼镜的很瞎

对于 online share 就好很多，没那么苛刻

如何 Present

第一次分享很容易紧张，尤其是大的广场分享，比如 gopher china 那种的

所以需要提前演练好几次，视重要程度来决定

开场前要深呼吸，淡定淡定。演练时对着空气讲，手机打开计时器放在旁边，方便查看速度。如果是大会分享，最好在公司内部演练一遍，收集反馈意见，包括不限于内容，排版，节奏，音调等等

如何开场

一般开场都会简单自我介绍，然后会说

通过这次分享，能给大家带来 XXXX，希望能帮助大家加深对 XXXX 的理解

相当于我们写邮件里的摘要 TL;DR (too long, don't read), 不能云里雾里，说了一堆，引出一堆不相干的东西

好的开场等于成功的一半

节奏

技术分享和普通分享不同，幽默风趣不是必需的，但要控制好节奏

语速不能太快，大家还没理解就过去了。太慢的话，会让人昏昏欲睡

特别是关键的图表，需要刻意停留很久，让大家有充份的时间，去理解内容。我这方面做的就不够好，还是得多锻炼多分享

同时 Slide 更重于时时互动，最好要在现场能抛出问题，或者是思考

沉淀

分享时会被问到很多问题，很可能是盲区，最好分享完再查找资料确认。

公司内部分享，要做好录屏，这样方便其他人观看，特别是可以将知识沉淀下来，方便新人 onboard

小结

这次分享就这些，以后面还会分享更多的内容，如果感兴趣，可以关注并点击左下角的分享转发哦(: