这两天参加了 GMTC 大会，会后又听大佬们讲了整整 5 个小时，
感觉收获很多，也产生了不少对未来的担心。
整个大会印象深刻的事情有好多，这里想记录一下，供以后参考回顾。
像这么大规模的前端大会，以前参加过的只有 D2 了，
但是跟以前参加 D2 相比，此次参会似乎少了很多激情，不想见任何人，
只想 “清空自己” “变得像蝴蝶一样” 去各个会场从零开始学习（语出第一场 #李佳）。
养成兼容并包的思维习惯
#玉伯 的演讲《前端现状之痛及未来趋势》带着很纯正的阿里味，然而很多人却对 “阿里味” 有着不够清醒的认识。
最近圈子里染上了很多不良习气，人们喜欢跟大家一致的 “嘲讽” 某件事物，
这是一种从众心理。
这种缺乏独立思考的习惯，非常的不利于个人的思维发展。
很多 “阿里黑” 也是如此，没能做到理智分析每句话背后的原因，
将语言跟语言某一种的解释强关联起来，让自己变成 “阿里黑” 却没能获得更多的进步。
每一句带有 “阿里味” 的原话，其实并没有带着太多情绪，只有把自己摆正，才能得到对自己最有帮助的解释。
正如佛家所言：你心里有什么，你看到的就是什么。
我以前也非常反感阿里看待 “技术” 的方式，凡事必谈目标、业务、投入产出比，
甚至某个阶段让我认为，这是否一个以商业作为核心价值的公司，所不得不沾染上的 “陋习”。
其实这是因为当时的认知还不健全，无法容纳与自己相反的观点，
现在看来，以 “目标” 或 “业务” 为导向的思维方式，并不失为一种 “有用” 的思维方式。
能做到思维切换，才是兼容并包、集众家之所长。
做技术要低调
做技术很容易 “飘” 起来，不管技术人员口头上怎么说的，其内心难免有一种自豪感涌现出来。
这体现在几个方面。
- 其一，总想追求更难、更艰深、更底层的技术。
记得一次 “海阔天空” 大会上， #玉伯 在回答问题时提到，
做技术并不是越底层越好，每个层次都有深度
技术人员对底层技术的 “盲目” 崇拜，会让自己的职业发展 “飘忽不定”，表现出来的形式是 “乱点技能树”。
在职业发展的初始阶段，多学一些知识确实是没问题的，也是应该的，
但如果一直以这样的心态治学，就会逐渐丧失 “分析个人核心竞争力” 的本领。
我们会发现要想在社会竞争中脱颖而出，会技能能解决问题是必要的，
但能不能有一个好职业发展，却并不仅仅取决于个人能不能解决问题，因为能解决的问题的人太多了。
我认为好的职业发展，应该建立个人的稀缺和竞争力之上。
我常跟朋友们解释，公司能雇佣一个员工的原因，
大概率不是因为我们能解决问题，而是，我们是能解决问题的人里面，性价比最高的那个。
所以坚持自己的赛道，不要总是追求 “更底层” “更酷炫” 的技术领域，
反而容易打造自己的核心竞争力，让自己在众多同学同事之中脱颖而出。
- 其二，不要说别人做的工作没有技术含量
技术人员经常容易掉入鄙视别人工作的陷阱之中，这次演讲之中 #玉伯 提到了低代码平台，
目前并不存在谁比谁更有技术含量，当你把某个领域做好做深时，才有技术含量。
技术人员说别人做的工作没有技术含量，其实是一种不合理的 “傲慢”。
因为很多实际问题的技术方案，从一开始都是简单的，这是因为场景还不够复杂。
当技术产品不断的迭代起来之后，所要解决的问题越来越多，方案也会变得复杂困难。
另外一个方面，很多技术方案从一开始只是自己拿来玩的一个实验用品，
别人对它没有那么高的期待，所以它就复杂不起来。
所以在谈到框架设计时， #玉伯 提到，
框架一定为了解决某个具体的业务问题服务的，而且要跟自己的切身痛点相关
即要有目标感，还要感同身受。
技术人员的 “傲慢”，很容易 “扭曲” 目标，或者形成 “扭曲” 的感受。
- 其三，低调不代表妄自菲薄，要看到自己的优势
#玉伯 提到美国教育不擅长培养软件工程师的时候，全场掌声雷动，
不同国家的教育体制是不同的，工程师在中国这个土壤上，确实更容易培养出来。
也只有摆脱 “怨念” 才能看清自己的优势和特点。
我们确实有更低的用工成本，也有最适合工程师的全套教育体制，
所以未来软件开发大军会越来越壮大，
我想这也许是 #玉伯 坚持做生产力工具（这么大的潜在用户群体）的原因了吧。
能用前端技术实现的，迟早都会用上前端技术
越来越多的前端工程师，会成为 SaaS 型产品工程师，总人数会超过后端工程师
在低代码、智能化、体验型工具等融合创新领域，中国有机会引领世界
“内卷” 的反义词不是 “外卷”，而应该是 “创新”
工具开发要具备产品思维
工具能体现出工具作者本身的修养。
我曾不止对一个人说，#尤雨溪（#尤大） 能做出好用的工具框架，并不仅仅是因为他技术一流，
更重要的还有以下几点：
能从错综复杂的趋势中，抓住主流趋势，顺势而为
知道谁是用户，不遗余力的对用户友好
擅于推销自己的观点
（1）顺势而为
就拿 Vue 来说，当时正赶上前端框架成型期，Vue 借鉴了 Angular 和 React 两大框架，
在框架角逐的恰当时刻，推出了 Vue 是很好的一种借力，借助了历史的潮流。
Node.js 的作者 瑞安·达尔 也是一个非常擅长借力的人，刚好借助了前端开发如火如荼，
以及 Google 推出了名为 “V8” 的快速 JavaScript 引擎，
才有了 Node.js 之后的快速发展。
TypeScript 的推出也如出一辙，借着人们日益加深的对类型的要求（时逢 Rust 这种语言的崛起），
以及 VSCode 作为主流开发工具的趋势，各方面互相加成。
vite 结合了时下 IE11 退出历史舞台，ES Module 的广泛支持，
社区里已经开始萌芽出结合 ES Module 的构建工具了，例如 Snowpack，
这时候推出 vite，又一次结合了潮流的趋势，大家有一种该来的终于来了的感觉。
这样的例子数不胜数，然而大多数工程师却都难以做到这一点，
他们要么不太关心 “国家大事”，要么对错综复杂的趋势没有自己主观的判断、人云亦云。
于是错过了一个又一个影响更多人的机会。
（2）为用户服务
有不少工具开发者的目标不是很明确，甚至有些人开发工具是为了让自己 “爽”，所以不想做脏活累活。
这样开发出来的工具，其实很难真正的帮用户解决问题的。
要想让用户买单，首先要明白用户的需求是什么，不能以个人的意愿出发。
就像你不能认为 vite 是解决 #尤大 自己在开发网页时遇到的问题的一样，
其实 vite 所解决的问题场景，并不是 #尤大 在实际开发过程中全都能遇到的。
这就引出了一个问题，他是如何识别到要解决哪些问题的？
有过工具开发经验的人应该都知道，这件事的取舍远非想象中的那么简单。
没有深入的调研或者访谈，或者需求的收集或分析，不可能得出客观的答案。
很多主观意愿上要支持的场景，其实都是假设。
基于共识，可以做更多的假设，有了这些假设，就可以做更多的优化
我在两年前刚好做过前端构建优化相关的事项，我的切入点是解决在前端应用在云上的构建速度。
这个切入点的把握，现在看来就有失偏颇。
而 vite 紧紧抓住了前端应用在本地环境中的构建速度，把 dev server 优化到了极致。
在开发环境中，开发者可以使用更高级的浏览器特性，而且是高频使用场景，
反观测试环境或生产环境在云上的构建，就不是那么频繁了。
所以 vite 显然比我做的构建优化更能契合用户需求，
你可以说这是 #尤大 天才的一面，也可以说 #尤大 比我更理解用户，更能抓住用户痛点。
所以一个伟大的工具，总是离不开其用户的，早期大家对 Vue 官网也是一致的好评，
反观很多工具甚至连一个像样的 README 都没有，
这种自始至终贯彻的对用户的尊重，最终会沉淀到工具中去，让它变得越来越好用。
（3）擅于推销自己的观点
我还记得 Vue 刚开始发布的时候，经常看到 #尤大 在各大群里做广告，
当时还想着这肯定是一个富二代想搞一个个人项目，
但也想着那时候他一定很忙，因为项目刚开始时，会有各种各样的问题出现。
而观察一下我们自己呢，做出了一个工具之后，要么不敢将它推广给更多的人来使用，
要么就 “等着” 更多人去发现它。
我认为这是一种非常 “低效” 的工具开发方式。
很多工具面临的并不是好用不好用的问题，而是有没有人来使用的问题。
没有人来使用，就没有 “被需要” 感，这一工具就没有存活的空间，
只有 “来需求了” 才能逼迫它不断的进行技术迭代，相辅相成。
所以对于工具来说，没有需求并不是件好事情，甚至是 “项目终止” 的风向标。
我们得不遗余力的推广它，让它活下来。
想一下如果我们是 vite 的开发者，会在哪些场子介绍它呢？
会不会利用 GMTC 做一个专场分享呢？敢不敢呢？愿不愿意呢？
还是等着别人去 github 发现这个项目？
看待问题的方式
问题就在那里，用不同的心态看待问题，就会得到不同的结果。
这次 GMTC 听了好几次演讲，感觉最有感染力的场次是 #刘晓丹 的《互动视频》，
技术大会的分享大多是分享自己解决问题之心得的，
套路是，我们遇到了什么什么问题，多么多么难，我们费了多大的劲解决了。
但是听 #刘晓丹 的演讲却不是这种感觉，就像听一段动听的故事，娓娓道来。
似乎遇到的每一个技术问题，都不是那么讨厌，而是办法总比困难多。
让我想到自己平时在遇到困难时，总容易释放出一种 “怨气”，这是心态还不够健壮的体现。
有些人的演讲透露着 “骄傲”，有些人的演讲 “节奏” 快得让人跟不上，
所以我认为 “演讲风格” 也是个人处事态度的缩影。
我们怎么对待世界，世界就怎么对待我们。
这其实来自于在做系统值班时的体会，每个人擅长什么领域，当周一般都会遇到什么问题。
世界会按着我们看待世界的方式反馈我们。
你看到的世界是和善的，是有计划有安排的，是有条不紊的，
那么你的生活也将变成如此。
你埋怨世界，世界就偏偏按照你埋怨的方式出现。
信息量巨大的晚餐
第二天晚上大会结束后，有幸跟三位讲师 #贺师俊 #俞天翔 #Jack-Works 以及一些好友一起吃了个饭，
全程都在专心听前辈大佬们的指点，感觉受益匪浅，
只是我的个人介绍环节没事先准备做的很不好，以后还要加强锻炼。
（1）笑话和梗
我个人有个坏毛病，就是喜欢说一些 “冷笑话” 和意义晦涩的 “梗”，
自我介绍的几分钟里，我感觉很多笑话没有被识别出来，反而显得很尴尬。
- 反对观点的重要性
当大部分都喜欢一个观点的时候，这个观点本身就变成了一种 “权威”。
新接受到这个观点的人，就失去了判断这个观点好处和坏处的能力。
当别人都有一顶帽子的时候，就没有人关心你帽子的材质了，关心的是你有没有帽子。
我拿函数式编程举例，几年前它像一阵旋风一样刮了好久，似乎每个前端工程师都在以了解 “函数式” 为荣，
但据我了解，大多数前端对函数式仅停留在浅尝辄止的水平，但仍不影响他们向其他人散播函数式的好处。
所以应当勇于针对问题仔细研究，并提出发对意见。
一个观点不可能只有完全正面的评价，如果是，那恰恰说明这个观点已经形成一种 “宗教式” 的信仰了。
函数式编程是如此的，“类型体操” 也是如此。
当天，#贺老 也在感慨，我们这么小的一个圈子，居然有一半人是 “类型体操” 的拥护者。
这些 “类型体操运动员” 也许没有想到，自己恰好是微软 TypeScript 推广战略中的一个棋子吧。
- 关于写 TypeScript
这个 “梗” 埋的有点深，像是对 Guido 的致敬，但我确实离 “I wrote xxx” 的水平还相差很远。
Guido 是 “写过”，我应该只能算是 “读过”。
去年我用了接近半年的时间读了 TypeScript 的一些源码，写了一点点跟 TypeScript Compile 本身相关的代码。
所以，当时称自己 “写过” 一年的 TypeScript，但自己仍是一个 JavaScript 程序员。
关于 TypeScript 的类型检查，我认为，
类型标注是否完整，应该取决于项目的现状，是一个折中的产物，而不是追求完美。
TypeScript 之所以需要那么多的类型标注，完全取决于微软在做类型系统设计时候的考量，
隐式类型系统显然比显示类型系统更难开发，并且显式的增加类型标签，会在推广 TypeScript 时更有辨识性。
TypeScript 的 type checker 并没有接受任何扩展，
只能通过 “类型体操” 的方式，让程序员在类型检查期间用类型推导进行计算，
这就加大了 “类型体操” 的难度，调试起来非常困难。
以上观点也有不太恰当的方面，但是只有自己深入了解过某个领域，才能避免被 “信仰” 洗脑。
（2）关于语言设计的取舍
#贺老 谈到了 SsTS（Subset of JS/TS） 的设计初心，使我立即想到了 Scheme RnRS 的设计哲学，
Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.
TC39 关于 ECMAScript 语言的走向，已经渐渐失去把控力了，越来越多 feature 被加入到语言标准中。
浏览器厂商的话语权越来越大，但他们只能代码语言者的利益，却很难代表语言用户的声音。
语言应该尽可能的精简，精简到没有什么特性可以删除，而不是尽可能的臃肿。
这是语言设计者的工匠精神。
但这种工匠精神往往在现实中是需要妥协的，也许是性能的取舍，也许是工程效率的取舍。
所以又回到了那个问题，我们总得考虑，提供怎样的方案为哪些人解决哪些问题。
并且还要考虑，这个方案我们如何推广下去，让它活下来。
从商业或者经济角度考虑问题，似乎更容易看清这件事情的本质。
（3）关于开发资源
这一点我也是感慨很深的，现在前端很多领域都进入了深水区，单兵作战越来越难了，
所以要么能找到一个很好的切入点，吸引一大批开源爱好者来共建，
要么手头上就必须有开发资源，才能把事情做成。
席间大佬们提到了，如何解决业务压力跟技术选型之间的矛盾，
技术人员最容易被挑战的话题是，如何量化技术所带来的的业务价值。
我的观点是，赋予自己做的事情以意义，本来就是技术人员的必修课之一。
能不能争取到上级的认可，是否向上对齐了期望，能否争取到更多的开发资源，
这也是想要做点 “大事” 的工程师的必修之课。
如果你手里没有资源，还想做大事，这几乎是不可能的。
空有一个好的想法，却不能带动更多人为这个想法努力，也是不可行的。
结语
以上是就是前两天 GMTC 大会的所见所感了，
中国古话说的真好，做成一件事当真离不开 “天时、地利、人和”。
在合适的时机，选择有利于自己的位置，找到拥护自己的人，才能把事办成。
今天跟同事聊天时还在想，GMTC 这个大会能够办好也真不简单，
门票这么贵，还能挤爆那么多人来参加，
这正是做好了 “天时、地利、人和” 的一个绝好的例子吧。
在软件开发路上，我们还只是小学生，前面有一批大佬帮我们铺平了道路，
我们要做的是前赴后继，做好自己的事情，并为后浪打好基础，
希望能有功成身退的那一天吧。