2020 年发生了很多事，整个社会、国家，公司、家庭、个人，都发生了一系列的变化。这些变化使自己产生了强烈的危机感,这种危机感迫使自己必须要做出一些改变，去提升自己，去思考未来。
然后我想，我应该通过一个 review 来看看 20 年做了一些什么，不管是好的坏的都做个总结。然后也给 21 年定个人计划，年末再回过头来看看自己到底能做到什么程度。

工作

20 的公司可以用破而后立来形容，经历了大范围的'优化'，两次大的组织架构调整，频繁的旧人离开新人加入。
而我也在这个背景的推动下加入到了 AR 团队担任 FE Leader，对公司所有的 FE 负责。
在这一年里工作重心发生了非常大的转变，再没有时间投入到代码中、没法再花时间在具体的项目中，也没有精力去细扣团队成员的代码质量。我开始需要将大量的时间投入管理工作，需要为整个 FE 团队考虑，团队价值、团队发展方向、绩效、每个成员的成长、以及小伙伴们捅出的各种娄子、每个 Q 的 OKR 和 Review。
不过收获也是有的

• 团队评价：我们的团队评价从 4 分提高到了 4.5+ , "一般" 评价已经没有了，非常满意超过了 50% , 这个的非常不容易
  
• 技术债务：我们从年初梳理了公司所有 FE 项目并将发现的各种问题全部都梳理成 TODOList，每个 Q 规划时间去逐一解决这些问题，而在这次 review 的时候再看已经都处理得差不多了
  
• 技术分享：从 Q4 开始要求每个团队成员都需要些一项技术 OKR ，拓展成员们的技术视野或者将已有的经验做个积累。由此我们建立了稳定的技术分享机制每周一次
  

专业能力

关于专业能力，其实我自己是个对代码比较痴迷的人，写代码对我来说并不完全关乎工作，而是自己享受这个过程，享受发现问题或者创造问题然后再解决问题的这个过程。这半年里基本大部分的下班回家后的时间都会写代码，我将大量很多时间投入到了 vue3、vite、typescript 中(公司的技术栈是 React 系)。
在 20 年 4~5 月份的时候，萌生了使用 vue3 重写 Element UI 的想法，当时有着很明确的思路，我想要实现一个现代化的前端框架，没有选择自己弄个不一样的原因在于我没有设计师😅 ，所以干脆就直接用 Element 的 UI 设计。 而 Element 本身有着 1.4k Issues ，维护得也是很少了，而且之前的代码也有着很多考虑兼容性的处理，而 vue3 本身便是基于现代浏览器的所以这些处理是没必要的。所以我的重点，不是当个翻译器，将 Element 翻译一遍来获取热度，我需要借这个机会梳理自己的前端知识，通过这个项目给自己做沉淀，同时也去尝试自己的各种想法。于是便开始了 elenext 这个项目。
断断续续大半年的时间，有工作的原因也由于我想要慢工出细活的想法导致组件库并没有太大的进展，身边的朋友确是总在催我快点怕我错过了这个'红利期'。毫无疑问我错过了，不过对此我并没有太大的感觉，我总是觉得稳定和持久的输出才是最重要的，在开发 elenext 的过程中附带的产出了 tsrv 、vite-plugin-vuedoc 、vptypes 这几个工具。

• tsrv -> https://github.com/JasKang/tsrv 开发一个组件库项目需要用到各种打包配置，而这些配置是可以复用的。而且也不希望一大堆的打包工具以及各种开发配置文件污染工程目录，所以便将打包、调试、测试 全部提取出一个 package，作为一个通用的 bundler 工具。tsrv 基于 rollup 封装，集成了build watch test 三个常用的命令，加入了对 vue3.0 的支持，包括 vue@jsx-next, 支持 typescript , 支持生成组件 declaration d.ts 类型文件。
• vite-plugin-vuedoc -> https://github.com/JasKang/vite-plugin-vuedoc 组件库需要文档，需要更方便的在 markdown 文件中编写组件示例，之前的一些组件库是基于 webpack + md-loader 实现的，而我用的是 vite , 所以便造了个 vite-plugin-vuedoc ， 目前已经有一些开发者在使用了 ღ( ´･ᴗ･` )比心。
• vptypes -> https://github.com/JasKang/vptypes 要写的组件很多了，每一个组件都需要写很多重复的 props 定义，而同时我又有点强迫症，每个 prop 都要有严格的 ts 类型提示，所以便有了 vptypes 。顺便将它从 elenext 中抽离出来作为单独的仓库。
  本来有一个类似的工具 vue-types 做了同样的事情，不过他的实现在 oneOf 中需要使用 as const 才有严格的类型检查，这让我有点受不了😂。

而 elenext 项目本身进度确实很慢，我在尝试着重构之前的 dom 结构以及 style ，并全面采用 css variables，这样能让 css 选择器的查询减少不少，同时也能更好的支持自定义主题。而在组件层面需要优化之前的冗余的结构移除掉，同时也需要去思考怎样用更适合 vue3 的方式去实现，比如重写 Popper、Grid 等组件，这些也都是尝试的过程，并没有找到所谓的最佳实践。

代码之外，中间还因为它收到一些邮件邀请
比如说 ant-design-vue element-plus

不过由于自己在时间管理上面做得太糟糕，以至于并没有参与。

甚至还有不少招人的😂。

除了自己的瞎捣鼓，这一年中也从一些大佬们的项目中学习到了很多不一样的东西，随着工作的越来越深入，我们会遇到各种各样的问题，而这些问题社区并没有给出完美的答案，所以我不习惯等着别人来解决，想要成为解决问题的人，同时也回馈社区。

• swc、esbuild: 现有的 bundler 环境下 tsc 和 babel 太慢已经开始影响 FE 的日常开发了，虽然缓存已经能在二次编译的时候提升不少速度了,而 @babel/plugin-transform-typescript 采用直接剔除类型定义的方式来支持 TS 从而提升了编译效率，但还是不够。swc 和 esbuild 使用 Rust/Go 从语言层解决问题大大提升了性能，这两者的定位也各有不同 esbuild 更像是一个 bundler , 而 swc 是个 transformer。不过很多时候解决问题的同时也会带来问题，比如剔除类型定义导致 declaration 丢失，需要自行生成 d.ts 文件

• Snowpack、Vite: 浏览器原生支持 es module 给我们的 bundler 带来了新的可能。他们的原理在于：每一个 import 便是一个GET 请求，用一个 Server 服务来处理这些 import 请求，在服务端转译，返回浏览器能识别的 js 代码。其中在处理模块依赖关系上是件非常繁琐的事。

• react-refresh、esm-hmr 保持组件状态，更好的热更新
  react-refresh 通过一个 babel 插件收集到所有 React 组件并注册到 runtime �配合 React 16.9 提供的
  ReactFiberHotReloading 来刷新组件

• Vetur、VueDx、volar 基于 language server protocol 来解决 Vue SFC 文件在 VSCode 下的各种问题

从中能看到前端的更新非常快，总会出现一批又一批的事物来解决老的问题，同时也带来新的问题。我们需要不断的学习，不在于工具本身，而且新工具的产生背后的思考，以及去看到各种各样的可能性