一个草根前端人的焦虑

解决什么问题？

要回答这个问题，你需要对相关技术的历史有所了解。以史为鉴，可以知兴替。如果你是一个有经验的开发者，对历史的了解是你的优势，至少你更容易看到问题的本质。

说到这里，再推荐一本书 doodlewind 翻译的 JavaScript 20 年

能不能解决你现在面临的问题? 如果不能解决你现在的问题，大概率你也用不上它，如果你精力有限，姑且可以放一边，以后你需要它的时候，如果它真正有用，自然会出现在你眼前。

因为从实用主义角度，你没有机会实践它，你很快也会忘记它。

如果你很有兴趣，那么你可以深入去看一下怎么解决的？

架构是怎样的，思想是什么？最重要的还是思想呀

再深一点，整体流程是怎么走的？

如果你要成为这方面的专家那就得深入去学习源码了

如果没搞明白上述问题，就很容易落入陷阱、走冤枉路。这种例子比比皆是，比如微服务、中台比较火，大家都纷纷模仿，不搞这套就不牛逼了，搞到最后填不完的坑…

一方面可能是技术本身不成熟，另一方面是某些技术一旦离开了自己土壤，就很难存活。

哪些东西值得学习？

计算机科学基础。越核心的东西、更新的频率越低，这是每个技术人的内功。像张无忌一样，内功越强，杂七杂八的武功可不都是信手拈来？

沉淀下来的东西。

不管什么时候，新技术往往是成群出现的、屡见不鲜。比如之前各种各样的 CSS-in-js 库、各种状态管理库、各种跨平台小程序框架、视图框架…

真的是你需要的吗？如果不是要解决你的燃眉之急，尚且先慢下来等待他们自行洗牌，最后能活下来的才是你应该学习的。

更进一步的是形成属于自己知识体系，对知识进行归纳和内化、找出知识之间的关联。当分散的点联系成了网络，等待下一步质变。

深度还是广度？

知乎上面有很多类似的问题：

对于年轻的程序员，知识的深度还是广度比较重要？

知识的广度和深度哪个更重要？

深度重要还是广度重要？

…

显然这是很多人的疑问

相较于纠结深度还是广度，一个更重要的原则是：不要给自己设置边界。这也是很多人容易陷进去的误区，举一些生活中常见的例子：

我安安静静敲我的代码就行了，业务需求问题我不关心

我就按照原型实现了页面，用户怎么使用我不管

任务没完成是后端问题，后端接口还没提供，前端没办法干活

老是加班，项目还是逾期了，是 TeamLeader 的事情，我已经做了我该做的。

需求评审会议、技术评审会议像是后端和产品的相声专场，跟我关系不大，好浪费时间

…

这应该是新时代的井底之蛙吧。给自己设置边界，只会让自己处于一种被动的状态，这不仅限制自己的发展、限制自己的眼界，遇到事情也会互相推诿；抗风险能力也会比较差，更容易被取代。

研发效率破局之道 中一个重要的关键词就是 “打破竖井”，旨在我们要打破自己的边界，站在更高的视角、或者全局的角度看待问题。你会发现现在很多流行的技术和实践都在体现这一点，比如：

全栈工程师。全栈开发就是让工程师不再只是对某一个单一职能负责，而是对最终产品负责。全栈开发是一个很好的抓手，逐步提高全栈开发的程度，大家的目标自然就会对齐，从而主动去提高，那其他方面的提高就容易得多了。

DevOps、SRE

开发左移、开发右移、测试左移、测试右移

在打破竖井后，上面那些问题可能会这样子发展：

我安安静静敲我的代码就行了，业务需求问题我不关心

你会去参与项目研发的整个过程，包括需求评审、领域建模、设计、开发、测试、部署上线等等。

一来你对需求信息更加清楚，避免信息在层层传递的过程中出现误差，导致闭门造车；

二来可以发现流程中的各种瓶颈，做出针对性的优化和建议；

三是，了解这些信息有利于后续的开发计划、优先级划分

四是，紧密的沟通和协作，可以提高研发的运作效率，学习各自的优点。比如产品面向用户的思维、后端业务抽象能力、测试的缜密细致…

最后，这显然也可以锻炼业务能力

我就按照原型实现了页面，用户怎么使用我不管

Eating your own dog food, 把自己当成用户，从用户角度分析需求是否合理？用户体验是否友好？

关注需求背后要解决的业务问题，而不是产品经理的需求。如果你想摆脱被产品经理支配的恐惧，那么你就需要在往上游走，找出原始的业务需求，尝试自己去理解和分析，再配合技术的视角判断产品给出的方案合不合理，是不是产品自己YY拍脑袋的？尝试在产品需求上提出自己的看法，改进甚至拒绝不合理的需求。

任务没完成是后端问题，后端接口还没提供，前端没办法干活

前后端协作出现了哪些问题？能否要制定一些协作规范？例如文档先行、API Mock、接口自动化测试

老是加班，项目还是逾期了，是 TeamLeader 的事情，我已经做了我该做的。

项目在流程上出现了什么问题？研发的瓶颈是什么？怎么提高各个环节的研发效率？反馈机制是否完善？沟通是否存在问题？问题为什么不能提前暴露？ 哪些可以自动化、提高流程效率？

需求评审会议、技术评审会议像是后端和产品的相声专场，跟我关系不大，好浪费时间

不给自己设置职能边界，尝试左移和右移，去参与上游和下游的流程。

业务能力很重要，技术人本来不就是用技术去实现业务自动化的？

很多公司的后端很重视在编码前需求分析、设计和评审。在前面的环节把该考虑的都考虑了，后面可以少走点弯路。将业务流程梳理清楚了、建立合理的业务模型、再映射到表结构、后面的实现基本就是照葫芦画瓢了。

这些都是值得我们学习的。

…

在打破自己的竖井之后再去谈深度和广度问题。

很显然，两者是不冲突的，我们需要广度、这不仅是指技术上面的广度、还有生活、沟通协作、管理、理财等软技能上面的广度。我们也需要深度，这提现了你的专业水平，是你的核心竞争能力。

当然，像 Morgan 说的更理想的是 M 型人才，在多个领域都有深度，这种可遇不可求。

也许这里的问题在于大部分人并不清楚自己要往哪个方向发展，眉毛胡子一把抓什么都学，祖国需要我去哪里我就去哪里。你也是这样吗？

就前端的细分领域就有跨平台、Iot、数据可视化、NodeJS…

这些领域也不断在扩展、以及和其他领域进行交汇，比如AI、Serverless、大数据…

怎么选择还是看自己的喜好，以及是否有平台进行实践。说到底还是那句话，不要给自己设置边界。

除了避免主动性的边界设置，也要提防被动的信息茧房。这是后话了

核心竞争能力是什么？

对于技术人，技术是立身之本。但是想想自己掌握的技术门槛并没有那么高啊？你会JS、HTML、Vue、React，别人无基础培训几个月出来的也可以‘一把梭’。再说你老了，拿什么跟年轻人去争福报？

这也是我经常问自己的问题。尤其是在日复一日，每日重复拧螺丝的日子里。

对于核心竞争能力，我觉得可以分为两个部分：

首先是硬的。即上文说的，你的技术广度和深度，这体现了你的专业水平和横移能力。这些技术深度和广度是不断学习和累积，不是几个月培训就能实现的。

其次是软的，这个涉及很多方面，比较抽象。早早聊这个面试专题不错(二次GG、早早聊记得给我打she)，通过大厂招聘给我们描绘了一个优秀技术人的画像。加上我的理解，整理了下：

基础能力

逻辑思维。

学习能力

沟通、协作、组织能力

扎实的专业知识、包括理论和工程

有独特的亮点

深度。

对某一领域、某些技术有深入了解

业务能力。这也算一个领域

说小点 - 项目

清楚自己在公司的业务价值，并尝试提升自己的业务价值。

能全流程参与项目业务建设(包括调研、建模、设计等)；

清楚自己做的项目的业务目标，用户是谁？目标是啥？ 你在其中有哪些贡献，项目的结果是什么，能否用数据说明?

说大点 - 公司

对公司的业务发展甚至战略有独立见解、能够解决业务痛点、带领或影响业务发展

说远点 - 行业

对产品技术全局有清晰了解，能发现业务及商业模式的短板，并提出解决方案

总结

面试前要精心做好准备，简历上写的知识点和原理都需要准备好，项目上多想想难点和亮点，这是面试时能和别人不一样的地方。

还有就是表现出自己的谦虚好学，以及对于未来持续进阶的规划，企业招人更偏爱稳定的人。

万事开头难，但是程序员这一条路坚持几年后发展空间还是非常大的，一切重在坚持。

开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】

前端面试题汇总

JavaScript

前端资料汇总