一个草根前端人的焦虑

缘起

之前看到一篇公众号推送：Deno 冲上榜首，Vue.js 首次屈居第二，JavaScript 2020 年度“新起之秀”都有谁？

Vite、ESBuild、SWC、TailWind、Snowpack、Vue3.0、Rzhi’qecoil、Deno、Lowcode…
不管是前端领域、还是技术领域、还是娱乐圈、每年都有涌现出一大堆的新玩意、每年都有新的鲜肉火了。

以往一年一届的技术大会，现在早早聊 一年要办十几次。

朋友圈转发的各种课程海报…

这是多角度、全方位攻击啊。我是不是落伍了? 我拿什么跟别人竞争？命吗？

如何看待新的技术？

我在面试时看到简历上说精通 jQuery、熟练掌握 Vue、React。我通常会问这样一个问题：
jQuery 当年那么火，为什么现在被 取代了？ 解决了什么问题？

从历史上看，所有的技术翻新和淘汰都是必然的，包括我们自己，首先我们应该有一个开放的心态去看待新技术。

其次现在是一个网红时代，技术圈也是。很多技术可能也经过了过度的包装和营销，让人眼花缭乱，容易盲目随从。

这值得警惕，不是所有技术我们都值得我们花大量时间去琢磨，乱点技能树的。随波逐流，容易让人舍本求末，疲于奔命，流失核心竞争能力。

所以说，怎么看待新技术，先问自己这些问题：

这是啥玩意？

解决什么问题？

要回答这个问题，你需要对相关技术的历史有所了解。以史为鉴，可以知兴替。如果你是一个有经验的开发者，对历史的了解是你的优势，至少你更容易看到问题的本质。
说到这里，再推荐一本书 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)，通过大厂招聘给我们描绘了一个优秀技术人的画像。加上我的理解，整理了下：

基础能力

逻辑思维。
学习能力
沟通、协作、组织能力

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

有独特的亮点

深度。

对某一领域、某些技术有深入了解
业务能力。这也算一个领域

说小点 - 项目

清楚自己在公司的业务价值，并尝试提升自己的业务价值。
能全流程参与项目业务建设(包括调研、建模、设计等)；
清楚自己做的项目的业务目标，用户是谁？目标是啥？ 你在其中有哪些贡献，项目的结果是什么，能否用数据说明?

说大点 - 公司

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

说远点 - 行业

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

广度。比如后端、运维、测试、跨平台、AI等等
体系化。更进阶的是形成一套体系化的知识网络，从点、线、到面

认知

对自己认知。明确自己的定位和业务价值，有清晰的目标和职业规划。
对专业认知。是看对技术维度、深度的理解和格局。站在点上、线上还是面上、结构化模型思维，能够在一定的体系认知上看事情。
对职业的认知。对职业、职员、团队的认识。这些会影响人的职业规划、工作态度、责任心、团队合作力。
思辨力，即洞察事实真相和思考分析的能力，能够看到事情的本质。
避免二元论认知。即非黑即白。
能够举一反三。对于同类问题能从多个角度看待，有不同的解决方案。对于同类方案，可以延伸解决其他类型问题。

自我管理、自我驱动、自我优化能力。主动的力量

有明确的目标，并有可执行计划
有时间管理的意识
终生学习的意识

要性

我看阿里系招聘都很讲究要性。 要性是指个体主动想去参与推动、主导改变的一种过程态度、对追求落地和拿到结果的持续行为。说白了要有追求，积极向上、主动探索、主动推动改变，而不是被动执行。

不局限在自己的专业分工，也要对上下游、全局有理解和思考。
技术热情。好奇心、 爱折腾，爱学习，爱总结。
自我驱动能力。自我学习、自我管理、自我优化。
不甘平庸、能自我证明。不满足于把事情做完，追求将事情做好、甚至是极致
总结能力。对自己、对项目、对团队、对公司、对行业有一定的总结能力，并能够推动进一步优化

有输出、有结果、有影响力。

这实际上也属于自我证明，除了管理好自己、还要去影响团队、影响业务、影响社区。
还有项目成果、个人产出

我有时候会在面试时问一些我自己也比较疑惑的问题，看他们有没有不一样的答案。

虽然我负责的是技术面，但我也知道，很多时候我们考察的一些基础技术问题，并不能完全体现一个人的真正水平。因此我会尝试多给机会让他们表达自己，花一些时间考察他们的软实力(或者说潜力吧)
大家身边应该也有挺多 一年、半年内，成长非常迅速的人，他们可能起步比较晚，后面能实现超越，大部分凭借着自己的要性。

我最近面试也问过这个问题，你的核心竞争能力是什么？你能做的事情可能别人毕业一两年，培训几个月可能也可以做？你怎么确保自己不被取代呢？

我得到的回答大部分是学习能力强、愿意吃苦、能独立完成…
能拿结果说明吗？

业务能力这个在本文提过好多次了，这个单独拎出来讲，是因为业务能力对技术人来说真的非常重要，也是很多前端开发者容易忽视的点。毕竟大部分人是做业务开发的，技术最终也是服务于业务，能不重要吗？

我之前也轻视业务能力的培养，也就是我给自己设置了边界，觉得业务是项目经理、产品、后端是事情，前端关注页面，关注上游给你的输入就行了。

这其实跟流水线工人有什么区别呢？

直到我换到另一个公司，他们全员都会参与产品评审、技术评审，开始我的状态是这样的：

会议中关键的几个人，产品、项目负责人、后端进入心流状态 ，各种业务术语满天飞， 有来有往，反应迅速，争论不休。

我发现自己跟不上(尽管我发现挺多人跟我一样)，只是旁听、甚至走神的…

一开始我是比较抵触的，这种会议有的一开就是几个小时，对于进入心流状态的人，乐此不疲, 忘记了时间的概念。而我们这些对业务不熟悉或者关注程度不高的人会觉得浪费时间。

事后我也反省了下，主要是在自己的舒适区待久了，片面追求技术，忽略了对业务能力的培养。

产品自不必说， 后端是业务的主要实现方，他们对业务流程的梳理、业务建模玩得很溜，自然很容易参与进去。

至于怎么提高自己的业务能力，废话就是多去参与，站在用户、公司、实现等多角度进行思考。有兴趣同学可以参考文末扩展阅读。我自知业务能力薄弱，这方面比较强的也可以提点提点。

如果非得说一下自己的核心竞争能力，我只能说是自我驱动的反省和总结、优化能力吧。不甘现状，可以让你去发现和反省问题，总结和洞察问题的本因、最后再针对性地进行优化，螺旋式地上升
生命不息、步履不停，最近的一些感想，非喜勿喷！