前端技术研发人员的能力模型

1 对于前端知识体系形态的理解

1.1 你的前端知识体系生长于哪？

了解前端首先还是建议了解一些浏览器的基础的工作原理，它是如何将js、html、css解析成为用户可浏览的页面的？

于我而言，javaScript就是按照当前运行时能够识别的规则，进行它WEBAPI的能力调用，进而被它解析为用户可视、可交互的内容。所以它的API面积和该客户端形态的权限范围就决定了前端技术能触达的能力范围。

所以如果领导让你做一个前端技术预研，别再说”我行！“，你应该说："浏览器能做这事"。你的能力上限不应该是你的知识体系，而是浏览器的能力 (#^.#)。

你的前端知识体系应该建立于ECMA standard、WEBAPI等这些前端标准上，而不是建立于某个前端框架上，前端的知识体系不是金字塔，而是一棵树，所以你的树干要足够的粗壮，它才能够足够稳定的成长。当然，如果你足够热爱，也可以先建造空中楼阁，然后慢慢向下扎根，不过如果这个过程没有喜欢，会比较痛苦。

1.2 我认为的最简单的前端能力分层结构

我最喜欢的前端能力分层结构是：组件化、工程化、自动化和辅助支撑。这三个层次会有交叉。

• 组件化：

  组件化应该很好理解，本质就是为了复用和解耦而进行的封装行为。

  狭义的前端组件化是指WebComponent，它和Promise的经历差不多，都是先有的实现，后被纳入的标准。

  截屏2021-06-19 下午1.22.02.png

而广义上，组件化这三个字是指封装的可以被引用的有输入输出的逻辑单元。所以不单单是有界面的WebComponent可以叫组件，一类能力的js库也可以叫做组件（是不是觉得我在强词夺理、偷换概念？(#^.#)）。

所以组件化能力就对于UI组件库或js逻辑库的封装能力，这也是比较基础的前端能力。这里不单单指微观的组件设计能力，也包含整体上一个组件库内部的依赖管理和公共API设计的能力。

• 工程化：

  我理解的前端工程化是从前端源码开发到生产输出的一系列相关的（支撑开发的工程结构及支撑生产的编译）解决方案。

  在前端发展的历史中，出现过许多语法形态的js的语法糖、不同风格和功能的css的预处理器，而产生这些东西最初目的都是为了更友好、优雅且简便的编写代码（我们暂且不提很长一段时间内ECMA标准更新的缓慢和客户端逻辑越来越重的问题。）。

  同时前端还需要兼容不同运行时（不同版本的浏览器，不同形态的客户端）的形态、版本等，我最早开始接触前端的时候（大概是大二）最苦恼的问题就做IE7、IE8的兼容，我需要对很多常用的css特性在不同的浏览器进行hack，那时候我就想，如果大家浏览器都遵循一套语法标准多好（emmm.....，我没有骂微软的意思）。而现在驮着V8的node和deno又让js有作为服务端的权限和能力，导致js库的工具链输出形态又增加了commonjs模块加载方式等。

  以上多样的语法形态和复杂的运行时环境都直接导致了前端的工程化相比其他编码领域更加琐碎和复杂。

  所以你想工程化做的好得会点啥？简单的说热门的taskRunner或者module bundler得会使用，如果足够喜欢，建议好好学习学习AST。

  编译的模式在变，但是编译的基础构造一直没变，在grunt和gulp的年代，图片压缩的依赖链末端是imagemin，形式进化到loader之后依然是，代码混淆Uglify也一样，前端工程化的演进一直都是有迹可循的，而不是断崖式的进化。

• 自动化和辅助支撑：

  自动化顾名思义，就是前端的持续集成和持续发布。而我所谓的辅助支撑是指辅助开发的命令行工具、IDE插件、浏览器插件等。

  其实自动化也可以算工程化的一部分，那么根据什么维度把它单独拎出来讲的？是根据支撑形态和语言类型。

  从支撑形态来说，工程化本身是解决代码从开发模式变为生产环境运行时可读模式的问题。而自动化除了减少部署的工作量，也是项目中集成和发布流程上的标准化工作。

  从语言形态上来说，自动化可以用node做，也可以根据团队统一的devops标准一起走，所以也可能会用到maven、gradle。此外还可能需要jenkins、circleCI、gitlabCI、docker等等，所以它本身不是单纯前端领域的解决方案。

  自动化具体需要的知识结构可以参考浅谈前端组件发布自动化中的”二、2：相关技术名词“。而辅助支撑的知识结构根据你团队的支撑的范围和多样性决定，这里就不一一列举了

2 知识地图

2.1 生态推荐的前端知识地图

下图是开源社区比较认可的前端能力模型 RoadMap ，大家可以根据自己的业务和团队情况进行有方向的选择。这里我只简单的分享一下如何看。

图片我只截取了一部分，它本身是提供说明的：

• 紫色的对号：推荐学习
• 绿色的对号：可选的学习项
• 灰色的对号：有时间的时候可以学习
• 无对号且置灰：不建议学习

上述说明只是针对生态的情况，他不建议学习的不一定不需要学习，还需要看你团队具体的技术情况。

截屏2021-06-20 下午3.05.32.png

2.2 我的前端知识地图

这是截止19年我的能力模型，在18年基本已经稳定，红色的部分是19年新增的。

不是这两年技术没有成长，而是更多的经历投入在一些框架的设计的工作上，偏软性的能力我就没再下图中展现（行，别骂了别骂了。我承认，是我懒得维护了）。

只是一个简单的参考，这是目前能支撑住我所在团队的技术研发的硬性能力模型。维度可能不严谨，但是它是我技术能力成长的顺序的一个写照。

截屏2021-06-20 下午1.51.46.png

3 一些不太成熟的建议

1. 把精力花在钢刃上：你不必什么都要会一点，但是你要知道它的技术构成和解决的问题是什么。
2. 一专多能：前端有很多方向，我建议先找个方向有深度之后再扩展广度。
3. 梳理并连接你自己的知识网络：前端的知识并不碎片化，前端的知识体系都是有脉络的，很少有单独存在的知识区域。
4. 给自己创造成长的机会：有一句话说的特别好”所有以产生价值为目的的行为，都应该以驱动自身价值的提升为准则“（嘻嘻，我说的 (#^.#)）。
   1. 如果你的技术能力低于团队的平均水平：你应该在工作中尽可能的去做一些自己没做过的技术盲区的任务。
   2. 如果在当前平台下的知识体系已经吃透了：尽可能的去做一些技术升级（不能给团队带来技术债务和维护成本的升高），尝试一些团队需要的、你也能成长的新的技术。
   3. 如果你当前平台已经没有机会再能让你尝试的新的技术了，那么恭喜你，你在这个平台或团队的瓶颈期到了。我个人的建议是，如果你有更好的方向的选择，且不想离开这个团队，可以尝试转型。如果你没有更好的选择或一心想做技术，那么就”谢谢再见“。
5. 技术没有适可而止：
   1. 问题的尽头有时不在issue，在源码：尽可能的找到问题的原因而不只是解决方案，不要懒得去看某些库源码，有些时候，看源码往往是解决问题的较快的途径。
   2. 技术学习不建议囫囵吞枣：分享一个技术文章阅读的习惯，我读一篇技术文章如果遇到不懂的概念，我会去搜索相关概念去学习，如果搜索的资料中还有不清晰的概念，我会继续搜索。这不一定是好的阅读习惯，但在你时间足够且知识体系有一定规模的情况下会帮助你成长。

附录：系列文章的目录结构

1、前言：一点对于前端框架设计的浅显思考

2、前端技术研发人员的能力模型

3、如何进行前端选型？

4、如何画好一个前端框架图？

5、如何进行前端框架推广？

6、关于开发人员支撑形态的见解

7、如何根据用户（开发人员）反馈进行框架优化？

8、前端框架用户体验方向的思考

9、专题1：前端自动化解决方案

10、专题2：前端研发流程下的权限控制