Menu

如何看待前端技术的不断更新及持续学习的态度

前端的更新迭代很快,很多知识来不及学就已经有新的内容出来了,让你猝不及防。从过去的Jquery和Bootstrap时代到现在的React、Vue、Angular时代,PC端、移动端、小程序,npm、webpack、git,浏览器、http等等内容。这么多概念,去了解就需要花很多时间。

前端的内容分为基础和实践两块,基础部分包括了HTML(语言、元素)、CSS(语言、功能)、JavaScript(运行时、文法、语义)、浏览器和API(实现原理、API),实践部分包含了性能、工具链、持续集成、搭建系统、架构与基础库。

明白什么是真正重要的

知道什么是重要的不容易,人太容易走神了,注意力太容易分散,人的感官依据外界刺激的强烈程度而反馈,刺激越多越新鲜越强烈,人的反应就大。在这些刺激之中,我们用在思考什么是重要的这个问题上的时间变得越来越少,我们独立判断的能力一天天被磨损。

年龄越大,学习的能力确实会越弱。一方面是因为身体的原因,因为年龄增长,大脑功能的衰退,思维能力相较于年轻人就已经发生了退化。还有知识的难度很高,也很难学习进去。日常的琐事太多,刚才也说了,注意力会被越来越多的事情分散掉,已经没有办法,如同学生一样专心学习,所以学习能力才会下降。

前端开发里真正重要的东西,很多年来都没有变过,也不会变(至少是很长时间内)。

一是语言本身,HTML, CSS, Javascript,前两者因为简单所以常被人忽视,但深究也有不少学问。Javascript最值得说,大家都知道前端的核心是Javascript,我们写来写去都是Javascript,runtime跑的是Javascript。但真正投入到语言的学习中的可能不多,很多时候我们都是被开发任务带着走,需要的时候学两下字,学习也就是搜索一下,很多时间被工具的熟悉消耗掉了。工具当然是需要熟悉的,只不过如果没有对语言核心的掌握,配置工具的时候就“配不进去”,只能让我们拷贝黏贴,使用过Gulp,webpack的应该都有这些体会。

二是web平台的工作原理,DOM,HTTP,浏览器装载渲染这些,细节有很多,这些东西不因为我们用的库和框架的不同而改变,而是库和框架在它们的基础上建立起自己的封装实现。要真正理解库和框架,往往核心就是理解它们的底层是什么,很多时候就是平台的API,平台提供的基础设施,比如NG用的zoneJS实现了change detection,如果理解了它背后的原理是对于浏览器异步API的patching,NG也就不神秘了。

还有一个是程序设计的能力。我可以不知道怎么在“框架A组件化”,但我知道怎么“组件化”,后者比前者更有适应能力和长期价值,万变不离其踪。JS程序设计,无论你用什么框架,真正需要注意力的是一些通用的问题,比如如何合理地实现App的模块化,如何让这些模块通信,什么是合适的通信机制,什么模式可以帮我架构等等。理解这些,任何框架我拿起来都可以和原有概念体系接上,并不需要特别地学习,用就是了。

基础和框架都重要,也都不重要,就算你js、浏览器、http原理、css新特性玩得飞起,要你设计一个UI框架你可能还是需要查文档或借鉴别人的东西,不信你试试看。就算你个人做出来看有几个人follow你的框架。术业有专攻,别歧视框架,也别抬高底层,这些所谓的底层能有多高的技术含量呢?重要的是你现在做的是什么,APP?企业应用?游戏?这些业务层面才是离用户或者客户最近,最能体现技术价值所在的地方。因为技术永远都是工具,是实现功能需求的工具而已

明白了什么重要,我们就在它们身上投入更多,不那么重要的那些,就少投入一点;对待的心态也有所区别,核心的东西追求完整透彻,辅助的东西我们可以拿来主义。对待工具就用对待应有工具的态度,拿出来用,用好放回去,不用请它们吃饭。

我也不喜欢面试官问的一些很原理性的东西,就比如我同事面试会问,说一下你理解的原型链…这时有些面试者会说不上来,然后我就会问,那你说下你什么时候用到过prototype,实例化的对象怎么指向的prototypetypeof nulltypeof undefined一样吗等等。这些很原理吗,不是吧。照样好多人说不对,你说这样的人再“会”那些新框架又如何。不过你要从企业管理上看,基础好不好无所谓,能按时干活就行。我遇到一些拿着20多k的人写的代码垃圾的一比,一点抽象解耦意识都没有,后期维护相当困难。我并不是说能解释清原型链闭包就能写好程序一样,我只是说必须要掌握基础,其次有编程思想

工程师

抛开前端,我们也是属于工程师,那也意味着需要具备工程师的一些能力。一个前端工程师需要具备三大底层能力,编程能力-去解决难的问题,架构能力-去解决大的问题,工程能力-去解决人的问题。难的问题,大概就是偏向逻辑的复杂,那我们可以通过逻辑拆分一些方式和刻意练习进行强化,所以你现在知道为什么面试造飞机,工作拧螺丝了吧,面试官就是要考察出你的潜力和编程能力是怎样的。大的问题,就是去解决复杂系统分析、多个协同管理,你也许一个大的系统里的每一块内容都可以做的不错,但是你无法把他们整理成一起,架构能力就能在其体现。人的问题,更多的是代码的规范、如何减少成本沟通,写出clean code,当然还有其他部分,目前阶段还不是很好的理解。

团队

前端需要和四个岗位线进行协作,设计、产品、后端、测试,而在其两两之间少不了沟通和交流,而如何让这些成本降到最低,也是对你能力的考察。其中你审美情况是怎样的,交互做的怎么样,对产品逻辑的理解有多少,为后端逻辑的考虑有多少,缺陷的产生是否比较少,对用户体验的感知又是一个什么样的程度,都是不可或缺的,效率也往往在其体现,这些能力就脱离具体的专业技术能力了,但也会起着比较关键的作用。

没人有选择的“智慧”,区别只是勇气

对待那些很不重要的东西,我们需要有做选择的勇气,这对嘈杂的技术圈里的不少人,是一个不小的挑战,所以需要自我训练:不用就是不用,不喜欢就是不喜欢,大大方方地怀疑,大大方方地恨。

每个人都做过nice guy,觉得所有新技术都是机会,所以一一请吃饭 —— 结果被强奸一百遍。

“大大”,“巨巨”说得天花乱缀,招聘启示写得再殷切,但决定是你自己的,你的精力在你有限的时间里是极其有限的,所以要把技术当成主动投资,投资就是选择这个,不选择那个,是有意识地自我控制的行为,投资不是把一万块分成100份,每份都压100块。三个框架你可以都做点功课,但你得决定投资那个,决定了就投入。

现在的技术,今天一个花样,明天又一个花样。每次都有承诺,每个承诺都很可疑:如果你这样这样这样再那样那样那样,问题就解决了,你看,很简单吧!比如大家都热爱的React,我个人就十分讨厌,不管他们怎么说,对我来说这就是一个缺乏品味的技术栈。今天Flux,明天Redux,后天MobX,破坏了一致性,反而回过来鼓吹JSX的表现力。Redux这样的承诺,化成“直观”的图形,多数人类却看不懂,却说它好用。

放屁。

我个人的看法是FB的技术团队只懂Hack,不懂设计,只不过有时候厂子大了Hack做得像模像样,让人误以为是好设计。很多人把自己的项目当FB。

Not me. 我决定不投资React,这是我的选择。因为这是我的选择,所以你也没有必要给我留言和我争论。我做了一个选择,我心安理得,我承担潜在风险,我愿意。

你也应该这样。

你可能有不同的选择,选择什么的结果都不会很差。但是如果你没勇气选择东搞搞西搞搞什么都搞,被坑了,你得先怪你自己。项目是你的,代码是你来维护的,搞好搞坏是你的。所以你得负起责任来,对自己诚实一点,做点接地气的决定。

不要害怕和别人不同,需要和别人不同的时候,就结结实实的决定。你受的教育不教独立和勇气,所以你得自己训练自己。

有时候靠谱的事只有一件,就是“顺其自然”

工具的开发者真想坑人的很少,但他们也是人,有时候一激动就把我们坑了。

把我们坑了不意味着工具不再提供价值了,我们应该把注意力放在它们提供的价值上,善加利用之,它升级你就升,他说同志们下一版本咱不兼容了,请大家把app重新搞一下,那你就搞,早点搞,不要想东想西耽误了时辰。多数时候也不过是npm update,不需要花太多力气。

在有价值的东西上投入一点时间来维护,这就像你投资了基金要交点年费一样,是正常的。你上了贼船,没太多选择,你不得不尊重这种选择,继续搞下去。

有时候该换的时候就换,工具只是工具,不是结婚对象,策略灵活务实一点,大多数情况下,做一个pros/cons分析并不难。

同样,不该换就不换,工具服务于更大的产品和商业的目标,如果这些目标是达成的,谁在乎你用的那个东西是不是最新版本呢,不是最新版本又怎么样呢,团队用了几年熟悉了,能当裤子穿了,就是自己的东西,版本也就没那么重要了。

搞清楚收益与成本,该干嘛干嘛。

本文固定连接:https://code.zuifengyun.com/2022/09/2923.html,转载须征得作者授权。

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!

¥ 打赏支持