参加第11届D2前端技术论坛，你有什么收获？

没参与这次的 D2, 但是看到

的回答，有感而发。

最近一两年我去过的技术会议不超过 3 个，去的动机基本上是面基。在我还没真正入行(但是已经写了几年代码)的时候，我很喜欢跑到广州参加各种各样的技术会议，是因为我喜欢跟和我一样在做技术的人在一起，不管我有没有听懂台上的人在说什么。

后来我从一个 Newbie 成长成为一个有些经验的老司机，在这个阶段去听这些会议的时候，我感受到的是失望，就像大学从选课到上课一样：

1. 看议程的演讲主题和简介，感觉要学到很多东西了。

2. 在台下听讲师讲，屏幕上是框和线，描述的是业务上的架构流程。事实上我根本看不明白。

3. 如无意外，下一张 slide 就是性能打点，表示用某某某技术之后性能提升了多少。

4. QA 环节，台下必问生产环境性能。

我也会偶尔接受一些邀请做过一些 talk, 每次都想跟活动方要求取消我的 QA 环节，但又不想显得自己搞特殊所以最终还是要接受这些 QA。因为台下能问到点子上的问题很少，而一般我都能想到听众会有的疑问，然后把这些疑问插进 talk 里，作为要讲的点。QA 只能算是一个补充。我很讨厌在台上兴致勃勃地演示完一个令人激动的技术之后，要被台下的人问这个技术用在业务上的性能啊兼容性啊怎么样。我更乐意去和大家讨论这个技术是如何实现的。

说到底，我就是不喜欢把技术分享和业务绑在一起的这种会议氛围。讲师不应该从直接从业务的角度向听众宣讲，而是应该把听众都当成一张白纸，首先介绍这次主题要讲的这种技术是什么、他的出现可以解决什么问题、我们在业务中如何用这种技术去解决问题。

可能是因为我的位置不够高，我对性能打点、业务整体架构真的兴趣不大，演讲中可以提到，这是很正常的。但是讲师把这些东西作重点来讲就很没有意思了。我们大家都是写代码的，just show me the demo code!

举个国外的例子：

Netflix JavaScript Talks - Async JavaScript with Reactive Extensions (https://www.youtube.com/watch?v=XRYN2xt11Ek)

整个 talk 的主题是 Netflix 如何解决异步问题。在前 10 分钟，先给观众一个概念：现代的应用基本都是 Asynchronus 的。然后表示，Asynchronus 是很难处理的，并用一个小小的代码片段做异步处理有多繁琐。然后又解释了 GoF 里的 Observer 和 Iterator 两个模式。科普了这些基本的知识后，才开始给出 Netflix 上一个现实的场景。他们用 map, filter, concatAll 这些方法来处理数据，然后告诉你，连 event 都能用这些方法这样来处理。这里才开始讲到整个 talk 的重点——Rx.

整个 talk 没有出现让你莫名其妙的架构流程图，而是把 Netflix 业务中很小的场景(比如一个搜索框)拆分出来，告诉听众，工程师如何用 RxJS 解决这个小场景中遇到的问题的。

这样的分享，才会让观众觉得干货满满，因为讲师都把进入 Rx 世界的钥匙交给你了，还带你看了看他们的 Rx 世界。至于观众听了以后用不用，那是观众自己要考虑的事，但最起码观众明白了什么是 RxJS, 什么样的场景可以用 RxJS, Netflix 是怎么用 RxJS 的。

再举一个例子：

What if the user was a function? by Andre Staltz (https://www.youtube.com/watch?v=1zj7M1LnJV4)

Andre Staltz 是 Cycle.js 的作者，对 FRP 有很深入的理解。这个 talk 讲的其实是 Cycle.js 背后的思想，观众能够顺着他的演讲，用另一种角度，另一种思维方式去看待 Web 的 UI 开发。这种 talk 的意义在于，讲师能给你带来启发。

我比较喜欢老外的这种模式，所以国内的技术分享我就越来越少去了。不是说国内讲师的技术不如国外的。国内讲师们的技术都相当好，而且经验十分丰富。只是，貌似国内的很多讲师对技术分享的看法和我想的不一样。我希望技术分享是一群热爱技术的人的聚会，也是有经验、有想法的讲师给观众带来启发的过程。我作为开发者，我希望看到的是，讲师对某个技术很有自己的想法，他把自己的看法分享给观众，让观众了解这个技术，知道这个技术应该怎么用。技术分享应该是面向社区的，而不是面向业务的。而那些数据啊，性能啊，都跟老板说去吧。

纯属个人看法。

-

导言：本篇以前端新人为受众，试图推广一种积极向上的前端参会心态，达成富强、民主的参会氛围，用以实现文明、友善的会议大和谐。

一句话总结：本年度的 D2，「亮点」和「干货」都比去年少，不过这可能是个好现象。

一方面因第三届 CSS 大会的同期举办，把讲师团和老司机见面会强行分成了杭广两个分舵（没算上海Strikingly还有场RN的小型交流），另一方面群众可能受到 D2 夜场的前辈们在尽量克制地表达某观点磁场干扰，导致线上线下的交流讨论都没有去年活跃。

我无意流水账搬记录每场主题的参会感悟。稍等几天，就可从官网下方「合作媒体」的某几家获取全部视频与讲义。随着当下信息获取会越来越便捷，很自然地，线下技术论坛进化为开发者面基论坛是迟早地事情。这不是纯吐槽，对合适的人，带着问题小团体沟通是非常高效的沟通方式，后面会细讲。那么歪个楼回答下「看了知乎对第11届D2前端技术论坛的吐槽，你有什么感受？」应该挺好玩的。

你像熬夜观看 Apple 发布会一样等待新品推出，你并不关注这些新产品背后实现的技术细节，但期待某个发布的最新产品改善了你的工作环境和生活品质。你只需接受刷信用卡般的接入成本，即可享受着封装工艺精美，整合后的接近零成本开发等新技术带来的快感。你关注订阅各个技术门户的推特和博客，与众多的吃瓜群众一齐站在前端技术的最前沿，感叹科技之创新，时代之进步，期待某个新产品线能提升你在的团队业务系统的迭代速度。遗憾地是：你扫过本届D2发布会的所有演讲者的标题，用失望地语气叹息到：没有亮点。

咳……与手机市场相似，在我看来，当下的前端生态在充分拥抱开源、技术实现方式公开的前提下，也处于从寡头垄断逐渐向垄断竞争市场的过度阶段。两个竞争团队为了抢占专利与占有率先机，会采取提早发布0.0.1版继而快速迭代小版本的策略。这样的结果是，部分大厂发布的产品和技术框架在正式版交付前已经在社区炒得火热。与此同时，很难再看到某个大厂的前端团队，憋大招般地放出一个全新概念的框架和库，其底层采用全新的支撑技术。

然而我认为，不放大招恰好是前端环境透明开放、良性循环的结果。你只要稍稍关注当前热门的前端产品的演进路线，会发现他们各家都汲取了 YUI 的教训，从高度集成的重型框架逐步拆分成积木般的性质不同的模块。从构建工具，编译工具，与框架本身几乎没有耦合性开始，构造函数，渲染函数，Addon 工具函数也进一步分离，同时提供函数式与类对象式两种构造风格，虚拟 DOM，不可变数据，单向流与双向绑定，响应式编程等模块的选择性接入…不一而举。假设你熟悉前端框架的各个功能模块的组成，会发现搭一个新框架的成本和难度比几年前低太多了。

游戏届有句俗话叫「普通玩家使用默认配置，高级玩家使用自定义配置」，如果你还在吐槽选择太少，技术选型只有全家桶可用，如果你的简历里没法分辨「会 Webpack」与「会用 Webpack」的差别，如果你还在期待某个产品线和团队，憋大招般的放出一个框架或者库，易用性强，突然一下子解决工作中遇到的各种琐事，是不是可以反思一下平时工作中太过在意技术「亮点」了？

你在全端与全栈的十字路口徘徊不定，小心试探并观望着A党，R联盟， 和后起的V教各个武林高手西湖论剑，冷眼观望的曾经辉煌一时的J帝国忠臣的悲凉地引战呐喊；你刚练好了单向流的起手式，你像订阅小道消息一样刷着Hacker News、 Reddit 和 medium，左手 ReactiveX 右手 ClojureScript 两本武林秘籍，小心翼翼地分辨着哪本是你的独孤九剑，哪本是辟邪剑谱；此时你用眼角的敏锐地同时捕捉两个会场，突然激动地发现其中一套连招正是你的期待降龙十八掌。你抓起手机冲过去希望录下一招半式，要是会后再要份完整的 PPT 慢慢研习就完美了~却发现屏幕右上角标着「本派内部系统，传女不传男」。只好嘴角45度向下感叹到：没有干货。

咳……假若让我来定义「干货」这个词，可以理解为解决某个问题的特殊技巧、实现原理以及某个领域的最佳实践。我所看过的大会分享（包括录制视频）中，很少有讲师能在四十分钟到一个半小时的限定时间内，在照顾大部分听众能听懂的前提下，把自己技术团队大半年的工作，用深入浅出的方式，兼顾实现原理，覆盖重要特性，语言生动有趣地讲述出来。你感受下这句话定语如此之长，就知道这类型的分享要有满满地「干货」几乎是不可能的事情。

然而（又是然而），在前端领域的分享中，没有「干货」不一定是坏事。除了培训教学的分享外，我并不希望分享者在既定时间内费时解释其原理或者新技术科普的。为什么？因为我可以在会后有会议数倍的时间去研磨实现原理——与夜场的几位前辈讲得一样——通过研习前端技术或框架的源代码。根据以前 D2 的传统，至少阿里前端团队在 D2 宣讲的前端技术，总会在几个月内公开大部分源码，某些团队干脆直接贴出项目github骗star，笑。对于这类以代码和框架为产出的项目，通常开发团队都乐于接受开发者的有效反馈，只需要掌握读源码和调试技巧，多去issue上针对性地提问，获取到你要的干货不是难事。

对于暂不打算公开源码但有线上商业产品的前端技术或内部系统，通常会着重讲解某种特殊场景下的特定的实现思路。如果你关注到某个实现细节，通过分享者留下的联系方式，正确地提问并且带着问题去一对一请教（最好是邮件或者私信一次把问题说清楚）和获取反馈（能解答的都会直言相告，可以提前想想用什么信息与大神交换）。可以对分享内容和方式提出中肯的意见，作为不错的切入点。当然，对于「你先加入我们团队我再详细解答」的情况，我也没什么更好的办法，见招拆招吧……

那么在分享中应该捕捉什么关键信息呢？我更倾向于倾听和试图理解讲师在什么环境下，面对怎样的受众，为了解决什么问题而做出了怎样的抉择和妥协。此时不必太过在意听懂每一个技术细节（全听懂的反而不正常），也不要因内容不适合你当前的技术场景就全盘否定这个技术方案。未来的前端，很可能在框架层面抹平，根据特定的场景搭积木般选择接入与之适应的特性模块与工具。

用 Fusion Design 举例：可以思考一下讲师是如何运用「开闭原则」对模块样式种类进行变量封装与抽象的。在实现层面， DPL 对应 React 模板的技术，结合既有组件库的实现方式（antd 的 perfix 命名空间，react-toolbox 的 mapToCssModules，blueprint 的classes）等实现类似 UIkit 的动态换肤功能，我预计不会有特别高的技术门槛（通过动手实践，转化成自己团队的东西）。我真正在意的是，设计一套DPL作为各类产品线的设计师与前端工程师桥梁，在推广阶段一定会经历各种实现阻力和妥协。这种工程实践方面的真正「干货」，各种曲折，岂是通过一场分享即可全盘知晓的呢？

总得来说，亮点和干货少了，KPI 驱动的轮子也消停了。作为听众不要对期待参加某场技术会议，效果立竿见影。不要急于从一次分享中贴标签，试着站在分享者的角度理解当前技术解决什么场景的问题。像D2夜场的各位前辈总结的那样：如果想深入到技术使用场景和细节，那就花一万小时阅读源码动手实践吧；如果想背后的设计思想和妥协，那就带着问题找作者一对一交流吧；如果你想通过会议增长见识，拓宽视野，那就带着一颗虔诚的心面基吧！（好押韵~）

勿忘初心，来过，爱过。

利益关系：没正经用过阿里前端产品，但从其开源项目中受益颇多的开发者。

-EOF-