什么是瓶颈期
初级前端的定义通常工做经验是 1 - 3 年，注意是 1 - 3 的工做经验而不是工做年限。前端
不少同窗常常有这样的状况，业务实在太多，能写完这么多业务已经花掉平常的时间跟激情，再也没有时间、精力去折腾了剩下的事情。node
每一个人的熟练度是有限的，最开始工做的时候，一个小项目或者需求开发时间须要一个月，而在工做一年或者更短的时间内，接受必定的业务毒打，使得框架熟练度、业务理解提高，能够将开发时间缩短到半个月。然而这个就是普通开发的极限，没有办法再借助熟练度来提升开发效率以后，就会很进入一段迷茫期。git
在现有的技术与熟练度已经彻底能知足如今的业务需求，公司给研发安排的内容都是占据预估好的时间。那么这个时候就是初级前端遇到的瓶颈期了。或者说这是任何一个阶段的研发都会遇到的一个瓶颈期。web
减小无效的工做
什么样的工做是无效（没有效率）的？面试
- 重复的业务从新写
- 重复的功能反复写
例子1：登陆业务
大部分活动 h5 都是须要开发新项目、新的代码，而不少业务都须要判断登陆态，若是你也碰到这个问题能够尝试下面的解决方案算法
将全部的登陆逻辑所有封装在 sdk 中，在开发新的活动的时候，能够将 sdk 直接经过 cnd 引入，判断当前环境未登陆的状况下，拉起登陆界面，进行登陆。数据库
这里推荐同窗用 Rollup 去开发一个 Library，比较方便。npm
例子2：权限业务
在中台系统中，基本上每一个业务中台（好比订单、客服等等）都会有对应的权限控制。每一个系统都要写权限控制的话，会很耽误时间，即便每次都是从上个项目 copy 过来，也很难保证将来权限系通通一升级的问题。小程序
对微前端的熟悉的同窗，能够将整个权限业务剥离成一个独立的子工程，而后每一个业务中台直接引用权限服务便可，这样能够保持权限业务的总体升级，而且不会影响到自己业务同窗的开发。后端
若是对微前端并非很熟悉的同窗，能够参考 git submodule 或者 npm 包依赖等等，也能够将业务抽离，统一开发、升级，只不过更新好的权限服务须要从新构建发布而已。
例子3：搭建基础脚手架
每次新开发项目的时候，会有一些基本的配置都不须要改变，好比：
- 请求的测试、预发、生产地址
- 构建命令，各类环境的配置
- 每块业务的特殊使用方法（如活动业务常常会使用到的分享功能等）
可使用 node 开发一个本身的 cli 工具，再根据不一样的业务预先配置好多份项目基础工程，这样能够根据不一样的业务拉取不一样的基础模板，减小新业务开发的搭建、配置时间。
例子4：本身的组件库搭建
虽然业内有很成熟的组件库好比 Ant Design、Vant 等等，可是要贴合每一个公司本身的特点与业务，通用的组件库确定是远远不够的。
能够配合 UI 设计，将公司的主体风格、基础组件所有规划一下，有意识的去沉淀本身的组件库出来。
在后续的迭代或者新的项目研发的时候，能够经过自建的组件库，快速完成界面的基础搭建。
这件事要主动去推进，否则通常很难落地。
上面的一些小例子，在第一次写项目的时候就有部分的基础代码，在第二个项目开发的时候就应该有意识的去设计、规划将这些内容进行封装、提取，从而在第三个项目的能够利用以前的设计跟基础的代码提升你的开发速度。
经过 1-3 年的项目训练，其实你应该具有，从多个项目抽取公共功能、业务，找到类似、相通点进行合并封装的能力（拆解项目、组合封装）。
这个理论上是良性循环的，能够将缩短后期迭代项目的开始时间，在这个过程当中，本身也扮演不一样的角色，获得不一样的成长与学习的机会。
上述的工做确定是会额外占用业余时间，但这也是一个学习、提升的过程。实际上，提升了效率以后，平常工做中反而会有必定自由的时间，去良性循环这个过程。
借助工具提升效率
vscode 一大把提效的插件，就很少提了，什么代码格式化、自动提示、资源代理这种，你们都是前端确定都常常用上。
可是不要把本身局限到前端的这个圈子里面，能够用点额外的工具来提升本身的效率。
这里的效率不只仅是前端开发这点内容，把眼界拓宽一点，放在整个研发工具链路上。
在需求-设计-研发-测试-上线-业务反馈这整个链路中，看看有什么样的工具能够提升前端的效率
将可预见、将发生、已发生与前端有关的问题都考虑进去。
这里面不少事情能够用 node 来作，能够本身研发，可是要考虑性价比成本的问题，不必定自研或者 node 是最优选择。
Jenkins Or Gitlab CI/CD
每一次的构建是否很痛苦，很耗时，而在多人协做的时候，还可能由于每一个开发者的系统环境不一样而致使线上异常问题出现。
当你遇到上述问题的时候，首先不要逃避，也不是再打一个新包去解决，而应该引入一个构建工具去帮你完成这些问题。
这些问题在大公司、大团队可能有运维或者有成熟的 devops 体系去完成，可是这并不影响你去学习、使用来提升本身。
若是团队中缺少这些的状况下，使用它将大大节约你在构建部署这块的精力。
Fiddler Or Chales
移动端调试一直比较麻烦，除了测试环境可使用 vconsole 工具以外，线上能够借助此类抓包工具，快速定位先后端分离项目的一些问题所在。
通常 mac 系统，Chales 用的比较多，windwos 用 Fiddler 多，选择你喜欢的就行。
Sentry
历来没有百分百完美的系统，上线以后的环境复杂度远超测试涵盖的用例，若是想更好地完善你的项目，团队若是没有足够的资源或者成熟的线上预警体系，引入 Sentry 将是一件性价比十足的事情。
这样能够节约你在找一些莫名其妙 bug 的时间，也是一件提升效率的利器。
Sentry 是一个日志平台，分为客户端和服务端，客户端(目前客户端有 Python, PHP, C#, Ruby 等多种语言)就嵌入在你的应用程序中间，程序出现异常就向服务端发送消息，服务端将消息记录到数据库中并提供一个 Web 界面方便查看。Sentry 由 Python 编写，源码开放，性能卓越，易于扩展。
Sketch And Pixcook
UI 给设计图的时候，仅仅肉眼是没办法还原的，拿到 psd 又须要会 ps 工具什么的，这里你能够推荐 UI 使用 Sketch 来给你设计图，既方便体积也小。实在不行，Pixcook 也能经过 psd 自动生成标注的前端代码，二者都是设计研发利器。
不要局限于框架
雷神的灵魂拷问：你究竟是雷神仍是锤神？放在前端也是同样，你是一个前端工程师仍是 Vue or React or Api 开发呢？
全部的框架都是开发业务的工具，在成熟的体系下，没有一件工具的价钱是超过人工的。你要考虑的不是怎么作好一个框架开发，而是怎么成为一个合格的工程师。
如今各类 web 框架层出不穷，各家小程序百花齐放下，多端框架也应运而生。学会一个框架的使用，其实并不难，最多两个项目，就可以熟练去使用了，由于框架的诞生就是为了让你快速去完成项目的。
底层技术与上层设计掌握的足够牢固，即便换了一个新的框架，你也能够快速上手。但这并不表明，你不须要去了解对应框架的设计与 Api， 而是避免成为 Api 工程师。好好想一想本身做为工程师的核心竞争力究竟是什么？
固然要是一个框架能玩出花，能解决全部的业务问题，那也是至关牛逼，但实际状况这种框架或者人不多。
总之能解决业务的研发才是能赚钱的研发，能赚钱的研发才是好研发。可能这段话说出来会被打，但现实赚钱的确实都是老板，而不是一个开发。
另外不管是底层知识、算法、设计的多厉害，可是必定不要脱离业务基础。为了面试，不少同窗会去刷题、刷算法，确实颇有效果，可是最重要的要学会怎么将这些全部的知识体系运用到实际项目中去，让他可以发挥最大的价值。
技术深度至关于内功，确定修炼的越深厚越好，可是必定要配合业务运用这层外家功夫，方能成为绝世高手。就比如郭靖一身高强的内力但仍是须要降龙十八掌才能御敌。
生死看淡，不服就干
单干
若是你在一个小公司，小团队的时候，就没事多折腾折腾本身，有什么新技术就上，前提是：
- 有必定的内心预期，不成熟的技术坑会很是多，内外部都会有很多的压力
- 预留足够多的时间去试错，业务必定是保障第一位
- 要有必定的备案，若是在新的技术解决不掉问题的时候，可以快速拿出备案解决
- 必定不要在主要业务中使用，若是出现问题，会致使团队的信任危机，影响后期发展，不利于后期合做
- 要有开放的心态，新的技术运用起来不是优越感爆棚，解决问题的同时，能够分享给团队的每位想要了解同窗
团队
若是你是在一个大公司，一个成熟的团队，那么能作的事情只会更多。
记住一个点，越大的团队，业务链路就越多，细节就越多，能下手的地方就更多，能拿到的资源也会更多。
因此要勇于承担责任与任务，在关键时刻顶住。
好比在新项目启动的时候要有足够的勇气主动去申请承担。前提条件是，你自己就要扛得住，值得信任，是一个可托付靠谱的人。
或者能够主动参与产品链路，与产品、研发、测试、运维、客服等等一系列与之相关的人员沟通，一块儿找到目前存在的痛点、难点，而后想办法去解决。
最好的办法是将你想作的事情，描述成他们想要的东西，而后他们能够借助你的资源来完成这件事，最后共赢局面出现，皆大欢喜。
写在最后
不管在哪都同样，作技术的切记心浮气躁，要赖得住寂寞，作得了冷板凳。