前言
在前端三大框架日益变成前端必备工具时, 考察一些框架的源码变成了面试必问, 也是初级前端到高级前端实现晋升的有效途径之一. 也有很多资深大佬推荐我们有时间多去读源码, 能很大程度提升自己的能力和认识.(大佬请绕过忽略, 只是可能写给刚入门的前端同学的一些观点)
那么作为一名业务前端, 或者一名初级前端, 或者也是一名高级前端该怎么看待这个事情, 有没有必要真的去研读源码, 以及将这件事放在什么重要等级上呢? 这也是很多前端或许扩大到程序员都一直在争议的话题: 面试造火箭, 实际拧螺丝.
背景
其实, 在我们讨论一件事有什么价值之前, 有两个问题我们要必须清楚, 1 这件事是否是有益的 2 这件事是否适合现在的自己, 是否能解决自己当前的刚需.
第一个问题, 学习一些框架源码肯定是有益的, 这个毋庸置疑的.
第二个问题, 对于当下的自己是否有必要, 有没有必要当做提升自己或者一定要变成必读的部分. 这个我们大多数人并不确定其实.
技术可能的几个阶段
在谈一些技术框架的时候, 首先要认识到技术框架意味着什么, 什么是我们真的要学习的. 前期, 掘金还相继出现过一波的什么停止学习框架, 驳停止学习框架之类的文章, 起源就是因为外文的一个大佬提倡大家不要以学习框架为主为最终目的, 让大家尽量多把重心放在技术和设计思想上, 然后有些人曲解了观点. 我的观点也是如此, 非常赞成原文的观点. 我自己将技术分为以下三个阶段:
基础阶段
技术基础, 底层 API
技术原理 (入门层次)
基于框架的基本使用
进阶阶段
框架源码解读能力
代码设计思想
针对业务逻辑分析定制技术方案
知识广度
技术原理 (深层次)
专家阶段
基于框架的研发 (造轮子)
基于技术基础的研发 (造轮子)
基于业务的聚合设计
针对大数据, 大并发, 高要求, 高安全等需求的高质量方案
如何学习
目前市场上大多数的前端属于 5 年以内经验的, 随着大部分公司对前端的工作经验要求越来越高, 慢慢的公司都喜欢加上一条期望 3-5 年的工作经验. 因为前端技术在快速迭代, 我最诚恳的建议就是重学前端.
基础学习
首先, 我们有必要列一下前端的知识图谱. 一般情况下, 图谱上所能列出的是多数都有书籍参考或者大部分所熟悉的知识点, 也就是处于第一阶段的. 这时候我会推荐大家学习以及了解的内容:
各个技术名词的 mdn 解释
技术大佬对一些名词和常见问题的解释
各类技术的权威指南, 比如 CSS 权威指南, JS 权威指南, http 权威指南, dom 编程艺术, Linux 私房菜
技术框架的官网, 比如 vue,react,ng 各自的官网以及社区, GitHub 站点以及 issue
进阶学习
技术进阶的书籍, 比如 JS 高级程序, 高性能的 JS 设计
基于技术或者框架实战总结的书籍, 比如一系列类似名称, es6 实战, vue 实战等
技术思想的, 重构, 设计模式
框架源码解读, 可以看大佬解读的或者自己直接看源码
基于项目分析问题, 改进问题, 总结反思
专家学习
总结工程性质问题, 分析共享, 思考模型
总结思考基于底层如何做封装设计
总结思考基于框架进行设计
定义团队研发思想
造轮子
技术方案解耦与针对性方案
考察源码是为什么
考察深度
考察对源码的理解实际是考察你的技术深度, 如果你能将框架中的一些设计原理越能详细的说出, 理解对, 说明你不但基础好, 而且在技术深度上有一定的造诣. 当然不得不说, 随着这些内容变成面试必问题, 这类问题的答案在网上有非常多的版本, 而很多开发者可能会不求甚解的去背, 甚至在不理解, 基础不好的情况下, 一定要看懂源码的整个内容. 如果我们的基础不是特别好, 当务之急还是基础牢固一点.
那么其实, 如果你的项目具有一定难度或者代表性, 能体现你的技术深度, 也是未尝不可的, 但大多码农可能没有特别典型的项目能真实体现自己的全部能力, 尤其是很多公司业务驱动的前提下, 即使你有较好的技术可能也没有空间去发展.
考察技术兴趣
考察你是否读了源码也是为了考察你是否是属于极客类型的码农, 意味着你可能很喜欢学习研究一些代码, 对技术具有更高的兴致, 具有更好的潜力.
那么其实, 如果你不读框架源码, 你能经常关注一些大佬的博客或者技术贴, 或者经常参与一些界内的论坛, 那么也可以用来证明你这点符合要求.
用来过滤
这点是最直接的目的, 因为考察前端基础可能对于 3 年甚至更久经验来说, 太没有办法过滤出什么了, 所以考察框架源码是为了过滤出你和其他人的差别, 从中选择出更具有优势的候选人.
我们该怎么看
心态平和
不管公司提出这样的面试题是否合理, 我们都该以正确平和的心态去理解这件事本身, 不要有不平衡或者觉得这样考核没价值. 公司怎样筛选人才是公司的权利, 或者说是面试官的面试标准, 我们能做的只是让自己尽可能优秀, 在这方面可能的话花出一些时间了解一下.
重点是什么? 基础 + 实战 + 攻关
无论什么时候, 技术基础都是在最重要的部分, 我们应该让自己的技术基础足够扎实, 这样能够减少一些低级问题, 能够快速的解决一些问题, 也能够在框架更新迭代的时候, 不因为框架迭代而心慌, 因为无论框架怎么迭代, 其都是基于基础 API 而设计封装出的一些 API.
实战能力是最实际的能力, 我也称这点为工作技能, 解决实际问题的能力. 我们做一切的学习以及研究都是为了解决实际的问题, 而不是为了学术或者为了好看或者 kpi. 这里的实战能力就是针对一些需求, 最好与相应技术的对应, 或者可以做一定的关联. 当符合某些条件时, 我们能够根据已有的知识点, 提出完成需求所应该具有的技术方案, 以及其细节处的收益和风险点.
攻关能力, 是指能够为公司提供技术储备以及解决重大的技术难题. 尤其是目前公司内或者网络上缺少比较类似的成熟的, 针对性的方案时.
看框架源码是看什么
我们学习框架, 不建议形式一样的去看每行代码, 然后最终结果是我们看完了整个框架每个地方都知道怎么实现的了, 因为这样做就像我们要抄一遍课文, 然后每个地方加上注解一样, 固然熟悉了, 但没有什么直接价值.
我建议我们要至少处于以下 4 种角度去学习源码:
1 为了更好的理解和使用框架. 就像之前很多人都会看 API 使用 jq 一样, 实际上很多人不能正确合理高效的使用. 我们读源码是为了让我们更好的理解框架为什么能实现这样的功能, 以及我们怎样才能更好的用好, 比如像基于 vue 框架写的 ui 框架, 我们可以认为那些写 ui 框架的人比较好的理解了框架的一些设计思想.
2 学习设计思想. 在没有很好地项目代码作为参考学习的案例时, 其实我们最好的案例就是各个框架的源码, 我们在读源码时, 要清楚每个关键点的设计总体是依赖于什么实现的, 而不是记住具体的代码. 比如双向绑定核心就是依赖于对象的定义属性增加监听, 比如自定义事件的核心是发布订阅机制, 比如 keep-alive 的实现的基本原理是依赖数据缓存节点等. 也许框架里写了很多 API, 实现了很多功能, 但是其一些核心的设计上可能用到的设计思想都是一样的, 我们不需要重复的学习理解每个 API 是具体怎么写代码的.
3 代码技巧和代码风格. 一个框架被开源被大多数人使用, 我们还要从中学习框架的代码风格, 代码组织方式, 代码的技巧, 这些都是只学会基础和设计模式后还需要提高的部分.
4 更多的去延伸场景, 针对性的学习. 每当我们读一段源码时, 要将之以一个新的角度去解读, 而不是以框架的某个文件, 某种算法单独的局限于这个场景去分析. 我们需要为我们自己想总结的内容找出一个更加独立的场景和技术话题, 然后综合自己看到的几个框架文件, 思考得出自己的答案.
小结
就到这里了, 希望大家有不同看法积极发言, 下次在看完源码之后能够总结出一些不同的文章.
来源: https://juejin.im/post/5c96234ff265da61162467d1