一个 32 岁「老」码农的复盘：确立方向

2019 年 7 月中旬，也就是去年夏天，我入职了一家低代码开发平台领域的公司。与之前工作过的公司相比，这次有点特殊，因为前端负责人是我关注多年的圈儿内大佬（为了避免蹭名气的嫌疑等，下文一直用这个称呼）。

低代码开发平台领域是国内近几年比较火的一个方向，尤其是帮助企业数字化转型的，它们在宣传时的用语都比较接近——aPaaS、中台架构（业务中台、数据中台等）、低代码/零代码搭建应用。

工作成果

上班第一天的时间被各种杂事占用了大半，赶紧用剩下的时间尽快熟悉下项目。看了一段时间之后，觉得有点头大：一是有些遗留的文件，看了段时间才发现用不上；二是在跟着函数/方法调用追踪时，嗅到了一丝「复杂」的气息，这才是主要的。

第二天开始就要正式进入工作状态了。先说下前端团队的主要流程、规定：每天早上有站会，尽量用精简的语言说下自己前一天做的事情及进展和当天的工作安排，如果遇到困难及需要协助的要尽早提出；每开发一个 feature 或修复 bug 需要在 GitLab 上提 MR，待另外两个人 review 通过后才可以合并；复杂点的功能（一般是工作量两天以上）需要写方案，评审通过后才能进行开发。

容器组件开发

晨会后，大佬给了我第一个任务——参考 ActionScript 3 的一个包去写几个容器组件，记得有：Box、HBox、VBox、Grid、Tile、ViewStack、Tabs、Card、Toolbar 和 Form。它们有的不仅仅是一个组件，在真正实现时会根据需要添加或分解成两、三个；其中有的在 Ant Design 和 Element 中有，在设计与实现时可以作为参考。

前端视图库用的是 Vue，当时项目中的 UI 组件库已经（同时）在用 Vuetify 和 Element 了，为什么还要自研它们中有了的组件？唯一的原因就是自研的更可控：有可能会与应用的一些底层机制进行结合；若是同一组件要支持多端，有更多可搞的空间。

在做之前，我先结合 ActionScript 3 的那个包、Ant Design 和 Element 的官方文档整理出一份包含了各个组件的特征、疑问等描述的文档，让大佬过目一遍，确认没啥问题了我才开工。

因为是写 UI 组件，不需要与业务及应用的机制相结合，相对来说简单很多。总共写了十几个组件，再加上规整了下相关的目录结构，大概用了两、三天时间。紧接着又做了一个 IconPicker 组件。从整体规划上来看，我所写的这些组件基本都是为了自定义视图、可视化编辑作准备的。其他组件的优化和补充，是随着之后一些需求一并进行的。

渲染流程改造

在第二周的工作中，开始沿着我所嗅到的「复杂」气息去逐渐深入到整个前端应用的内核中，一窥它的运作机制。

在有所了解之后就一个感受——脑壳儿疼……不是因为写得不好，而是因为它太复杂了！这个应用的复杂程度不是我以往参与过的能相比的，差了几个级别！它所暴露出来的概念中蕴含的信息量，已经超出了我当时的认知水平！

可以想象一下，自己的认知水平就是头顶的那块天花板，而那些概念中蕴含的信息量正好在天花板之上，想要去理解并吸收掉，就必须得突破那块天花板。在那之前只能脑袋一直在天花板上来回摩擦，就看在蹭破之前头有没有秃噜皮，几层皮，还有没有头发，蹭破的到底是头皮还是天花板。

那段时间那个难受劲儿啊，脑袋瓜子嗡嗡的，就像真的在头撞墙一样。其实这也是对心理素质的考验，不是压力，而是困难。是知难而退？还是硬着头皮迎难而上？我其实挺喜欢这种感觉的，不是因为我是自虐狂，而是觉得这是正在走出舒适区的过程，挺下来了就会成长，看到另外一片天空。

这里在做的低代码开发平台包括了前台和中后台。前台是官网、商城页面的装修，中后台就是管理系统的定制。前端架构的重心和复杂度主要是在中后台，当时的前端架构基本只有逻辑层和表现层这两层，没有特别抽象出数据层。一段时间内，我主要负责表现层的设计与开发。

在这里，表现层内又划分了三层：描述层、包装层和渲染层。它们也可分别叫做「抽象层」、「适配层」和「运行层」，只不过这几个是更为泛化的叫法。描述层是作为配置的模板，是元数据；渲染层是实际进行渲染的 UI 组件；包装层是将模板解析后的节点树转为组件树的纽带。

我入职后的首个阶段目标就是扫平可视化编辑的障碍。上文说的我做的那些 UI 组件就是障碍之一，另一个同时也是比较大的障碍是从模板到最终呈现的渲染流程。在我刚接手时，表现层并不像上面所说的那样明显地划分出了三层，那是我接连两次改造所形成的。

描述层，即 XML-like 的模板（下文简称「模板」），是一直有的，但当时是直接当作 Vue 的模板来使用的，不过没有用插值、指令等与逻辑有关的特性。这么做，元素、属性的命名等受 Vue 的限制是一方面，另一方面是每个元素的配置等信息的收集不好弄。

<view widget="table">
  <config checkable="true" fixed-header="false" />
  ...
  <field widget="input" name="name">
    <config column-width="100" />
  </field>
</view>

如这段模板所示，如果直接把它当作 Vue 模板使用，命名等方面有没有警告或报不报错不说，在渲染 <view> 所对应的组件时，它并没有直接拥有通过 <config> 声明的配置信息，得在组件的 render() 中遍历子 VNode 来收集。并且，在 <field> 所对应的组件中也是如此，如果还有其他元素……

将模板相关的信息收集与 Vue 的渲染流程耦合在一起，可维护性变差是显而易见的，还有三个比较关键的问题：在可视化编辑时，配置等信息改变了，如何很好地反馈到最终呈现的视觉效果上；如何在开始渲染某个组件之前，对它的配置等信息进行「魔改」以做些额外的事情，这算是可扩展性问题；模板变得不是视图库无关的。

鉴于上述原因，我开始了第一次的改造：注册一些与模板元素相对应的专门用来收集信息的 Vue 组件，在拿到模板后首先通过它们进行「预处理」；收集信息并拼装成 JS 对象后，将「预处理」用的组件树销毁并进入真正的渲染流程，这时每个组件都能直接拿到自己的配置等信息了。

相较之下，这次只是个「小」改造，并没有完全解决那三个关键问题，于是就有了紧接着的第二次改造。在第二次改造中，将模板相关的处理与 Vue 的渲染流程彻底分离开了——

模板如果不去解析，它就只是一段普通的文本，没有任何作用。

要对模板进行解析，得有一套对应模板上标签的标签集，还需有能将纯文本的模板借助标签集转换成 JS 对象的解析器。

标签集中的每个标签，也可以称为「元素」。考虑到扩展性，需要有元素注册的机制，这有助于元素属性等的规范和管理。

在注册元素时，需要指定一些关键信息，如：元素名、标签名、属性描述符、行为。「属性描述符」主要是用来声明该元素所支持的属性及其值的类型；「行为」则用来告知该元素在解析后是作为父节点的子节点还是属性存在。

所有作为子节点存在的元素，基本都对应一个具体的部件。从表意上来说，这些元素分为两类：一类是较为抽象的，另一类是较为具象的。较为抽象的元素只有一个，它仅单纯地表达是「部件」这个含义，并没有更具体地体现出是干嘛的；其他的元素都是具象的，像 <view>、<field> 等，从命名就知道是用于哪方面的。

所谓「节点」，就是将模板中的元素编译解析后所转换成的 JS 对象。整个模板会解析成一个树状结构的 JS 对象，也就是「节点树」。每个节点可以有一些方法，用来新增子节点、删除自身、获取或修改自身信息等。

如上所述，为了彻底解决问题，我设计并实现了一套模板元素的注册与查找机制，模板解析的工作就交给了魔改后的 Vue 2.6 编译器。最终生成的「节点树」就是页面中的特定区域要渲染哪些「部件」以及它们的配置的描述信息——这听起来有点像「虚拟 DOM」。

经过第二次改造，不仅解决了那三个关键问题，并且表现层内的三层划分变得清晰了——

描述层完全是视图库无关的，因为模板中所使用的元素及解析器是独立的，产物是描述要渲染的内容的 JS 对象。由于解析器是相对独立的（即使是用 Vue 2.6 编译器魔改的，也可以看作是与 Vue 无关的），线上环境所使用的 Vue 版本可以是不带编译器的，这样会减小一些文件体积。至于模板解析器的体积，可以考虑通过将解析阶段从运行时中移除进而优化掉。

包装层主要包含了将节点树转换为组件树的「包装器」和转换程序，以及将基础组件与底层机制封装到一起的「部件」。因为最终呈现完全是根据节点树来的，这就可以在节点树转换为组件树的过程中加入一些扩展点来加以影响，如：过滤一些子节点，改变节点树的结构等。

渲染层就基本是具体的运行时环境及基于它封装的基础组件。这没什么好说的，无须多言。

至此，影响实施可视化编辑的障碍物差不多都已经排除了，就差开发个可视化编辑器来拖拖拽拽了。

可视化编辑器

如上文所说，页面中特定区域的最终呈现是由节点树来决定的，运行时中始终会有节点树的存在。在正常运行时，节点树生成后就不会有啥变化了；而在可视化编辑时，它的结构和节点属性等则会不断随着用户操作而改变。由此可以看出，可视化编辑是由节点操作和用户操作两大部分构成，处理它们的分别是节点编辑器和可视化编辑器。

正常运行状态下的节点树中节点不像 DOM 节点那样拥有自己的方法，只能在可视化编辑状态时通过注入的节点编辑器实例进行操作。这个「节点编辑器」实际上就是一个实现了简单的事件机制的节点树结构与节点属性操作的 API 集合：可以在节点树中增、删、移动或复制一个节点，也可以修改节点的 props、attrs、config 等信息；节点树结构与节点属性的变更都会触发相应的事件。

一般来说，可视化编辑至少需要有三个功能区：工作区，也可叫「画布」，是用户操作的主功能区，采用所见即所得的形式；物料集合，罗列出可以拖动添加到工作区进行操作的物料；属性面板，用来给工作区中选中区块（不只是物料）的一些属性进行配置。

由于属性面板相对难抽象，我所开发的可视化编辑器只包含了工作区和物料集合部分，并且只是比较通用的核心逻辑。因为在编辑不同领域的模板（如视图模板、打印模板、问卷模板等）时所要处理的细节有所差别，需要针对具体的领域去把核心部分给包装一下。

可视化编辑器中与物料集合相关的部分主要是与工作区通信及节点树操作等相对底层的逻辑，每个物料条目长啥样，由外部定义的组件决定；工作区部分主要有可编辑区块容器及根节点包装器。

可编辑区块容器是工作区中用户与节点树之间的重要媒介，也就是说，用户操作通过可编辑区块容器来反馈到节点树上。可编辑区块容器有两种，一种是用于使用绝对定位的自由布局的，它可以通过拖拽调整大小；另一种是用于像栅格布局、分栏布局等固定布局中的。根据需要，可编辑区块容器可以有删除、复制、上/下移等操作。

根节点包装器的作用是，以被编辑的节点树的根节点为基础，在渲染时对其每个可编辑的子、孙节点用可编辑区块容器进行包装，根据模板所属的领域选择可编辑区块容器的类型。当时，根节点包装器在实现上有个很大的缺点，就是将容易变化的包装逻辑耦合进来了，理应外置。

主题扩展机制

随着可视化编辑器开发的完结，首个阶段目标也算是彻底完成了！下个阶段目标就是主题，这是面向客户的表现层可扩展性方面的能力之一。主题相关的事情，难度嘛基本没有，竟是些繁杂琐碎的事儿，相对来说是个「体力活儿」……

相信很多人看到「主题」二字，第一想到的就是字体、颜色等——这没错，但也不完全对，因为在这里的低代码开发平台体系中，那只是其中的一部分，可以叫「风格」，也可以叫「皮肤」。在这个体系下的主题，除了风格，还有行为、布局、组件、部件等，它们以「主题包」的形式打包存在，只要其中有一样变了，就是另外一个主题。

主题的「行为」部分主要作用于部件，包括交互、布局——

看以下几种需求：

• 布尔型字段在某个应用中想用 Switch 组件，在其他应用中想用 Checkbox、Radio 或 Select 等组件；
• 表格在页面主体中时想显示列偏好设置、单元格文本密度调节，但在对话框中时不想要这些功能。

用来解决这类需求的配置，就是「行为」。

上面是「交互」的例子，下面则是「布局」的：

对于组件的外部来说，组件内部就是个黑盒子，其自身结构的组成部分有的可以被上文所说的视图结构所控制，有的则无能为力：

上图是一个比较复杂的搜索组件，虽然外观和布局看起来有所不同，但「它们」确实是同一个组件。外观不同的解决方案上面已经大体说明，这类视图结构无法控制的布局问题，需要枚举场景后在组件内进行支持，然后作为「主题」的一部分存在。

主题中的「布局」是页面布局，更确切地说，是视图宿主的布局。「视图」是表格、表单之类用来展示或收集数据的，这应该没什么疑问，「宿主」就是视图的容器——最常见的就是页面，这里的视图叫「主视图」；其次是对话框，这里的叫「弹出视图」；最后就是字段，在这的叫「嵌入视图」。

宿主的布局也是上文中所说的模板，主要通过 <container>、<header>、<footer>、<content> 和 <sidebar> 这五个元素的排列组合来拼装出不同的布局结构：

<!-- 只有页头和主体 -->
<container>
  <header />
  <content />
</container>

<!-- 页头、侧边栏和主体 -->
<container>
  <header />
  <container>
    <sidebar />
    <content />
  </container>
</container>

<!-- 页头、主体和页尾 -->
<container>
  <header />
  <content />
  <footer />
</container>

<!-- 页头、侧边栏、主体和页尾 -->
<container>
  <header />
  <container>
    <sidebar />
    <content />
  </container>
  <footer />
</container>

<!-- 侧边栏、页头和主体 -->
<container>
  <sidebar />
  <container>
    <header />
    <content />
  </container>
</container>

<!-- 侧边栏、页头、主体和页尾 -->
<container>
  <sidebar />
  <container>
    <header />
    <content />
    <footer />
  </container>
</container>

「组件」和「部件」就没什么可说的了，就是一个完整的主题包内，必须包含提供基本交互的基础组件和将基础组件与底层机制封装到一起的标准部件各一套。

看到这里，也许会觉得——主题也没有一开始说的那么繁琐啊，哪里是体力活儿了？这是因为，关于风格我并没展开说什么……我就举个例子体会下吧——

要让一个按钮组件的风格可以被定制，需要将 6 个主题色（默认、主要、信息、成功、警告、危险）、4 个状态（悬停、聚焦、激活、禁用）与字体、文本、背景和边框等属性相互进行组合，会产生多少变量可以自己算下……这还是往少说了，尺寸、阴影什么的还没算进去呢。光一个按钮组件就这么多了，还有那么多其他组件呢……

风格与行为都是以 JSON 形式的 JS 对象来配置，在页面刚初始化时会把风格部分的配置生成 CSS 自定义属性；部件的实例创建后会获取自己的行为配置并与默认的配置进行合并后渲染。

工作体验

以上都是些我在这家公司主要负责的地方及工作成果，下面就来说说在这里的一些往事——

为什么会选择这家公司？一方面是在买/卖好车时期的后半段，我的主要工作内容是基建与提效工具，并且从那时起我就倾向于走基建与提效工具这个方向，这家公司的业务方向与我较为贴合；另一方面是在得知大佬在这里工作之后，我就毫不犹豫地决定要来了，在对一家公司、一个方向不甚了解的时候，跟着绝对信任的人总没错。

为什么我会绝对信任这位大佬？在之前，现实中（即线下）接触过且有所交流的同行，即使比我强，我也会觉得只要自己努努力，也不会差到哪儿去；然而大佬就不一样了，经过多年的观察，他不仅在技术上有深度和广度，在企业软件这个方向上的思考也很多，有自己的一套很完整的方法论，面对他就像抬头望天——令我「颈」（景）仰！

流水的兵

入职的第一天，基本跟以往刚去一家公司一样，填各种资料，安装电脑应用，搭建开发环境。发送附有「新人介绍」表格的邮件时，「师兄」那栏填的是大佬的名字。与以往不同的是，HR 会给拍一个一分内介绍自己为什么选择了这家公司的视频。

这时公司总共 20 人左右，这个数字保持了一段时间的动态平衡。算上我总共 5 个前端，除了大佬和我之外，另外三个分别是：之前在端点的小明；做过淘宝店铺装修的阿杜；毕业一两年的阿栋。

在我开发容器组件的同时，小明和阿杜在做搜索相关的功能，阿栋在做字段部件的国际化与格式化相关改造。因为负责阿杜写的代码 review 的没有我，所以不太清楚他的代码写得咋样；但阿栋的代码有很多问题，并且竟是些很基础的问题，毫不夸张地说，我基本每行代码都得评论一下……

代码 review 是件耗时耗力的事。如果一个人的代码基础能力很差，写出来的代码就会漏洞百出，再加上不严谨、不精益求精的态度，在 review 时就会来回反复——发现问题进行评论；写代码的人改完提交；提交的代码还是有问题，又评论……这样真的很折磨人，对协作、对团队危害都挺大。

有次我实在没忍住，吐槽了阿栋一句：「提 MR 前能好好检查一下代码吗？！」只见他嘻嘻一笑。其实也许不应该说他不严谨、不精益求精，没准他态度上没问题，单纯是能力问题——无法要求一个人在做事时去用他所不知道的知识，不能奢望让一个人去做超出他能力范围的事情——他不适合这个团队。

在我入职不到一个月的时间里，先后又来了两个前端。先来的是在滴滴工作过，从北京过来的阿达；后来的是成为我「师弟」的哈哈。

虽然哈哈是我的师弟，但他很省心，几乎不用带，顶多就是刚开始时分配一下任务与适当地解答一下疑问。他自驱力很强，其他方面的能力也不错，遇到任何问题都是先尽可能尝试自己去解决——就像我一样。所以，在工作方面我心里对他有很高的评价。

在我将实施可视化编辑的障碍扫清之后，就要开发低代码开发平台上的相关功能了。这个功能是我负责，要跟哈哈和阿杜一起完成。这是第一次跟阿杜打配合，虽然之前没看过他的代码写得咋样，但从平时工作中他们的谈话来看，我有些担心。

在进入开发之前，我把哈哈和阿杜叫到会议室去分配任务并排期。本来我已经根据每个人的情况预先想好了谁做什么，就打算直接安排下去，然后他们报个合理的工时就好了。然而，在给阿杜分配任务时受阻，有的任务他说做不了，因为不理解要做的内容是什么。

由于在分配之前我都会大概说下那个任务是什么，所以我不理解阿杜不理解什么，就问他：「你哪块儿不理解？我给你讲。」在我问了以后，他一脸无法形容的表情，几秒钟不说话，我和哈哈都看着他，彷佛时间停住，凝结的空气中充满了尴尬的气息……急躁的我不自觉地加重了语气又问了一遍，他终于说了：「都不理解。」

看来我的担心不是多余。如果只是某几个点不理解，还可能通过讲解能让阿杜明白，但他是对整个前端框架的运行机制一点不懂，那就没啥办法了。最终让他把自己能做的任务给领了，剩下原本要安排给他的我和哈哈分掉了。

在低代码开发平台的可视化编辑相关功能开发完成了的一段时间之后，可能是阿杜觉得自己的能力实在是无法跟上这个团队，他主动离职了。我相信他在作出这个决定之前有去努力过，而不是随随便便就放弃了。这里的前端框架的运行机制理解起来有难度是客观事实，每个新入职的前端都要至少花费一个月以上的时间去理解。

之后又陆陆续续来了四个前端，他们基本都没多久就又走了。其中一个好像来的第二天还是第三天就走了，一个没到一周就走了，还有个是半个月左右，只有阿华留下了。

那几个没留下的，为什么走得那么快？有个事儿我一直没说，那就是这里的工作时间是早 9 点到晚 9 点，每周 6 天——没错，就是「996」！并且，虽说是到晚 9 点，但基本都是到 10 点或者更晚才下班。我觉得他们很可能是因为这个而离开的。那么，难道在入职前他们不知道这里的工作时间吗？那我就不得而知了。

我不会去批判他们什么，不觉得他们的做法有什么大问题，如果是站在他们的立场的话，反而支持他们的决定。那么我们这些留下来的人是因为什么理由？别人我不清楚，我想阿达和哈哈应该跟我差不多，他俩跟我一样选择来这家公司主要是因为大佬，可以说我们是大佬的追随者，只要大佬在，没有特殊原因的话我们就会在。

接下来的几个月中前端团队的人员比较稳定，直到年后。在 12 月阿松加入后，前端团队总共 7 个人——大佬、小明、我、阿达、哈哈、阿华和阿松。

同舟共济

大佬在各种场合多次强调，团队中的每个人都应该是自驱动、自管理的——我十分认同这点！在我的理解中，「自驱动」代表着一个人知道自己想做什么，知道自己在做什么，并且会尽可能靠自己想方设法地达成目标；而「自管理」则代表了对自己的要求，对自己的约束——这是在成长型团队，尤其是初创团队中所必不可少的特质。

在日常的工作中，我除了正常做自己的事情之外，也会通过别人的谈话、日报/周报等途径去观察他们，大佬自不必说，前端团队其余人中完全符合「自驱动」和「自管理」的只有我和哈哈二人。

说来也巧，我和哈哈都是因为大佬而选择这家公司；我是大佬的师弟，哈哈是我的师弟的同时也是我很认可的人；我和哈哈在熟悉工作和融入团队的方式与过程上有些相似，并且在其他方面我们三人也有一些相似点——让我觉得这是冥冥之中被安排好的……

从工作内容上来看，前端团队可以再细分为两个小团体，借用建筑行业的用词的话，就是「设计团队」和「施工队伍」——大佬、我和哈哈是「设计团队」，主要负责前端架构设计以及开发与完善基于此的前端框架；其他人是「施工队伍」，小明就是包工头，去用自研的前端框架开发具体功能。

后来，这种划分方式有了官方说法，虽然实际工作内容有所差别——「平台前端」与「项目前端」。

我们三人分工比较明确：大佬主要负责业务数据及相关的元数据处理逻辑；哈哈主要做逻辑层其余部分、资源管理及应用构建相关的；我则负责表现层。我们并没有很特意地说谁谁负责哪块儿，而是渐渐形成的默契。

在那段跟大佬一起工作的时间里，能感受到我们仨的目标是一致的——想把前端框架和平台做得更好。我感觉，当其他人与自己有共同目标且一门心思想要去做好时，会有一种莫名其妙的吸引力，让彼此走得更近，进而产生并增加信任。

大佬是团队的风向标，是这艘船的船长。就像《ONE PIECE》中的草帽海贼团，人虽少，但很强。船员们都是因为路飞且目标都与「ONE PIECE」有关才上了船，各自本身就有些本事，再加上相互之间的信任与团结，就变得更加强大了！大佬就是路飞。

在那期间，每天做事都心无旁骛，很容易进入心流状态。「996」怎么了？我是在做自己想做的事情，就算不在公司做，我也是在家里做，只不过换了个地方而已——就像在买/卖好车时每天下班后都在住处「加班」一样。

那时我们三人每天一起吃饭，有时也会有别人。在来回的路上，在吃饭时，除了与工作相关的事情，还会聊些游戏、奇闻趣事等。不过，很多时候我是当听众，然后时不时地插句嘴，提个问题。

记得有天中午，我们吃好饭后从瑞幸买了咖啡出来，在回公司的路上，忘了我当时是由什么想到的，就问了大佬一个问题：「技术上能达到你这个级别，同时对企业软件这方面有如此见解的人，在杭州能有几个？」他的回答和我想的一样——「应该没几个。」

其实我觉得，不仅在杭州没几个，就算放眼国内应该也没几个。如果有那么一个搜索人才的搜索引擎，查找同时满足「以前端为主」、「技术深度和广度足够」、「对企业软件领域很有见解」、「在杭州」、「跟公司创始人认识」这几点的人，就算结果为「0」也再正常不过了。于是我脱口而出：「大佬，有你是公司的幸运！」

就如上文所说，因为大佬的技术深度和广度以及他对企业软件领域的见解，使他成为团队绝对的风向标，并且对公司来说也很有影响力。可以试想一下，如果没有大佬的话，这家公司的前端团队会是什么样？我认为，不会好到哪儿去——

没有一个绝对中心存在的话，团队凝聚力会差很多；由于没什么人能跟后端、产品甚至老板去 PK，前端将没什么话语权，沦为砧板上的鱼肉，就像大部分其他公司中的前端一样成为「工具人」；团队中能力较强的人容易陷入自说自话，听不进去别人的意见，并且别人也基本给不了什么有效意见。还会有很多其他问题，这里点到为止。

行尸走肉

年底了，大家都回家过年了，可谁也没想到，疫情来了。来的，不仅是重创人类文明的「新冠」，还有要摧毁前端团队精神核心的「改变」。

因为疫情，全国各地封城，年后公司不能复工，很多行业和企业受到了严重打击。而我们这种不受时间、地点限制的工作，只要有电有网就能正常办公。为了减小业务受到的影响，部分人过完春节就开始工作了，我是其中一个。就从这时起，我们平台前端的人做的事不是为了平台，而是为了那些具体的项目——船开始偏航。

一直以来，我很向往远程办公的工作方式，认为这是一种很高效的工作方式。然而，现实狠狠地打了我的脸——在那一个月左右的日子里，工作与生活的界限模糊到不行，就连晚上九、十点都还要语音会议，我已经分不清什么时候该是生活了……

我知道这一切不是远程办公的错，都是时臣的错！啊不，都是不懂高效协作的人的错！无论工具、手段再怎么提高效率，只要是跟低效的人协作，就永远不可能高效起来！我参与的那个项目，是跟其他几个公司的人一起合作的，在进行需求评审时，居然要花两天时间开视频会议！

3 月初，公司刚复工，正当大家为即将到一个更大、更好的办公场地而有所期待时，得到了一个可以说是对于前端团队来说震感十分强烈的消息——大佬离职了！！！震惊之余，终于明白了为什么我会觉得在那之前的一段时间里大佬的状态不太对劲。

大佬的离开，与项目前端比起来对平台前端的影响要大得多！毕竟无论有没有大佬，项目该做还是做，他们的工作内容并没太大差异。但对平台前端来说，这是不是意味着公司的发展方向与大佬的目标不一致了？同时也代表，与我的目标不一致了？也许在远程办公开始参与到具体项目中时让我产生的浑身不适感就已经在暗示些什么……

得知消息后，我的心情很宕，一时很焦虑，同时也迷茫——

焦虑的是，之前是因为有大佬在抵挡来自于后端、产品甚至老板的压力，在他的保护下我和哈哈才能那么专注、愉快地去做向目标更进一步的事情。之后谁能去抵挡？谁抵挡得住？另外，前端框架原本由大佬负责的部分要分摊到我和哈哈身上了，虽然之前在代码 review 和日常交流时有所了解，但突然要接手还是需要有段时间去理解并过渡。

迷茫的是，灵魂人物没了，团队将变成行尸走肉；风向标没了，这艘船该驶向何方？大佬这样的人物是稀缺的，公司内没人能够顶替。难道我在上文中关于「如果没有大佬」的假设要成真了吗？平台前端、前端团队将何去何从？

不管以后怎样，硬着头皮也得把这段既要接手大佬遗留工作又要支撑项目开发的艰难时期给挺过去！

首先就是去把之前大佬负责的部分研究下，然后顺便把逻辑层剩余部分以及整个前端框架之前没有仔细看过的其他部分都了解下，以便当别人有问题时我能 hold 住！这回不像当初刚来公司第一次接触框架内核时那么一脸懵逼，没有那股难受劲儿了，毕竟那块天花板早就被我弄破了！

在那之后的日子感觉就像在泥潭中挣扎，支撑我挺过去的，不是当初为了实现共同目标的满腔热血，因为公司的发展方向与我的目标已经不一致，并且大佬已经不在了；不是觉得公司还能再让我有所突破，虽然也还会继续成长，但不会再有触到天花板的感觉了，大佬还在的话也许还会有；而是，且只单单是我的责任心。

在这种高强度、高压力的工作环境中，身体健康每况愈下，最终选择离开了。

总结

这段工作经历时间不是很长，才一年多一点，但它给了我工作至今的两个方面的「最」——因长期「996」和项目交付 deadline 而强度最大、压力最高；因突破天花板和确定之后的努力方向而收获最大。

作为一个以前端开发为职业的软件工程师，促进前端标准化、工业化，让前端开发更加有序且可快速装配是我今后的使命！