深度好文 如何做一个有质量的技术分享

plucky · 2021年10月17日 · 182 次阅读
本帖已被设为精华帖!

文章转载自 https://coolshell.cn/articles/21589.html

404

分享信息并不难,大多数人都能做到,就算是不善言谈性格内向的技术人员,通过博客或社交媒体,或是不正式的交流,他们都能或多或少的做到。但是如果你想要做一个有质量有高度的分享,这个就难了,所谓的有质量和有高度,我心里面的定义有两点:

  1. 分享内容的保鲜期是很长的;
  2. 会被大范围的传递。

我们团队内每周都在做技术分享,虽然分享的主题都很有价值,但是分享的质量参差不齐,所以,想写下这篇文章 。供大家参考。

首先,我们先扪心自问一下,我们自己觉得读到的好的技术文章是什么?我不知道大家的是什么,我个人认为的好的文章是下面这样的:

  • 把复杂的问题讲解的很简单也很清楚。比如我高中时期读到这本 1978 年出版的《从一到无穷大》,用各种简单通俗通懂的话把各种复杂的科学知识讲的清清楚楚。还有看过的几本很好的书,有一本是《Windows 程序设计》,从一个 hello world 的程序开始一步一步教你 Windows 下的原生态编程。
  • 有各种各样的推导和方案的比较,让你知其然知其所以然。有了不同方案的比较,才可能让人有全面的认识。这个方面的经典作著是《Effective C++》。
  • 原理、为什么、思路、方法论会让人一通百通。这里面最经典的恐怕就是《十万个为什么》了,在计算机方面也有几本经典书,有《Unix 编程艺术》、《设计模式》、《深入理解计算机系统》等书,以及《The C10K Problem》等很多技术论文。

其实,从教科书,到专业书,再到论文,都有上面这些不错的特质。

所以,如果你想做一个好的技术分享的话,下面是我总结出来的方法,供你参考。

  • 先描述好一个问题。这样能够听众带入进来,如果这个问题是他们感同身受的,那是最好了。千万不要一上来就说 What,或是直接冲进答案里。这样的分享是在灌输和填鸭。把 Why 说清楚。没有 Why,直接谈 What 的技术分享,通常来说价值不大。
  • How 比 What 重要。在讲 How 的时候,也就是如何解这个问题。
    • 先要把问题模型说清楚,有了问题模型这个框框后,方案才有意义。
    • 然后要有不同技术的比较。有了比较后,听众才会更相信你。
    • 直接上 What 的技术细节,其实没有太大意义。
  • 一定要有 Best Practice 或方法论总结,否则上不了档次的。也就是分享中大家可以得到的重要收获。

说明了这个模型就是:问题 –> 方案 –> 总结。这其中是有一定的心理学模型的,具体表现如下:

  • 用问题来吸引受众,带着受众来一起思考
  • 用问题模型来框住受众的思考范围,让受众聚焦
  • 给出几种不同的解决方案,比较他们的优缺点,让受众有一种解决问题的参与感。
  • 最后,给出最佳实践,方法论或套路,因为有了前三步的铺垫,受众欣然接受。
  • 整个过程会让受众有强烈的成长感和收获感。

这里有几个示例,也是我在我司 MegaEase 内部的技术分享,供你参考(我个人的 YouTube 频道

技术分享:Prometheus 是怎么存储数据的(Youtube)

技术分享:Distributed Lock Manager(Youtube)

下面是我写在我们公司内的 Knowledge Sharing 中的 Best Practice,供参考


Sharing Guideline

Please follow the following sharing protocols

Understand Sharing

  • Sharing is the hard way to learn knowledge. The presenter gains the biggest advantages. not audience. 分享是学习知识的最难的方式。分享者获得的好处最最多的,而不是观众。
  • Sharing can open the knowledge door for the audience, but you have to walk to knowledge by yourself. 分享可以为听众打开知识的大门,但你能不能获得知识还要靠你自己。

Best Practices

To perform a great sharing, please follow the below practices.

  • Do not share a big topic, a small topic is better. A big topic could make the audience lose focus. Remember, Less is More!
  • Sharing time less than 60 mins is the best.
  • English language for slides is preferred.
  • While prepare the sharing contents, it’s better to discuss with the senior people to help you to see the whole picture, understand the good side and bad side, know what you don’t know … etc.
  • Strong Recommend Materials Outlines
    • What’s the Problem?
    • How to Solve the Problem?
    • The Best Solution or Practice.
    • The Mechanism, Key Techniques, and Source Code
    • Pros/Cons
    • References (Further reading)

For example, if you want to sharing a topic about Docker. the following outlines would be good one:

  1. **What’s the major problems need to solve.* (Provision, Environment, Isolation etc.)*
  2. **The Alternative solutions.* (Puppet/Chef/Ansible, VM, LXC etc.)*
  3. The Best Solution – Docker.
  4. Why?Docker’s key techniques – image, cgroup, union fs, namespace…
  5. Docker’s Pros/Cons
  6. Further reading list.

Knowledge increases by sharing but not by saving. — Kamari aka Lyrikal


作者:Plucky
出处:https://www.1991.wiki/topics/4
版权:本作品采用「署名 - 非商业性使用 - 相同方式共享 4.0 国际」许可协议进行许可,如您转载必须以链接形式注明原文地址。

plucky 将本帖设为了精华贴 10月17日 03:46
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册