前言
自 15 年 9 月第一次接触前端开发到现在已经过去了五年多，最开始是从一个很小的外包团队团队出身，没有带，没人管，几乎一个人干了 2 年多的活。
做了接近 3 年的组长，碰巧近期团队在调整，今年也经历了很多事情，回想一下自己这一路倒也挺有感触。
虽然我不是一个很好的组长，但也见过不少五年工作三年经验情况的同学，他们在遇到瓶颈期时候的迷茫与无措。
毕竟自己算过来人，写一下对初级前端怎么样突破瓶颈期的一些理解与思考，希望能对部分同学有些启发跟帮助，也欢迎留言讨论。
什么是瓶颈期
初级前端的定义一般工作经验是 1 - 3 年，注意是 1 - 3 的工作经验而不是工作年限。
很多同学经常有这样的情况，业务实在太多，能写完这么多业务已经花掉日常的时间跟激情，再也没有时间、精力去折腾了剩下的事情。
每个人的熟练度是有限的，最开始工作的时候，一个小项目或者需求开发时间需要一个月，而在工作一年或者更短的时间内，接受一定的业务毒打，使得框架熟练度、业务理解提升，可以将开发时间缩短到半个月。然而这个就是普通开发的极限，没有办法再借助熟练度来提高开发效率之后，就会很进入一段迷茫期。
在现有的技术与熟练度已经完全能满足现在的业务需求，公司给研发安排的内容都是占据预估好的时间。那么这个时候就是初级前端遇到的瓶颈期了。或者说这是任何一个阶段的研发都会遇到的一个瓶颈期。
减少无效的工作
什么样的工作是无效（没有效率）的？
- 重复的业务重新写
- 重复的功能反复写
例子1：登录业务
大部分活动 h5 都是需要开发新项目、新的代码，而很多业务都需要判断登录态，如果你也碰到这个问题可以尝试下面的解决方案
将所有的登录逻辑全部封装在 sdk 中，在开发新的活动的时候，可以将 sdk 直接通过 cd 引入，判断当前环境未登录的情况下，拉起登录界面，进行登录。
这里推荐同学用 Rollup 去开发一个 Library，比较方便。
例子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 用的比较多，windows 用 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 工程师。好好想想自己作为工程师的核心竞争力到底是什么？
当然要是一个框架能玩出花，能解决所有的业务问题，那也是相当牛逼，但实际情况这种框架或者人很少。
总之能解决业务的研发才是能赚钱的研发，能赚钱的研发才是好研发。可能这段话说出来会被打，但现实赚钱的确实都是老板，而不是一个开发。
另外无论是底层知识、算法、设计的多厉害，但是一定不要脱离业务基础。为了面试，很多同学会去刷题、刷算法，确实很有效果，但是最重要的要学会怎么将这些所有的知识体系运用到实际项目中去，让他能够发挥最大的价值。
技术深度相当于内功，肯定修炼的越深厚越好，但是一定要配合业务运用这层外家功夫，方能成为绝世高手。就好比郭靖一身高强的内力但还是需要降龙十八掌才能御敌。
生死看淡，不服就干
单干
如果你在一个小公司，小团队的时候，就没事多折腾折腾自己，有什么新技术就上，前提是：
- 有一定的心里预期，不成熟的技术坑会非常多，内外部都会有不少的压力
- 预留足够多的时间去试错，业务一定是保障第一位
- 要有一定的备案，如果在新的技术解决不掉问题的时候，能够快速拿出备案解决
- 一定不要在主要业务中使用，如果出现问题，会导致团队的信任危机，影响后期发展，不利于后期合作
- 要有开放的心态，新的技术运用起来不是优越感爆棚，解决问题的同时，可以分享给团队的每位想要了解同学
团队
如果你是在一个大公司，一个成熟的团队，那么能做的事情只会更多。
记住一个点，越大的团队，业务链路就越多，细节就越多，能下手的地方就更多，能拿到的资源也会更多。
所以要敢于承担责任与任务，在关键时刻顶住。
比如在新项目启动的时候要有足够的勇气主动去申请承担。前提条件是，你本身就要扛得住，值得信任，是一个可托付靠谱的人。
或者可以主动参与产品链路，与产品、研发、测试、运维、客服等等一系列与之相关的人员沟通，一起找到目前存在的痛点、难点，然后想办法去解决。
最好的办法是将你想做的事情，描述成他们想要的东西，然后他们可以借助你的资源来完成这件事，最后双赢局面出现，皆大欢喜。
写在最后
无论在哪都一样，做技术的切记心浮气躁，要耐得住寂寞，坐得了冷板凳。
推荐阅读
这里推荐一位朋友的博文，写的非常好。
