很多同学都非常努力，每天早出晚归的工作，但是几年下来之后，成长情况有非常明显的差异，有的很快成长为团队骨干，升职加薪，有的成长缓慢，濒临淘汰。~~~
学习&如何学习
俗话说「光学不练功难精,光练不学意难通」
我们不仅要学习，还要善于学习。
现在的前端知识体系比较庞大，html/js/css就不说了，框架有React、Vue等，有es6+、nodejs、typescript，RN，小程序，flutter&Dart，koa/express/egg，工具类有webpack、vite、yarn/npm/pnpm，还有可视化、低代码、serverless等，这么多的知识，要是挨个学一遍，需要付出庞大的精力，都很难学通。
我们真的需要学习这么多的知识吗？
是的。
但是不是每一种都需要我们精学。
我们要把学习的知识做一个分类，哪些是需要精学并且仔细研究的，哪些是需要泛学，知道他有什么能力能干什么事情有什么特点的。
通常，我们当前工作中能够用得到的知识是需要精学的，很清楚的知道即将用得到的也是需要精学的。那些用来扩展眼界，提升知识广度的是需要泛学了解的。
那么这样就很清晰了，精学的内容是可以提升我们当前的工作效率和质量的，泛学的内容是可以提升我们的整体素质的，开阔我们的视野和思路。
比如我现在在用React + es6开发业务，项目是前后端分离的，那么react、typescript等就是我们需要精学的，是需要认真研究的，相反nodejs、甚至flutter这些暂时只需要大概了解下就行。当我们遇到了性能瓶颈以及打包效率等的时候，webpack或者vite就需要我们认真研究了。
研究和系统性的学习
我们经常会在工作中遇到一些技术问题，这个时候为了快速的解决问题，我们需要很快的学习一个技术或者知识点，从而可以应对我们面对的问题。
比如一个没有typescript经验的同学要开发一个typescript项目，为了能够快速的进入开发中，需要找一些速成的教程来看，一般学习一些常用的语法和特性就可以进行开发了，但是如果想要把代码写的优雅简洁，并且能够把类似特性搞的明明白白的，就需要进行系统性的进行学习了，就需要把ts的文档好好研究一遍了。
那么下面我们就说说如何进行系统性的学习？
学习目标&节奏
「日拱一卒，功不唐捐」
步入工作后跟在校园不一样，没有大块的充足的时间供我们来学习，我们只能在工作之余利用碎片化的时间来更新知识。很多同学不适应这样的学习环境，碎片化的时间都用来刷抖音和微信，这样根本没有时间来进行系统性的学习。
所以我们需要给自己设置一个学习节奏，给自己定一个学习的小目标，不要太大，但是要坚持完成。
这个目标怎么定呢？
每天学习一个小时？可以。
但是很多时候会觉得比较难以坚持下来。因为自己定的目标缺乏执行路径和明确的目标。
给自己定一个OKR吧，按照OKR的指标标准，把执行的路径和考核标准定义下来。
OKR的要点：定一个目标，指定完成目标的路径和关键结果。
比如
O：学会typescript，能够熟练使用typescript开发项目
KR：每天最少学习一个小时，学会3个typescript的知识点。
这样有了明确的目标和实现目标的关键结果和路径，可以帮助我们坚持的完成目标。
突破自己
业务做多了，每天都在重复开发业务，觉得没有提升。
做业务开发就没有提升吗，就没有成长吗？
如果只是重复的做自己的事情，那么不管放在什么岗位，都不会有提升。
做一个需求开发的时候，是否充分考虑了不同的技术方案以及方案的优劣？
一个项目做了一年多，项目中每一个文件的作用是否清楚，每一行代码什么含义是否了解？
能否清楚的把项目的架构图画出来？
做的项目架构是否合理？
项目的方案设计是否合理，是否有更好的方案？
自己写的每一行代码是否有更好的写法，是否有优化的余地？
代码考虑到项目的性能了吗？考虑到复用性了吗？
多少同学学习了es6，却在项目中没有用过解构。
多少同学写了很久的箭头函数，却不知道箭头函数和普通函数的核心区别。
多少同学写的组件只是看着像组件，基本的解耦都没处理好。
多少同学写的一个函数有几百行。
多少同学一个项目做了好几年，项目中的一些文件是用来干嘛的不清楚。
如果上述问题都能做到肯定的回答，想不成长都难。
关于沉淀
工作初期，一定要在一个稳定的业务工作三年以上，频繁换工作是大忌。
作为一个面试过几百个候选人的资深面试官，各种各样的同学都遇见过，我们经常遇到一些工作了三五年的候选人，有不少有大厂经历和名校背景，但是结果面试没有通过，原因普遍是缺乏沉淀。
缺乏沉淀呢体现在哪里？
短时间里技术用过很多种，jQuery、vue、react、angular等，但是每一个只是会用。
对整体的技术环境体系理解欠缺，公司内开发、测试、部署等流程理解不够，公/私有仓库管理。
对于项目的技术架构不能清晰描述，更别提清晰的画出来整体的架构图。
业务描述不清楚，对于支持的业务缺乏理解，对于业务价值、业务逻辑、用户画像描述不清。
……
为什么会有这些影响呢？
- 工作初期，经验和技术基础都比较薄弱，在这个本应该打基础的时间段，把精力都浪费在了熟悉环境和项目上，反而没有时间让自己把技术做的深入，只能停留在表层。
- 每到一个新的环境，工作所依赖的基础设施需要重新熟悉一遍，需要消耗大量的精力，可能只是初步熟悉了如何使用就更换了，没办法深入理解内部机制。
- 到了一个新的环境，重新变成了新人，工作又要从最基础的做起，人与人之间的信任需要重新建立，尤其是与leader之间的信任。
这些缺乏沉淀的候选人共同的特征是频繁换工作，平均一年多换一份工作的经历，甚至更频繁。
做一件事情，就把这件事情彻彻底底的搞清楚，前端/服务端项目，整体的技术架构，产品功能和产品架构等等，当然把这些都搞清楚需要时间，但是当彻底的搞清楚这些之后，你会发现你不仅在技术上成为了专家，在这个行业领域里都是半个懂行的人。
承担
主动承担更多的事情，拓展自己的边界，不给自己设限，将会走得更远。
现在的职业分工，让我们很容易忘记自己首先是一个名工程师，然后才是聚焦于某个方向的xx工程师。
工程师是解决问题的，因此当遇到问题的时候，我们不应该简单的判断为「这个是后端的事情，跟我前端没关系」「这个问题不是我的问题，是xx同学的问题」就不管了，如果有余力的情况下，要尽可能的把问题研究透：问题的背景是什么，影响面是什么，产生问题的原因是什么，如何解决这个问题，以后如何避免类似问题的产生，等等。
不给自己设限，你会从一名工程师，逐渐成长为团队leader，技术负责人，业务负责人。这决定了你的职业生涯能够达到的高度。
当然，如果你在工作中忘记了自己是一名工程师，从整个产品甚至更高的角度来看待问题和解决问题，那么你的成就肯定会更高。
关注技术，也要关心理解业务
技术最终是要在产品上进行落地的，只有懂业务才对技术有准确的判断力。
业务能力应该是程序员除了技术之外，最具价值的能力，也是最必要的。因为技术本身很难赚钱，业务落地才能赚钱。当程序员具备了业务和产品能力，才可能选取业务和技术的折中点，又快又好的支撑业务，带来价值和效益。懂产品和业务（甚至交互设计）的技术，更容易跟其他工种进行沟通，用通俗易懂的方式介绍技术实现和难度，可以提升在企业中的自身地位和价值。此外，对于架构师，理解业务也是必备能力。
