
草原上突然出现了三万头猪，你要如何领导一个数十人的团队，在一个月内抓完这些猪，并且把它们变成冷冻猪肉？

正确的做法：把成员划分成抓捕组、杀猪组、储藏组、后勤组，建立分工协作机制，并且尝试优化这个机制。这样即使再来三万或者三十万头猪，只要填充人力就可以解决，这就是管理的艺术。 

错误的做法：在草原上闲逛，看到一只猪就喊几个团队成员过来：“这里有一头猪啊！你们这么多人整天都在干什么？这么久了都不抓走它？”


寓言一则


## Jamstack是什么？

Jamstack 指的是一套用于**构建现代网站的技术栈**，可能过去的一些文章通常会把它们理解为 **J**avaScript、**A**PIs、**M**arkup，但其实现在这个概念已经被扩大了，Jamstack 的官网上将它的核心概念归纳为 **Pre-rendering**、**Enhancing with JavaScript**、**Supercharging with services**。

[For fast and secure sites | Jamstackjamstack.org](https://link.zhihu.com/?target=https%3A//jamstack.org/)

当然掉书袋没什么意思，用人话来解释的话，当下绝大多数 Jamstack 网站，都是这样的技术栈：

**1. 使用网站生成器预渲染整个网站**

整个网站在部署前，会被**网站生成器（SSG, Static Site Generators）**构建和优化为一系列的静态页面和静态资源，这样整个网站可以被托管在 CDN 上，加载速度得到最大程度地优化，安全性也得到保障。

这里的网站生成器包括但不限于：[Gatsby](https://link.zhihu.com/?target=https%3A//github.com/gatsbyjs/gatsby)、[Hugo](https://link.zhihu.com/?target=https%3A//gohugo.io/)、[Jekyll](https://link.zhihu.com/?target=https%3A//jekyllrb.com/)、[Eleventy](https://link.zhihu.com/?target=https%3A//github.com/11ty/eleventy)、[NextJS](https://link.zhihu.com/?target=https%3A//nextjs.org/)……

![img](https://pic1.zhimg.com/80/v2-9fcb49402c7d59db87dfc0d8ef4eb900_1440w.jpg)

**2. 使用 Headless CMS（无头 CMS）管理动态内容**

如果想要网站承载动态内容，那么可以接入各种 Headless CMS（无头 CMS），这些 CMS 系统会对外提供 API，网站生成器可以调用这些 API 拉取数据，**将动态数据渲染成为静态页面**。

这里的无头 CMS 包括但不限于：[Ghost](https://link.zhihu.com/?target=https%3A//github.com/TryGhost/Ghost)、[Strapi](https://link.zhihu.com/?target=https%3A//github.com/strapi/strapi)、[Netlify-CMS](https://link.zhihu.com/?target=https%3A//github.com/netlify/netlify-cms)、[TinaCMS](https://link.zhihu.com/?target=https%3A//github.com/tinacms/tinacms)……

![img](https://pic4.zhimg.com/80/v2-074202b1d2ad92e46edcc85cd7b73683_1440w.jpg)

**3. 使用 HTTP API 增强网站的功能**

在登录注册、评论框等需要后端支持的能力上，Jamstack 网站通常会使用微服务提供的 HTTP API，或者一些第三方的 BaaS（后端即服务）能力。

除了以上三个主要特点以外，Jamstack 的网站通常还会有下面的特性：

- 全站托管于 CDN 上
- 原子化发布（每次发布都是一次全量、原子性的发布）
- 灵活的文件缓存策略
- 基于 Git 的全自动构建、部署流程

## Jamstack有什么优势？

**1. 相比于纯静态网站**

纯静态的网站很难承载动态的内容，内容改动通常都是要直接修改页面的代码，这**对于内容管理人员（很可能是非技术人员）来说非常不友好**。

而 Jamstack 的网站，通常会使用无头 CMS 来将内容管理抽离出去，内容管理人员可以直接在这些 CMS 系统的 UI 界面上进行内容修改，然后触发整个网站的重新预渲染，以及部署。

**2. 相比于传统动态网站**

这里的“传统动态网站”指的是用 PHP、Ruby On Rails、JSP 甚至更古老的 CGI 构建的网站，以及基于这些技术产生的建站工具比如 WordPress、Drupal 等等。

这些传统网站的劣势在于，它们在运行时都需要一个实时在线的服务端，这些服务端负责处理请求、渲染页面，这就很大程度上降低了**服务的可伸缩性和稳定性**（想象一下，你迁移扩容一个在线的 WordPress 网站有多么麻烦）。

Jamstack 由于是直接使用 CDN 分发静态的页面，完全不需要渲染页面的服务，网站的伸缩性、稳定性可以得到最大的保障。

**3. 相比于单页应用（SPA）**

大概五年前，随着各种前端框架的成熟，越来越多的业务逻辑迁移到了前端处理，这也就诞生了 SPA 的概念，也就是整个网站的 UI 层，由浏览器端来完全接管。得益于 HTML5 和现代浏览器的一系列特性，这样的做法可以保证最好的用户体验。

但是 SPA 最大的问题在于它**对 SEO 不友好**，因为 SPA 的页面内容都是靠浏览器异步获取、渲染的，虽然 Google 为首的大多数搜索引擎渐渐地支持爬取 SPA 的内容，但是这依然是一个隐患。另外，由于 SPA 需要异步加载数据，首屏内容需要在在加载、运行 JS 之后才能看到，也给用户打开网站的体验带来影响。

而 Jamstack 的页面本质上都是托管在 CDN 上的静态页面，搜索引擎可以直接爬取这些静态内容，首屏与静态网站一样，可以直接展示内容，而不需要等到加载运行 JS 之后。

**4. 相比于 SSR 应用**

目前市面上的几大前端框架都支持了服务器端渲染，也就是 SSR 的概念，这些 SSR 技术也成为了 Jamstack 的基础之一。但是典型的 SSR 应用和传统动态网站一样，都是需要一个在线的服务来渲染页面，同样**会有运维和安全性上的风险**。

Jamstack 从技术角度上讲，可以认为是 SSR 技术的进阶，也就是提前用 SSR 预渲染大部分页面，然后将这些页面部署在 CDN 上，随后根据网站的数据变化，重复预渲染、部署即可。

| 特性            | Jamstack | 纯静态网站 | 传统动态网站 | 单页应用（SPA） | SSR应用 |
| --------------- | -------- | ---------- | ------------ | --------------- | ------- |
| 使用CDN全站加速 | ✅        | ✅          | ❌            | ✅               |         |
| 方便的内容管理  | ✅        | ❌          | ✅            | ✅               | ✅       |
| SEO友好         | ✅        | ✅          | ✅            | ❌               | ✅       |
| 首屏渲染速度    | ✅        | ✅          | ❌            | ❌               | ✅       |
| 不需要在线服务  | ✅        | ✅          | ❌            | ✅               | ❌       |
| 安全性          | ✅        | ✅          |              | ✅               |         |

当然，Jamstack 也不是万金油，不可能完美适应所有场景，Jamstack 最适合一些**内容更新不太频繁的网站**（比如新闻、电商、文档）。它不适合 Feeds 流、聊天室、论坛、个性化推荐这样高度动态化的网站，以及邮箱、编辑器这样偏重型的 Web 应用。

## Jamstack的商业价值

在国外的电商行业，Headless Commerce（无头电商）是一个非常火的概念。

所谓的无头电商，就是把用户端的 UI 展现和整个电商后台服务进行解耦，去除掉了 UI 层，也就是“头”，毕竟每个公司都不想自己的网站、购买体验和别人一样。

![img](https://pic3.zhimg.com/80/v2-f9fceb792e467569442afb113ffaf552_1440w.jpg)

无头电商只对外暴露一系列的 API，让客户公司可以使用这些 API 构建自己的电商网站。举一些具体的例子，比如 Salesforce 正在推行的 [Open Commerce API](https://link.zhihu.com/?target=https%3A//www.salesforce.com/video/2520463/)，逐渐成为现在电商开放 API 的标准。换句话说，这个做法很类似现在国内很多公司在推行的**“中台化”**、**“大中台小前台”**的概念。

所以这和 Jamstack 有什么关系呢？

你会发现，Jamstack 推行的这一套技术栈，包括**预渲染动态数据的静态页面**、**无头 CMS**、**微服务 HTTP API**，几乎和无头电商的理念完全一致，或者说，无头电商就是 Jamstack 一个最贴切的应用场景。

在前段时间 Vercel 举办的 [Next.js Conf](https://link.zhihu.com/?target=https%3A//nextjs.org/conf/expo) 上，主要赞助商除了 AWS、Github、Firebase 这样的云平台以外，大部分都是适用于 Jamstack 的第三方 API 提供方、或者一些无头 CMS，这也从侧面体现了 Jamstack 目前在国外的生态繁荣。

![img](https://pic3.zhimg.com/80/v2-e87cbf37634b2b5de748195b08e56a9a_1440w.jpg)

但是在国内市场上，或许不那么乐观：国内 Web 网站本身就处于一个很尴尬的状态，各大公司的主要业务都是**以移动端 App 为主要入口，Web 网站缺少流量来源**，或许只有一些特性类型的业务（比如新闻、电商网站）需要 Web 站点；电商市场方面，国内大部分中小型公司都处于**严重缺乏信息化**的状态，更多依赖于阿里、京东这样的大平台方提供的基础系统，还远远没有自建整套流程的需求，无头电商也就无从谈起。

## 尾声

从技术角度上讲，Jamstack 本质是一种**增强的静态网站**，它的出现很大程度上得益于各大云厂商提供的云上能力，包括更容易管控的 CDN/DNS、Serverless Function、DevOps 工具等等。

随着国内相关云计算基础设施的成熟，Jamstack 在国内几家云平台的支持程度也会慢慢提高，我们完全可以期待未来 Jamstack 部分替代传统的 WordPress 等建站工具，变成新一代的建站技术栈。

Jamstack，下一代Web建站技术栈？


从加入腾讯云以来，团队的业务一直发展得很好，团队扩充很快，人数从刚来时的不到十个人，变成了现在接近六十人的大团队。

我也是第一次亲眼目睹一个小团队成倍地增长（之前呆的团队都没怎么快速增长过），这当然很让人兴奋，但也能观察到不少随着团队增长而带来的问题。

# 唯上

随着团队的扩大，我们也从一个小团队非常扁平的结构，慢慢分化出了好几个层级。伴随着的，就是内部也开始隐约出现“唯上”的行为，Leader 说什么就是什么，要做什么那就是要做，很难产生任何阻力和反对的声音。实际上，这种行为不仅对自己没好处（把自己变成了可拔插的工具人、执行的机器），也同时对整个团队没有好处（领导者不可能是全知全能的，错误需要反馈才能修正）。

在控制论里，一个没有负反馈的系统，是很难做到稳定的；而“唯上”这种行为，不仅没有负反馈，可能反而还是一种正反馈，放大了系统的整体误差，让系统变得更加不稳定。

从整体上讲，腾讯内部的宣传是**强烈反对唯上主义**的，各种内宣和制度设计上都能看出这一点。但就我观察而言，个别人还是依然存在官本位的思想。从根源上讲，**这其实是一种惰性**，它的潜台词是“我不对这个事情负责，只对上级负责”，毕竟**应付上级比真正解决问题要简单太多了**。

# 信息同步的困境

团队人数、层级的增加之后，信息传递和同步的复杂度也伴随着指数级增长，这直接带来的问题就是团队**很难建立起一个共同的愿景**，每个人都在自己有限的空间里各自为战，而不知道整艘船要驶向何方。

为了解决这个问题，就只能引入各种会议，各种专项群，以维持大家对整体目标的关注度。但这些东西的引入，又带来了人力上的磨损：本来过去小团队几个人站着讨论几分钟就能定下来的事情，变成了要提前预约、拉通各方、开一两个小时的正式会议才能确定（有时还没法完全确定）。

这就是人月神话里一个很经典的例子，假设你有一个 10 人团队，研发效率是 1；那么当你的团队扩大到 20 人，研发效率可能也只能增加到 1.2。这里面 0.8 的损耗，就是花在了信息传递和同步上面。而各种软件工程、DevOps、协作工具、项目管理学就是在尝试降低这 0.8 的损耗。

# 短期目标与长期目标

大公司都是有明确的考核周期，在腾讯是半年一个维度进行考核，团队和个人都是。

有了“半年度考核”这把利剑悬在头顶，让大部分团队和个人都需要把重点集中在短期目标之上，直接导致了下面的业务侧作出很多令人匪夷所思的事情，包括但不仅限于：

- **杀鸡取卵**：口碑、影响力、知名度、生态？这都不重要，我们这半年目标就是要变现，把招牌砸了也要变现。你问明年怎么办？先活过今年再说吧！
- **滥竽充数**：为了汇报时能有足够的流量增长，不从根源上思考如何优化产品、触及核心用户、让产品良性增长，而是靠各种渠道带量（手机QQ里那满屏幕的红点就是佐证）。毕竟一个人点进来看了看就走了，再也不回来了，也是算一个活跃用户的嘛。我一直觉得靠渠道拉量就和毒品一样，一旦吸了，爽翻天就再也离不开了。

这些问题的本质是来源于**短期目标在考核里的比重太大，以至于它背后的长期目标被掩盖了**，让人不得不为了利益做出这些事情，哪怕这些对于产品的发展而言完全是南辕北辙。


大公司病？


- 生于 95 年
- 技术爱好者
- 致力于研究、设计优秀的技术产品

# Experience

- 2021.12 - 今，腾讯云云开发产品 Leader
- 2018.9 - 2021.12，腾讯云（[云开发 CloudBase](https://cloud.tencent.com/document/product/876)），高级工程师
- 2017.7 - 2018.9，腾讯 SNG（手机 QQ、Now 直播），前端工程师
- 2013.9 - 2017.7，复旦大学电子工程系，本科

# Awards & Honors

- 腾讯 TC39 代表
- Node.js Core Collaborator

# Links

- [Twitter](https://twitter.com/_WeijiaWang_)
- [Github](https://github.com/starkwang)
- [知乎](https://www.zhihu.com/people/starkwang0131)


About

前几周收到了 HR 公众号发过来的入职周年庆贺邮件，才想起来我已经在腾讯干了整三年了。

三年的工龄，在腾讯内部不算长也不算短，恰恰是一个最为「中坚」的阶段：既要承担一线的 Coding、搬砖，也要开始慢慢学习掌握业务、管理、跨团队协作、商业运作这些程序员的“屠龙技”。

所以我想要写一些东西，记录、总结一下这个节点我的所思所想。

![img](https://picb.zhimg.com/80/v2-41698c6f6d769a7c7b9c4316f62e0091_1440w.jpg)

## 这三年我在腾讯都做了些什么？

17年刚刚毕业入职的时候，我在 QQ 的 Web 团队（AlloyTeam），当时主要就是负责手机QQ、PC QQ里面的一些 Web 承载的页面，面对的场景都是最经典的 hybrid 开发，这块说实话在当时已经趋于完善，对我而言主要就是**学到了每天数亿级访问量的页面，是怎么做开发、测试、发布、监控**等等（虽然当时内部的基础设施现在看来很落后，但这一套老系统还真的挺完善的）。

后来17年底部门拆分，我所在的小组被拆去了互动视频产品部，这是一个主要做 Now 直播、花样直播、QQ 群视频的部门。当时我的小组一共 9 个人，里面一大半都是近两年毕业的“新人”；业务上，大部分也都是新项目，所以当时可以**有大量的机会去尝试前端的新技术，语法特性、框架、浏览器、基建设施，都可以用换成最新的技术栈。**这也是我在腾讯“画网页”画得最爽的时候，积累了很多对于前端框架的比较深入的知识。

在这个期间，业余时间很闲，就开始为 Node.js 社区做一些共享，**在 18 年初的时候，也被提名成为了 Node.js Core Collaborator**。

后来18年的上半年，越来越觉得自己作为一线的“码工”，光是**技术上的优化很难对业务产生真正的影响力**（毕竟没有谁会因为你的页面体验好，就进来看你家的直播吧？）。所以当时也陷入了迷茫，感觉自己有很强的能力，但是却无法兑现成现实的东西，拳头都打在空气上的感觉。

于是 18 年夏天的时候，在一位前同事的安利下，我决定转岗去了腾讯云，也就是现在我所在的[云开发 CloudBase](https://link.zhihu.com/?target=https%3A//cloud.tencent.com/product/tcb)团队（当时还只有「[小程序·云开发](https://link.zhihu.com/?target=https%3A//developers.weixin.qq.com/miniprogram/dev/wxcloud/basis/getting-started.html)」这一个产品）。

正式转岗、搬工位的那天下午，正好是 9 月 30 号，也就是腾讯著名的「930 变革」，公司内发了正式的全体邮件，把几乎所有的 toB 业务都划分到了新的 CSIG，而我正是在办公室绵绵不绝的议论声中，收拾东西搬到了腾讯大厦，那个兵荒马乱的下午还真有一种天选之子的感觉（逃）。

到了腾讯云之后，我觉得工作的内容让我愉快了很多很多，因为本身负责的就是面向广大开发者的技术产品，所以我**能接触、设计、主导大量硬核的技术需求，而不是简单地画画网页，**比如：

- 设计、开发、维护亿级调用量的 Node.js 服务；
- 设计几十万开发者都在用的数据库 SDK；
- 解决 Node.js 一些底层内核问题；
- 修社区开源项目的 bug；
- 尝试对业界流行的框架做适配和兼容
- ……

几乎每一件事情都让我感到兴奋，也可以让我有地方施展拳脚。

后来 19 年的时候，因为团队一时人手不足，有时候我也会充当售前架构师的角色，全国到处飞，去见我们真正的客户，这期间也对国内云计算整个行业有了一定的认识。

所以在云开发团队的这两年，也是我成长最快的两年，无论技术上还是业务上（哈哈我即使说了这句话 leader 也不会给我发红包的，如果看到了请微信转账谢谢）。

## 程序员的职业价值和发展

首先我想探讨一下程序员或多或少都会思考一个问题，那就是「程序员的价值在哪里体现？」，这个问题我们可以从程序员的几种身份开始说起，我觉得程序员起码会有四种身份：

首先程序员是有「**执行者**」这个身份的，这个身份本质上和工地、流水线上的工人并没有太大区别，硬要说有，可能也只是工作内容、专业程度的不同而已。这是最廉价的一层身份，对于公司而言，你只是一个可拔插的生产机器而已，明天换成别人其实也差不多。

然后就是「**设计者**」这个身份，和上面的区别在于，**设计者能对涉及的技术项目产生影响，决定项目的各种选型，而执行者不行**。这里的设计可能并不是指产品、业务上的，而是技术上，比如你的公司想要做一个新的应用、新的服务，如何选择合适的技术栈确保业务顺利的运行、增长，就是一个很考验经验的任务了。（对于很多非技术驱动的业务，例如 toC 产品，程序员的天花板很可能就是这里了）

再然后就是「**推动者**」，和上面的区别在于，**推动者可以对业务产生直接的正面影响，可以影响业务的决策，而设计者不行，**比如业务本身就是一款技术产品（例如云计算业务、微信小程序），或者业务本身就依赖于技术上的竞争优势（比如各大公司的推荐算法团队）。这也是我当时转岗到腾讯云的原因之一，我希望能靠我的学识、能力，去真正推动一款产品的发展，而不仅仅当一个执行者或者设计者。

最后就是「**开创者**」，和上面的区别在于，**开创者能够开始一个新的赛道，引导业界的下一步走向，而推动者不行**。理想主义地说，就是可以用技术让这个世界变得更加不一样。比如各种顶级开源项目的作者，比如学术工业圈两头吃的大佬，这也是包括我在内的很多很多程序员梦想成为的人。

但成为开创者的路是很难很难的：

**第一条路就是，你在某个领域拥有绝对专精的能力，并且正好遇到了风口。**这条路上的标准模板，就是学术界往工业界转型的大牛们。这一点上，我在大学就确定自己并没有足够的耐心和兴趣做可能看起来没有什么短期收益的学术，我更喜欢解决实际的工程问题，所以已经放弃了。

**第二条路是，你是一个文艺复兴式的「全才」**，这里的全才不仅包括了技术能力，还有管理、交流、视野、逻辑思辨甚至审美、写作能力等等。这条路上的标准模板，就是优秀的独立开发者，还有大部分技术出身的公司创始人。在技术水平上，他们可能并不是最优秀的那群人，但他们懂得如何面对真正的用户、如何经营自己的项目，这些看起来很务虚的内容，并不会比技术问题简单多少。

刚毕业的时候我是一个**技术唯上**的人，觉得我只要有 Book Smart 就够了，学好数理化，走遍天下都不怕，这家干得不爽了，我可以立马去下一家，毕竟哪家公司不喜欢一个优质的螺丝钉呢？

但随着工作经验的累积，看到、接触到的范围更广，我发现如果未来需要突破一些天花板，不想当一颗螺丝钉的话，**光有 Book Smart 是完全不够的**（毕竟走的不是硬核科研路线），**Street Smart 在一些时候也是相当重要的**：你要学会如何推动手上的事情，如何向上向下管理，如何与别人达成利益一致，如何简单清晰地表达自己的想法，如何更有性价比地投入时间和精力…… 这些也是一个工程师的软实力所在，**随着工龄越来越长，这些看起来不那么硬的因素，或许就会成为区分点所在**。

（PS：不过我也要泼一盆冷水，以当下很多同行的技术水平之差，还轮不到拼这些软实力。）

## 大公司的生存之道

在腾讯呆了三年，就这样慢慢变成了一根「老油条」，也学到了不少在大公司生存的经验，下面几点是比较有深入体会的，所以想分享一下。

## 1. 提升你的影响力

几乎每家大公司，无论 OKR 还是 KPI 还是什么别的考评制度，一定都会有一项很重要的因素叫做「影响力」。所以每年考核季的时候（比如腾讯的一月和七月），你就能看到各种奇怪的开源项目、一连发好几篇的技术文章、内部分享课程、公众号推文如同雨后春笋一样冒出来，这些背后的推动力，就是对影响力的考核。（但我始终相信，长期来看影响力这一点并不是能够临时抱佛脚出来的。骗得过一两次考核，骗得了三年五年吗？）

所以如何建立影响力呢？

最简单的方法，就是去**吃下一个项目，成为项目的核心维护者**，大家遇到这个项目的需求或者问题，都会第一个想到你，把你默认作为 owner。当然这个前提是你有能力吃下项目，并且维护。众所周知几乎国内外所有的公司，很多项目的代码都接近「屎山」，我现在越来越觉得**能够短时间内搞清楚一堆屎山，并且渐进式地改良它，也是非常重要的能力**。

第二个方法，去**为团队提供好的、正确的东西或者决策意见**，这点在国内尤其重要。目前国内因为行业发展速度太快，基础知识过硬的程序员实际上是少数的，即使是大公司，也有很多人也并不是科班出身，做一些设计的时候**更多是基于多年的经验，而不是基于系统化的理论知识**（据我观察年纪越大，这点越明显）。

未来可预见的十年内，这个状况会一直保持。这就是能让年轻人打出优势的地方，也是我为什么除了感兴趣之外，平时都会读大量的专业书，哪怕跟我的工作领域并不那么相关。我们要做的是**出卖自己的知识、能力、学识给公司，而不是卖自己的人肉劳动力。**

## 2. 与其埋头加班，不如想想怎么提升效率

在国内工作，不可避免的一个问题就是加班，但其实大公司里，加班也分成好多种：

1. 工作量太大or项目赶时间而加班；
2. 白天时间都花在开会、讨论、对接各种人上了，没时间干活，只能晚上干；
3. 反正回家也没事干，不如呆在公司吃吃喝喝吹空调上上网；
4. 要绩效考核了，表演式加班。

后两种纯粹是自作孽，我们就不做评论了。主要想讨论下前两种加班：

前段时间因为团队业务的扩张，我也遇到了第 1 种的问题，当时的想法其实是很「头铁」的：突然来了这么多工作量，那就正面刚嘛。直接结果就是，我一个人干了好几个人的活，连续几周都处于工作压力很大的状态，对身心健康都造成了负面影响。后来才知道，**整个团队的工作量其实并没有那么大，只是存在分配不平衡而已**，如果我能把手上的一些任务拆分出去给到其他人，其实大可不必这么辛苦的。

在刚毕业的时候，我完全不需要去考虑怎么分配任务的问题，因为那时候我更多的是一个执行者，把交给我的任务优质地完成就好了。但现在，我也要开始**学会如何去承担一个 owner 的职责：把任务合理地拆解，分配给合适的人，并且关注整体进度和交付时间**。

第 2 种，需要反推团队去提高交流效率，比如规定**每次的讨论结果必须落地成文本、每次讨论前需要准备基础的材料发给大家看**等等**。**这点上，**可以先从自己做起。**我曾经也有一段时间，一旦遇到什么问题，就立马去找人聊，后来发现这样其实是很低效的。最高效的方法还是**先自己思考清楚要聊什么，自己有哪些想法和备选方案，再找相关的人讨论，**这样也节省了双方的时间和精力。

## 3. 主动承担

「主动承担」这个词听起来很官方，很像宣传标语，也是腾讯每半年考核的一个维度，但我一时也没想到什么更加口语化的说法。

什么叫主动承担呢？日常工作里，总是可以遇到很多**边界模糊**的东西，比如：

- 你提交了代码，发现跑了几次测试用例，都是时好时坏，而团队里也没什么人愿意花时间去修复不稳定的用例，多跑几次能过就行；
- 团队维护的核心服务还是跑在老爷车基础设施上，虽然公司在鼓励上云，虽然老爷车效率很低，但因为还能跑，所以就没有动力去迁移；
- 团队的项目代码缺乏基本的 lint 工具、git hook、git commit message 格式校验，有的甚至连基本的 CI 都没有；
- 经常收到各种用户的工单，问的都是同一个问题，也没有人考虑写一篇文档彻底解决疑问。

这些都属于「房间里的大象」，也就是非常显而易见，可是却一直被忽略的东西。它们可能是一些脏活、累活、难活，但对于整个团队的效率、交付质量非常重要，需要有足够的人力投入。

**这些边界模糊的东西就是需要去主动承担的点**，是除了完成团队本身托付的任务之外，还能创在额外价值的点。

作为一个从小到大性格上都比较强势的人，我经常出于“我靠我实在看不下去了”的心理，去做一些份外的事情，这些份外的事情给我带来额外负担的同时，也让我有机会去引导团队的发展。当然我也希望我的同事都是能够主动承担的人，这样我也不会这样心累了（逃）。

## **4. 学会**引导团队的发展

《乔布斯传》里提到过一句话：“**消费者并不知道自己需要什么，直到我们拿出自己的产品，他们就发现，这是我要的东西**。”

其实工作上也是如此，**即使单纯从技术的层面讲，不少人也并不知道什么是好的、正确的**。比如曾经的我，认为**以下真理是不言而喻**的：

- 写自动化测试用例不是浪费时间，而是提高效率；
- 面向对象或者函数式的代码，比面条代码好；
- 有类型检查，比没有好；
- 把服务容器化，比跑在虚拟机上好；
- 严谨的对外 API 设计，比随心所欲的好；
- 精简到两三句话就能把事情说清楚的文档，比一大坨不知所云的文字好。
- ……

后来我发现，起码就我接触到的范围内，**并不是所有人都会有足够的技术审美、追求和视野**，比如有人会质疑， 为什么 git 比 SVN 更适合团队工作流，为什么你写的这段 OOP 代码就是比他的七层 if else 好，为什么项目要写自动化测试并且接 CI，为什么我们要抛弃虚拟机转向容器引擎等等。说服这些“顽固保守派”，也是要花很多时间、口水和精力的事情。

那么**要如何引导团队呢**？刚毕业那会儿我是一个很激进的人，看不惯一切落后原始的东西，团队内的项目，一刀切上最新的技术就对了，这种做法后来发现阻力很大：

- 团队成员并不是每个人都了解这些新东西；
- 新东西往往有很多隐藏的坑，你可能就要当第一个吃螃蟹的人；
- 现成的业务已经趋于稳定了，虽然可能是个屎山，But It Works !

在了解这些阻力的来源之后，我开始学会如何「**渐进式**」地去改造现有项目，比如：

- 项目缺乏最基本的 lint？那先把 husky 加进来，任何人改动的文件，都会被自动化 lint，**而不是对整个项目跑一遍全量 lint 和格式化**（这样其它人的开发分支全部冲突了）；
- 想给老项目引入 TS 进来？那就允许 TS 和 JS 并存，这样随着项目的开发，JS 就会被慢慢改写成 TS。**而不是花一两周时间啥也不干，全量把 JS 切到 TS 上**。
- ……

渐进式迁移的好处就是，可以满足绝大部分人的利益，不容易遇到阻力，也不会给项目一次性引入太多的风险和不稳定性。当然对于新项目，我是偏向于激进的，不想给未来留下过多的历史性包袱。

## 最后

现在全民 CS 的时代，程序员确实是大势所趋，毕竟收入水平摆在那里，即使完全不爱这一行，那也不能和人民币或者美元过不去嘛。

但对我而言或许并不是那样，和《一拳超人》的琦玉老师一样，**我是一个兴趣使然的人**，一直觉得写代码是一件很酷、很 Geek 的事情，能够学到更多的知识，能够用自己的学识和能力做出、推动一些事情的发展，让世界变得稍稍不一样，这就是我的源动力，而当下的腾讯能够给我这样的舞台。

士不可以不弘毅，任重而道远。

写在入职腾讯三周年


现在市面上几乎所有的 Server 框架都是为服务器主机上运行而设计的，即使有一些框架支持底层迁移或者导出到 FaaS 上，但终究不是为 FaaS 设计的，或者说，都是「Server First」的。

我大胆地猜测未来几年一定会慢慢诞生「Serverless First」的服务端框架，这种框架把 OS、运行时、服务伸缩容、服务编排隐藏了起来，开发者很难感知到底层是如何运行的，只用在云上的 IDE 写上层逻辑就好。其实现在比较激进的 Darklang 就已经是这样干的了，国内还没有看到追随者。

所谓的 Serverless 框架到底应该是什么样


“摩擦的产生也是因为增长团队将领域和背景如此不同的一群人聚集在一起，可想而知，他们势必会有意见相左的时候，有时甚至在立场观点和工作重心上存在冲突。工程师一般只对在技术上最具挑战性的工作感兴趣，而不关心他们提出的解决方案是否会对增长产生实质性的影响。产品经理往往沉迷于产品开发与发布工作，如果市场和销售团队在最后一分钟提出产品改动要求却给不出有说服力的商业理由，他们可能会大发雷霆。用户体验设计师经常会反对为产品引入一些试验性的功能或特征，因为他们担心原本对产品满意的用户会因此感到厌烦。营销人员则可能会过于关注像网站访问量或销售线索这样的“面子指标”，而忽略了在漏斗的其他部分（比如用户留存）提升指标的必要性。”

《增长黑客》小记01


如果你关注 Node.js 社区，那么你一定记得 Node.js v12 一个非常重磅的功能就是，内核的 HTTP Parser 默认使用 [llhttp](https://github.com/nodejs/llhttp)，取代了老旧的 [http-parser](https://github.com/nodejs/http-parser)，性能提升了 156%。

但知其然也要知其所以然，llhttp 是如何做到这一点的呢？

## http-parser 的过去和现状

之前 Node.js 使用的 [http-parser](https://github.com/nodejs/http-parser) 是 Node.js 中最古老的几个依赖之一，始于 2009 年（也是 Node.js 的元年）。在那个年代，Node.js 的定位是一个后端开发平台，其目标之一就是能快速搭建异步的 HTTP Server，所以 http-parser 是最核心的模块之一，也影响了 Node.js 内部很多代码、模块的设计。它的设计上参考了 Ruby 的 [mongrel](https://rubygems.org/gems/mongrel)，也同样使用了小部分来自 Nginx 的代码，还有一部分代码是 RY 自己写的。

http-parser 其实是有很多优点的，比如它的性能足够好；兼容了很多“非标准”的 HTTP 客户端；积累了足够完善的测试用例，这些优点让它经受住了时代的考验，毕竟对于一个技术项目而言，十多年已经是一个非常久的时间了。

但是它也有缺点，随着时间的推移，无数的迭代，它的代码变得越来越僵硬（“rigid”），很难对它进行大的改动，或者做很大的优化，这也导致它难以维护，任何代码的变更都可能会引入 bug 或者安全问题。

另外，http-parser 是纯 C 实现的，而 Node.js 的受众主要是 JavaScript 开发者，这些开发者中大部分人都不是 C 语言的专家，这也给维护带来了困难。

所以，Node.js 需要一个新的 HTTP Parser，这也就是 llhttp 的来源，它起码需要以下几种特性：

1. 性能要好于 http-parser，或者至少不能更差；
2. 最好使用 JS/TS 实现，便于社区维护；
3. 对外接口尽量保持一致，便于无缝升级。

## HTTP Parser 是什么？它在做什么？

我们在这里不过多深入 HTTP 的细节，只是做一些简单的介绍。

HTTP 是一种应用层的文本协议，建立在 TCP 之上，由三个部分组成：起始行（start-line）、头部（headers）、传输体（body）。

比如下面就是一个完整的 HTTP 请求的例子：

```
POST /user/starkwang HTTP/1.1                  <--- 起始行
Host: localhost:8080                           <--- 头部开始
Connection: keep-alive
User-Agent: Mozilla/5.0 (Macintosh; ...
Content-Type: application/json; charset=utf-8  <--- 头部结束

{"text": "这里是Body!!"}                        <--- 传输体
```

当然这只是理论，实际上收发、处理一个 HTTP 请求并没有那么简单，比如对于 Node.js 的 Runtime 层面而言，它收到的来自传输层 TCP 的数据实际上是**几串离散的数据**，比如：

```
POST /user/starkw
------------我是分割线---------------
ang HTTP/1.1                  
Host: localho
------------我是分割线---------------
st:8080                           
Connection: keep-alive
User-Agent: Mozilla/5.0 (Macintosh; ...
Content-Type: appli
------------我是分割线---------------
cation/json; charset=utf-8

{"text": "这
------------我是分割线---------------
里是Body!!"}
```

**HTTP Parser 的工作之一就是把这几串数据接收并且解析完毕（如果遇到不符预期的输入则报错），并将解析结果转换成文本和 JavaScript 侧可以处理的对象**。下面是一个便于理解的例子：

```
{
    method: 'GET'
    headers: {
        'Host': 'localhost:8080',
        'Connection': 'keep-alive',
        'User-Agent': 'Mozilla/5.0 (Macintosh; ...',
        'Content-Type': 'application/json; charset=utf-8'
    },
    body: '{"text": "这里是Body!!"}'
}
```

（实际上，Node.js 里面是以 [IncomingMessage](https://nodejs.org/dist/latest-v13.x/docs/api/http.html#http_class_http_incomingmessage) 和 [ServerResponse](https://nodejs.org/dist/latest-v13.x/docs/api/http.html#http_class_http_serverresponse) 的形式表示的）

## llhttp 是怎么实现的？

如果你学过或者接触过一点编译原理的话，很容易就想到 HTTP Parser 本质上是一个**有限状态机**，我们接收并解析 start-line、headers、body 时，只是在这个状态机内部进行转换而已。

## HTTP 状态机

假设我们正在接收一个 HTTP 请求，我们收到了 HTTP 请求的第一个字符，发现这个字符是 G，那么我们接下来应该期望收到一个 start-line 的方法名 GET。

但如果第二个字符收到了 A，那么就应该立刻报错，因为没有任何 HTTP 方法是以 GA 开头，根据这个步骤，我们就得到了一个很简单的状态机：

![img](https://pic2.zhimg.com/v2-d43f85bd2c1ee071a05ad5079667d611_b.png)

顺着相同的思路，将这个状态机进一步扩展，我们就可以解析完整的 HTTP 请求了：

![视频封面](https://pic4.zhimg.com/v2-60a12f97e47b489ec2a551c738a88277.jpg)



下面是实际上的 llhttp 内部的状态机（[大图请看这里](https://indutny.github.io/jsconfeu-2019/reveal.js/images/graph.svg)）：

![img](https://pic3.zhimg.com/v2-9de3eadcbbb904a559ab01ef1edc8bee_b.png)

## 如何优雅地实现状态机

理论有了，那么我们接下来的问题就是**如何用代码优雅地实现一个有限状态机？**

比如我们可以用一个 switch 来解决：

```js
const state = 0
function excute() {
    swtich(state) {
        case 0:
            // do something...
            state = 3
        case 1:
            // do something...
            state = 0
        // ...
    }
}

while(true) {
    excute()
}
```

可是 switch 的问题在于：

1. 大型的状态机会存在成百上千种状态，把这么多状态放在一个巨大的 switch 中，是很反人类的事情；
2. 对于解析文本协议而言，有很多重复的动作，比如“连续匹配 POST 这四个字符”，这种“连续匹配”的行为是可以进一步抽象的，而不是写成多个状态；

## 使用 DSL 描述状态机

为了解决上述问题，llhttp 使用了一种基于 TypeScript 的 DSL（领域特定语言） [llparse](https://github.com/nodejs/llparse)，用于描述有限状态机。

llparse 支持将描述状态机的 TypeScript 编译为 LLVM Bitcode（这也是为啥叫 llparse 的原因）、或者 C 语言、或者 JavaScript。它起码有以下几种优势：

1. 不需要手写大量重复的状态机转换的代码
2. 可以输出到多种语言，其中 llhttp 使用的是 C 语言
3. 可以在编译期间对状态机进行静态分析和优化，合并冗余的状态

## llparse 快速入门

现在关于 llparse 的文档和文章几乎没有，llparse 本身也只有 [Fedor Indutny](https://github.com/indutny) 一个维护者，所以想要理解 llparse 的 API 是有一定难度的。

## 简单介绍

llparse 使用 TypeScript 描述一个专用于匹配文本的状态机，所以它的一切 API 都是为描述一个这样的状态机而设计的。

在 llparse 中，所有状态都是一个节点（node）：

```js
// 创建一个状态 foo
const foo = p.node('foo')
```

我们可以通过各种 API 来描述节点之间的转换关系，或者各种状态机的动作，这些 API 包括但不仅限于：

- match
- otherwise
- peek
- skipTo
- select
- invoke
- code
- span

下面分别介绍这些 API。

### match 与 otherwise

.match() 表示在当前状态时，尝试匹配一串连续输入。

下面这段代码尝试连续匹配 'hello'，如果匹配成功，那么跳转到下一个节点 nextNode；否则调用 .otherwise() 跳转到 onMismatch：

```js
const foo = p.node('foo')
foo.match('hello', nextNode).otherwise(onMismatch)
```

### peek 与 skipTo

.peek() 表示提前查看下一个字符（ peek 有“偷窥”的意思），但是**不消费它**。

下面的代码表示，当下一个字符是 '\n' 的时候，跳转到 nextNode，否则使用 .skipTo() 消费一个字符，跳回到 foo 重新循环。

```js
foo.peek('\n', nextNode).skipTo(foo)
```

注意，**.skipTo()** **和** **.otherwise()** **的区别在于， 前者会消费一个字符，而后者不会**。

所以如果我们使用 .otherwise() 替换上面的 .skipTo()，就会收到一个错误，告诉我们检测到了死循环：

```js
foo.peek('\n', nextNode).otherwise(foo)
//=> Error: Detected loop in "foo" through chain "foo"
```

### select

.select() 用于匹配一串文本，并且把匹配到的文本映射到某个值上，然后把这个值传入下一个状态。

```js
foo.select({
    'GET': 0,
    'POST': 1
}, next)
```

比如，在接收 HTTP 请求的时候，根据规范，开头的前几个字符必然是 HTTP 方法名，那么我们可以这样接收：

```js
const method = p.node('method')
method
  .select({
    'HEAD': 0, 'GET': 1, 'POST': 2, 'PUT': 3,
    'DELETE': 4, 'OPTIONS': 5, 'CONNECT': 6,
    'TRACE': 7, 'PATCH': 8
  }, onMethod)
  .otherwise(p.error(5, 'Expected method'))
```

### invoke 与 code

任何有意义的状态机最终肯定是要对外部产生输出的，比如调用外部函数，或者存储一些状态到外部的属性上面，.invoke() 和 .code 就是为此而设计的。

.invoke() 调用一个外部函数，并且根据外部函数的返回值，映射到不同的下个状态，如果没有映射，那么跳入错误状态中。

.code.match() 返回一个外部函数的引用。

```js
const onMatch = p.invoke(
    p.code.match("bar"),
    {
        1: nextNode1,
        2: nextNode2
    },
    p.error(1, "bar error")
)
```

我们这里调用了外部函数 bar，并且根据返回值确定下一个状态 nextNode1 或 nextNode2，如果返回值是预期外的，那么跳入错误状态。

### span

.span() 表示在一段时间内，为输入的每个字符产生一次回调。

```js
const callback = p.code.span('onByte')
const onByte = p.span(callback)

node.match('start', onByte.start(nextNode))

nextNode.match('end', onByte.end(nextNextNode))
```

上面我们尝试匹配 'start'，如果匹配成功，那么跳入 nextNode，并且开始为每个匹配到的字符触发 onByte() 回调，直到匹配完毕 'end'，我们结束触发回调，并且跳入 nextNextNode。

## 使用 llparse 构建简单的 Parser

单纯地讲 API 是很枯燥的，我们来实战试一试，我们尝试构建一个匹配 'hello' 的 Parser。

首先我们创建一个 start 状态节点，代表起始状态：

```js
import { LLParse } from "llparse"
const p = new LLParse("myfsm")

const start = p.node('start')
```

我们可以尝试使用 .match() 连续匹配一串输入，如果匹配成功，那么跳转到下一个状态节点 onMatch；否则跳转到 onMismatch：

```js
start
    .match('hello', onMatch)
    .otherwise(onMismatch)
```

然后 onMatch 中，我们使用 .invoke() 产生一个外部调用，调用的是注入的外部方法 onMatch，如果它返回 0，那么就跳转回到 start 状态，否则报错

```js
const onMatch = p.invoke(
    p.code.match("onMatch"),
    {
        0: start
    },
    p.error(1, "onMatch error")
)
```

于是我们就得到了这样一个简单的状态机：

![img](https://pic4.zhimg.com/v2-27aab74d15b646d0c3f9cedb5b5fc9a3_b.png)

下面是完整的代码：

```js
import { LLParse } from "llparse"
import { writeFileSync } from "fs"

const p = new LLParse("myfsm")

// 创建状态节点 start
const start = p.node("start")

// 创建调用节点 onMatch
const onMatch = p.invoke(
    p.code.match("onMatch"),
    {
        0: start
    },
    p.error(1, "onMatch error")
)

// start 状态匹配到 hello 之后，进入 onMatch节点
// 否则输出 expect "hello"
start.match("hello", onMatch).otherwise(p.error(1, 'expect "hello"'))

// 编译状态机
// 状态机从 start 开始
const artifacts = p.build(start)

// 输出编译结果
writeFileSync("./output.js", artifacts.js)
writeFileSync("./output.c", artifacts.c)
```

运行上述代码，我们就得到了状态机的编译结果 output.js。

然后我们可以试用一下编译出来的状态机代码：

```js
import makeParser from './output'

// 传入外部函数，创建 Parser
const Parser = makeParser({
    onMatch: (...args) => {
        console.log('match!')
        return 0
    }
})

const parser = new Parser()
parser.execute(Buffer.from('hel'))
//=> 0，代表没有报错
parser.execute(Buffer.from('lo'))
//=> 打印 'match!'，同样返回 0
```

注意，我们这里即使把 'hello' 分为两段输入状态机，状态机依然可以成功匹配。

但如果我们输入了预期外的字符串，那么就会让状态机进入错误状态：

```js
const parser = new Parser()
parser.execute(Buffer.from('starkwang'))
//=> 返回 1，代表错误状态
```

## llhttp 是如何使用 llparse 的？

解析 HTTP 协议，和我们上面构建的这个简单的 Parser 其实原理上是一样的（只是前者复杂得多而已），比如下面就是一段解析 HTTP 起始行（start-line）的状态机代码（[来自 llparse 的 README](https://github.com/nodejs/llparse#usage)）：

```js
import { LLParse } from 'llparse';

const p = new LLParse('http_parser');

const method = p.node('method');
const beforeUrl = p.node('before_url');
const urlSpan = p.span(p.code.span('on_url'));
const url = p.node('url');
const http = p.node('http');

// Add custom uint8_t property to the state
p.property('i8', 'method');

// Store method inside a custom property
const onMethod = p.invoke(p.code.store('method'), beforeUrl);

// Invoke custom C function
const complete = p.invoke(p.code.match('on_complete'), {
  // Restart
  0: method
}, p.error(4, '`on_complete` error'));

method
  .select({
    'HEAD': 0, 'GET': 1, 'POST': 2, 'PUT': 3,
    'DELETE': 4, 'OPTIONS': 5, 'CONNECT': 6,
    'TRACE': 7, 'PATCH': 8
  }, onMethod)
  .otherwise(p.error(5, 'Expected method'));

beforeUrl
  .match(' ', beforeUrl)
  .otherwise(urlSpan.start(url));

url
  .peek(' ', urlSpan.end(http))
  .skipTo(url);

http
  .match(' HTTP/1.1\r\n\r\n', complete)
  .otherwise(p.error(6, 'Expected HTTP/1.1 and two newlines'));

const artifacts = p.build(method);
console.log('----- BITCODE -----');
console.log(artifacts.bitcode);  // buffer
console.log('----- BITCODE END -----');
console.log('----- HEADER -----');
console.log(artifacts.header);
console.log('----- HEADER END -----');
```

当然你也可以直接去读 llhttp 的核心状态机代码：[llhttp/http.ts](https://github.com/nodejs/llhttp/blob/a6ca348d00bfb3d399f5df5e43e22d521b6c142f/src/llhttp/http.ts)

## 为什么 llhttp 会比 http-parser 更快？

1. llparse 在编译 DSL 时有静态分析的过程，这期间会做一些状态机的优化，例如状态合并。比如匹配 ‘POST’、‘PUT’、‘PATCH’ 的时候，就会合并第一个 ‘P’ 字符的状态，而不是生成三个独立的中间态；
2. http-parser 为了 C 代码的可读性和 DRY，存在很多抽象，这些抽象其实是一种 trade-off，是存在性能损失的。而 llparse 完全不需要考虑编译结果的可读性，所以甚至可以在编译出的 C 代码里大量使用 goto 替代条件判断，这里也间接提升了性能。

## 总结

1. llhttp 使用有限状态机解析 HTTP 协议，保证性能的同时也提升了代码的可维护性；
2. 为了使状态机的代码简洁明了，llparse 被设计了出来，这是一门基于 TypeScript 的用于描述解析文本的状态机 DSL；
3. llparse 提供了一系列 API 对状态机的行为进行抽象，并且可以把状态机编译到 LLVM Bitcode、C、JavaScript。

## 参考资料

1. [llhttp - new HTTP 1.1 parser for Node.js by Fedor Indutny | JSConf EU 2019](https://youtu.be/x3k_5Mi66sY)
2. https://indutny.github.io/jsconfeu-2019/reveal.js/index.html
3. https://github.com/nodejs/http-parser
4. https://github.com/nodejs/llhttp
5. https://github.com/nodejs/llparse

Starkwang.log