一个草根前端人的焦虑

旧城等待， 2022-10-27 12:13 135阅读 0赞

大家好久不见，虽然变成了年更博客，但是我还是有坚持在用文字来记录我的学习和生活的。

首先给大家安利 Notion 这款笔记应用，这一年它确实给我的生活带来很多改变，举一些应用例子：

*  博客。以前我习惯用 Markdown + Github 来维护我的博客
 *  日常学习笔记、文档。之前习惯用 MindNode 思维导图
 *  任务管理，不管是个人时间管理还是团队项目协作。
 *  写日记、周报、总结。之前用 Day One
 *  记账等等

除了 VSCode，Notion 是我第二个重度依赖的工具。

功能强大倒是其次，重要的是我可以随时随地去写东西，只要打开一个网页就可以了，我可以丢弃掉其他杂七杂八的工具。这种便捷性，让你找不到借口不去写点东西。

它就像一张白纸，会让人有一种提笔去写写画画的欲望。

![format_png][]

实际上我现在很多生产工作只要一个浏览器就可以完成了。比如我最近就在使用 Code-Server，实现了在家无缝加班。再配合 Docker，将开发环境制作成镜像，也可以快速地构建一个开发环境。

回到正题

今天为什么又想起要写文章呢?  主要是早上看到一篇公众号推送：Deno 冲上榜首，Vue.js 首次屈居第二，JavaScript 2020 年度“新起之秀”都有谁？

Vite、ESBuild、SWC、TailWind、Snowpack、Vue3.0、Recoil、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 型人才，在多个领域都有深度，这种可遇不可求。

![format_png 1][]

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

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

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

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

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

## 核心竞争能力是什么？ ##

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

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

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

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

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

*  基础能力
 *   *  逻辑思维。
     *  学习能力
     *  沟通、协作、组织能力
 *  扎实的专业知识、包括理论和工程
 *  有独特的亮点
 *   *  对某一领域、某些技术有深入了解
     *  业务能力。这也算一个领域
     *  对产品技术全局有清晰了解，能发现业务及商业模式的短板，并提出解决方案
     *  对公司的业务发展甚至战略有独立见解、能够解决业务痛点、带领或影响业务发展
     *  清楚自己在公司的业务价值，并尝试提升自己的业务价值。
     *  能全流程参与项目业务建设(包括调研、建模、设计等)；
     *  清楚自己做的项目的业务目标，用户是谁？目标是啥？你在其中有哪些贡献，项目的结果是什么，能否用数据说明?
     *  说小点 - 项目
     *  说大点 - 公司
     *  说远点 - 行业
     *  深度。
     *  广度。比如后端、运维、测试、跨平台、AI等等
     *  体系化。更进阶的是形成一套体系化的知识网络，从点、线、到面
 *  认知
 *   *  对自己认知。明确自己的定位和业务价值，有清晰的目标和职业规划。
     *  对专业认知。是看对技术维度、深度的理解和格局。站在点上、线上还是面上、结构化模型思维，能够在一定的体系认知上看事情。
     *  对职业的认知。对职业、职员、团队的认识。这些会影响人的职业规划、工作态度、责任心、团队合作力。
     *  思辨力，即洞察事实真相和思考分析的能力，能够看到事情的本质。
     *  避免二元论认知。即非黑即白。
     *  能够举一反三。对于同类问题能从多个角度看待，有不同的解决方案。对于同类方案，可以延伸解决其他类型问题。
 *  自我管理、自我驱动、自我优化能力。主动的力量
 *   *  有明确的目标，并有可执行计划
     *  有时间管理的意识
     *  终生学习的意识
 *  要性
 *   *  我看阿里系招聘都很讲究要性。要性是指个体主动想去参与推动、主导改变的一种过程态度、对追求落地和拿到结果的持续行为。说白了要有追求，积极向上、主动探索、主动推动改变，而不是被动执行。
     *  不局限在自己的专业分工，也要对上下游、全局有理解和思考
     *  技术热情。好奇心、 爱折腾，爱学习，爱总结。
     *  自我驱动能力。自我学习、自我管理、自我优化。
     *  不甘平庸、能自我证明。不满足于把事情做完，追求将事情做好、甚至是极致
     *  总结能力。对自己、对项目、对团队、对公司、对行业有一定的总结能力，并能够推动进一步优化
 *  有输出、有结果、有影响力。
 *   *  这实际上也属于自我证明，除了管理好自己、还要去影响团队、影响业务、影响社区。
     *  还有项目成果、个人产出

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

虽然我负责的是技术面，但我也知道，很多时候我们考察的一些基础技术问题，并不能完全体现一个人的真正水平。因此我会尝试多给机会让他们表达自己，花一些时间考察他们的软实力(或者说潜力吧)

大家身边应该也有挺多 一年、半年内，成长非常迅速的人，他们可能起步比较晚，后面能实现超越，大部分凭借着自己的要性。

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

我得到的回答大部分是学习能力强、愿意吃苦、能独立完成...

能拿结果说明吗？

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

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

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

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

![format_png 2][]

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

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

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

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

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

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

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

生命不息、步履不停

最近的一些感想，非喜勿喷

## 扩展阅读 ##

本文提到的一些引用以及扩展阅读

普通的程序员和大神级的程序员有什么区别？

程序员业务能力

研发效率破局之道

10x程序员工作法

前端工程师是否有成为CTO的可能？

后端同学是不是比前端同学理解业务更快？

技术人员怎样提升对业务的理解

中台“搞砸”简史：成功的中台都是相似的，失败的中台各有各的失败！

技术选型指南

捕蛇者说：个人知识管理体系系列

JavaScript 20 年

心流理论

信息茧房这个概念如何理解呢？

PDCA 循环工作法/戴明环

软技能

程序员修炼之道

### 最后 ###

如果你觉得这篇内容对你挺有启发，我想邀请你帮我三个小忙：

1.  点个「**在看**」，让更多的人也能看到这篇内容（喜欢不点在看，都是耍流氓 -\_-）
2.  欢迎加我微信「huab119」拉你进技术群，长期交流学习...
3.  关注公众号「**前端劝退师**」，持续为你推送精选好文，也可以加我为好友，随时聊骚。

![format_png 3][]

![format_png 4][]

点个在看支持我吧，转发就更好了

[format_png]: /images/20221024/3340fa5ab8ad41ac82a7ef13f4f26468.png
[format_png 1]: /images/20221024/2cf0967486704192b5d66a2120781ad8.png
[format_png 2]: /images/20221024/fec2830dae0941ea8fcca17b33fbb287.png
[format_png 3]: /images/20221024/8b172e6f9d73451da416f395a8f12f53.png
[format_png 4]: /images/20221024/01d12f6f658e4787842f35694ff1aaee.png