演讲： 关于为什么要做分享这件事

这是一次内部分享，以下为文字稿，内容比较口语化，分享出来给大家

大家好，虽然我们已经见过几个月了，但是可能还是有一些朋友不认识我，更多的朋友对我不是很了解。我叫 AnnatarHe，是一名前端工程师，虽然现在写前端的时间比较少，但是确实是一名正经的 前端工程师。目前供职在 xxxx，主要做的 CI/CD, 性能分析平台等相关项目的开发和维护工作。

几个月前，在很多同事的帮助和支持下，我们终于组织了 web 前端的技术分享会。分享了包括 GraphQL, DevOps, 程序设计，代码技巧以及业务实践相关的话题。大家的精心准备，认真听讲和积极参与都能看出很足的匠人精神

但是在经历了几次分享之后，我作为一名听众感受到其实很多同事对于分享这件事还是有一些误解的地方，确实，之前直接开始做分享，也没有做一些预先的准备预热，导致现在目的并不明确。所以我想在这里重新开始一下我们做分享这件事。

先说大的背景。

公司的 web 技术

我来这边工作也有一段时间了，大概感受到了这边的一个技术氛围。不得不承认的一个让人沮丧的问题是：我们的 web 技术落后于行业水平有一些距离，然后距离顶尖水平有相当一段距离。

我得出这个结论的论据主要有几个：

我们没有一整套 DevOps 概念

其中一个很重要的点是 CI/CD。缺乏 DevOps 理念的影响就是我们的开发效率是有很大的提升空间的。不知道我们这边有多少项目组能做到一周发布 100 次，还不影响工作节奏的。大家也可以思考一下。

节奏不够会导致上一个功能慢一些。别人上线三个版本都跑起来了，我们还在问数据库怎么部署是不是有些尴尬。

针对上面的问题。有些同事可能会说，我们组做了 CI/CD。那么就是第二个非常重要的问题。我们很少有合作。人类能发展到今天这个样子，站在食物链顶端，没有 “合作” 是做不到的。我们应该也都过了个人英雄主义崇拜的年纪了吧。公司存在的一个原因是把一群人凑到一起合作，产生更高的利润。我们作为同一家公司，同一个工种的同事，很多时候合作是很少的。比如之前我们有很多内部项目开了至少三个的 npm registry 就是个典型的沟通不足的例子。

我们不知道 “好的 web” 是什么

“好” 是有量化标准的。

我知道有很多人会觉得数据冷冰冰，不合理。不如人思考有深度，然而事实是数据都是抽象出来的，我们需要数据来评判我们做得如何，而只需要注意不要为了数据而数据。

目前我感觉下来我们这边对数据很不敏感。比如我们的 web 的 TTFB 数据是多少, FP 呢，加载的瓶颈在哪里，DOM processing 花了多久？

ok，2b 的业务不需要这种极致的性能分析，那么重构大家应该会做一些吧。测试覆盖率是多少？代码量减少了百分之几？性能跑 benchmark 了吗？结论如何？

甚至一些很关键的，页面上有没有一些严重的 error ？触发频率如何？

我不了解大家的项目做得如何，但是我想应该很多环节都没有注意到吧，当然，这里不是 blame 各位，我也一样很多环节没有做得极致的好。

我们不知道 “好” 是什么（略）

对于很多问题，大部分人会用和稀泥的官方辞令说 “没有好坏，没有对错，都是不同的见解而已” 这种毫无意义的说辞来调和。很多人都说世界上没有黑白，都是灰色，二元对立是小孩子才会有的想法。那么我必须要表达，世界不是这样的。

我画的画和毕加索的画能一样吗？你会不会花一亿买我画的小鸡啄米图。

如果说没有好坏对错，那为什么强哥的工资比我高很多？

---

以上就是几个大的背景。包括我在内的很多同事看到了这些问题，只是由于工作忙或者事情太多的原因他们没时间去解决，所以主要就由我来思考怎么能解决这些问题。

其实也有私心：在这样的一个技术水平比较一般的团队待上几年再出去，说句老实话，被市场淘汰是大概率事件。我作为其中的一份子希望把这个概率减到最小。

为了解决问题并达到目的我们需要做的是解决我前面提到的四个问题。而其中我认为最重要的是 “合作” 这个环节。

所以，前端分享就是这么来的。通过交流沟通，我们有了更多合作的可能性，我们可以扩散很多优秀的思维和方案，我们共同探索 “好” 是什么，“优秀的 web” 是什么。

这个分享会的目的是：大家一起成长，一起进步。把我们的 web 团队做成中国顶尖乃至世界顶尖的 web 技术团队。

千万不要觉得这个难度很大，或者说我在说大话，实际上我们是非常有希望的。接下来我简单解释一下：

时间和思考

我是一个非常非常讨厌加班的人。我认为加班的原因只有一个：

我太菜了(水平太差了)

只是菜可以有很多方面：

• 一种是我技术太菜了，实现这么一个饼图竟然需要三个小时导致加班才能完成，不可接受。
• 一种是我沟通能力太菜了。这么一个蛮横无理的上线需求我竟然没能拦住，导致现在加班搞还不一定能保证里面没有 bug。
• 一种是我的辨识能力太菜了。竟然加入到一个营收压力这么大以至于需要加班的 公司/团队 .

可能各位觉得像是阿里，腾讯，头条他们的技术团队很强对吧，他们是很有可能成为顶尖技术团队的人对吧。

但我不觉得：他们工程师加班太多了。他们大多数 PM 脑袋不太灵（解释一下：pm 脑袋不灵光的原因大部分在于领导）。

• 加班多大概率会导致很少有时间学习与思考。
• KPI 压力又会导致他们不多的下班时间还得思考怎么升职，怎么写 PPT。（虽说现在都搞 OKR，但是实际上绝大多数公司只是把 KPI 换个名字而已）

所以等式：

加班多 === 菜 && 加班多 → 没时间学习思考 → 以后会变菜

拿我自己举个例子。之前我工作强度还是比较大的，有段时间甚至在坐地铁都在写代码，出去玩也在写代码。没有开玩笑。那段时间头发白了很多，整个人状态也非常差，心情也很 down。

后来来了公司以后，这里省略一些彩虹屁。总的来说这种工作强度的变化是非常不适应的，导致有了很多的时间去胡思乱想。所以我们项目跑起了 k3s, 我们把 rancher 搭了起来，搞了监控，报错。有多余的时间思考业务变化，甚至还抽了三个微服务出来，探索了 git based database。

我不相信 996 的工作强度允许工程师思考很多问题。// 我也不相信阿里的价值观可以让员工有更高的创造性劳动成功。

基于这样的原因，我真的觉得我们能够达成我们的目标，我们所有人：

大家一起成长，一起进步。把我们的 web 团队做成中国顶尖乃至世界顶尖的 web 技术团队

那么前面说了那么多我们做这个分享会比较上层的目的，具体到个人我们会有怎么样的收益。

作为听众自然是可以收获到各种各样不同的观点，思考方式，技术方案。为自己做技术储备，开拓视野。

作为嘉宾可以更加深刻地学习了解自己所要分享的话题。比如某个技术方案，很多时候我们做完之后不会单独拿个时间出来复盘，看看哪里做得好，哪里可以改进。分享会就是个很好的机会，帮助嘉宾更深刻地了解自己的项目，或许可以从不一样的角度思考问题。

只是分享会不能直接帮大家升职加薪比较遗憾。在坐的各位除了 xx 应该没有谁能评其他人的绩效对吧？另一个方面想一下，其实分享做砸了也没关系，不会因为分享得不够好对工作造成什么影响，比如罚你吃一整个榴莲

上面基本解释了 “为什么要有前端分享会” 的问题，接下来要聊一聊如何分享的问题。首先针对嘉宾谈一谈。

私下里我找过很多同事说能不能分享一些内容给大家什么的。大部分人的回答都是 “哎呀，我技术不太好，什么都不会，不知道分享什么“。

所以我这边首先需要调整几个思维。

第一个是作为演讲嘉宾： “我什么都不会，怎么给大家做分享“。

大家应该都听过一句话 “三人行必有我师”，更何况我们这边十几二十个人，总有人在某些方面比别人强点儿吧。比如，虽然代码可能写不过大多数人，但是我比较自信屋子里起码有一半人追星水平不如我，饭圈混得没我熟。那我就可以讲一讲饭圈文化嘛。当然，我们要技术相关，技术相关的可以聊一聊他们怎么做集资的对不对。还可以看看一些集资或者论坛网站的代码，参考一下他们的技术架构，评论一下如何改进。比如我就觉得兔区像是上世纪八十年代做的网页。或者是经常逛 P 站也可以思考一下他们怎么做 cdn 的，加载怎么这么快。

可能有些嘉宾觉得自己说的内容太简单，其实不是的。如果各位经常逛一些外网的文章或者论坛，会发现很多老外非常的沙雕。比如用 css 写个 windows 98 的页面出来。拿 js 来实现 js，天天捣鼓 elixer，或者怎么拿 emacs 煮咖啡。这些东西实用价值基本是 0，放到某集团价值观妥妥的 3.25。但是这些东西背后是多么精彩的智慧！能把其中的原理，实践，思维方式教给大家，绝对是一个精彩的分享。

当然这个思维也可以反过来。我知道其实有些话题可能很多听众会觉得太简单了或者没什么卵用，脑海里会想 “这也太简单了，我都会，听他讲干嘛“。还是前面说的 “三人行必有我师”。也许这个主题觉得一般，但是很多人思考的纬度，做事的方式不同会产生很多奇妙的东西。比如之前有一期是关于一些 js 代码的小技巧，无非就是一颗 trick 或者 API. 看起来很简单的话题，但是最后经过分享讨论产生了那么多奇特的代码。

第二点是嘉宾要尊重观众。作为主要的分享人，我们会占用参与者一个小时的时间，他们为什么愿意花一小时来听你分享而不是玩一把 0/21 的快乐亚索。我们作为分享嘉宾需要尊重观众，认真地准备内容，思考如何让观众更好地理解你所表达的意思。

整个分享的目的不是 “反正我说了你们也听不懂，就听听算了“， 而是深入浅出让观众理解，理解其中的意义，并在将来实践在自己的项目中。

第三点是嘉宾要尊重自己。作为分享的嘉宾你很可能要多花一些时间来准备内容，内容需要准确，演讲的节奏要控制好，论点要清晰，论据要充分。不然花了三个小时草草了事的工作基本上就是浪费了人生中自己的三个小时。

第四点是听众要尊重嘉宾。我这里说的是对于内容的准确度。比如嘉宾给大家分享说 1 + 1 = 4 我们不能只是听了就过去了，应该要有自己的观点，去询问为什么得出这个结论。如果说嘉宾说的不对，那么他很快会意识到自己的问题，及时改正。如果嘉宾正确解答了，那么也为很多同事解惑。这个例子不是说听众一直要 challenge 嘉宾，而是去找正确的答案。我一直很推崇 erlang 的一个哲学 crash early, crash fast，今天犯错今天改，总比丢了更大的人要好。

尊重观众，尊重嘉宾，尊重自己。

关于如何分享还有一个问题是分享什么话题，这边我可以简单列几个维度：

• 有什么新工具可以给大家安利
  • webpack 5 有什么新特性，为什么这么设计，解决了什么问题，怎么实现的
  • vue 3 有什么新特性，为什么这么设计，怎么实现的
  • vim 8 花了二十多年终于有了的 async task 是怎么回事
  • git 如何正确的使用，有什么小技巧，合理的 workflow 应该是怎么样的
• 编程语言和实现
  • 正则怎么使用，规则是什么，怎么实现
  • decorator 这个语法怎么变来变去的，有什么用，为什么。其他语言是怎么处理的。
  • monad 是什么，call/cc 是什么，模式匹配又是什么
• 项目实践
  • 点餐系统项目发展怎么样的，碰到了什么问题，怎么解决的，有什么经验教训
  • 介绍新的账户系统。为什么要和权限系统 分开/合并 。如何实现高可用，对于分布式问题如何解决
  • MySQL 性能优化如何做，为什么要做这些优化，如何切片，如何做多节点
• 如何写代码
  • 四人帮设计模式分享
  • Kiss 原则
  • SOLID 原则

我只是在自己有限的脑袋里简单想了这几个话题，希望可以抛砖引玉产生更多的想法。不要被上文的内容所束缚，尽情地释放自己的能量。

谢谢大家。希望各位能够理解我们这个前端分享会的意义，积极参与，共同成长。