简单讲下背景
笔者从事前端4年，一直在郑州几家中小企业做前端工作，整个研发团队最大不到20人。且先后换了三家公司，先天条件可谓极差。
但后来历经三个部门14轮面试成功进入阿里（体检阿姨说第一次见阿里巴巴，似乎之前还没有本土前端直接进阿里的）。
我是怎么弥补先天不足的
自驱动和勇于挑战是主要。我虽然跳了三家公司但在每家都主动担任负责的角色并做出了成绩，且在没有任何人要求和给时间的情况下自发做了很多额外的又能给公司带来益处的事儿。
开源和文章是亮点。我从18年中接触开源到现在维护了近10个项目，累计star千余，下载量近10万。各博客平台的原创文章累计阅读10万+。
这为我积累了非常多的好机会。
恶劣的条件下如何重塑自我
首先要有明确的概念
在我们这里，90%以上的前端或公司不会去讨论大厂，甚至连讽刺和趣事都不会多看两眼(估计因为不用脉脉)，仿佛是比清华北大更虚幻的两个世界。但是随着前端行业的整体提升，这里也开始有些许前端通过博客平台和github能和社会接上轨，打开闭关锁国的局面。当我们认知到有大厂存在和进入大厂的要求和途径后，我们就可以往这个方向上去准备。
有自我追求极致的心态
我曾在一份工作需求中，面对功能实现极为复杂且位于世界范围内前列的产品供应商敢于亮剑，在借助它们的产品耗时一个月开发完一个功能(极小众需求、国外产品、破解版未提供文档、国外论坛资料都极少)后，自己因为不满意其在当时环境的表现，花了周末一天半的时间从0开发出来一个从易用美观扩展性强上手快等方面上表现优异的重制版。
自发的想要做出好的东西，比业务完成能跑就行更能提升自己。
有真的想做就无惧困难不找借口的三观
在另一份工作中，有位同事说不想写业务了，想做啥啥啥。
我说如果你真的想做的话应该已经做出来了，因为除了我们都要做的日常业务开发之外，我还需要去协调前后端的工作进度，和硬件团队对接，向客户的宣讲等，我的空余时间比你要少许多。但是在没有任何人要求我做也没有专门分配时间来做的情况下，把公司从前后端未分离（2020.1，也就是去年）的比较落后的情况，转为当时比较前沿的微前端架构，并且梳理工程结构，编写脚手架，制定微前端的nginx方案和docker方案，编写多个辅助微前端开发的脚本，制作多种工具，形成了较完整的微前端开发闭环，抹平了小团队微前端开发模式的上手成本和工作成本。让团队提效了，公司也得以小团队实现多条业务线并行。(具体微前端是啥有兴趣的可以了解一下，到今天这个话题在博客平台依旧挺火的)。
当你想做或者认为该做的时候就去做，环境总不是为我们而存在，如果你有意识自己做开拓者，未来必定会长远许多。
开眼看世界拒绝闭环锁国
按照上面的心态和三观积累一段时间，你应该有了自己的自主知识产权内容，有了自己的内容就有交流的需求(大厂这点感受明显，不会有曲高和寡的尴尬，大有坐而论道之势)，多写文章，再搞搞开源，这是我们在地域限制之下最好的突破口。
和外界接轨，接收当下主流知识，有条件再顺着某些前沿知识一探究竟，假如你天天和清华生有来有回的交流，你还会觉得清华远不可及吗。
能从业务实现中脱离出来从上层往下看
首先大家有一点共识：学了总不用等于白学。这也是小城市前端进阶的一大牢笼。且日常业务谈不上多大难度，技术能力和经验易被取代，前景更是蒙上一层阴翳，也难怪许多人会有搬砖无意义或前端无用论。但小城市目前前端环境如此，需要我们自己破局。
简单猜想非一线城市80%的公司应该都是中小企业，公司不重视代码质量是常态但一定会重视开发效率。所以提效是我们能接触到并能实践的进阶最佳道路。而我们普通前端能有效践行的提效方向不外乎工具，抽象，基建，脚本，Mock，构建工具，ide插件，CICD，优化几个点
我在阿里干了啥
进入阿里之后我发现即便在这里依旧有许多抽象的需求存在。
我曾在第三周向老板提问，如何在日常繁忙的业务工作中实现业务模型的抽象和下沉，得到的回答是当我们拿到一个需求，把它实现出来只是最基本最基本的素质，甚至我理解这不是60分而是0分，除此之外我们要思考和解决的东西才是真正得分的开始，而这部分做的越少、越晚，未来背负的债就越大。
于是我一直从践行这一思想出发，在刚入职的前两个月完成的四个需求中便积累出来一个业务占比在一半以上的功能容器(使相关业务常规功能部分工作量降低了77%)和参与重新梳理并实现了某个复杂组件协议的重构(使相关业务工时由一周缩短为一天)。且这两个积累都是在日常工作排期之外创造条件完成的，其后也将这两项内容在整个大团队作为后续的标准推行。
所以一个人不是说只有搞定越难的越厉害，能在看似合理平常中找到有效革新才是大多数人能够在日常中践行的。
当一个业务需要写第二遍的时候，我就会去考虑将其抽离出来做封装而不是去做简单Ctrl c Ctrl v。得益于我从19年底开始就做微前端到21年初，对于模块复用从认知的层面上可能就无形的被扩大了很多，当我们说模块封装的时候，我可能想的不单单是某个原子组件，某块功能的封装，也可以是整个业务流程的封装。比如说我做OA系统的时候我会直接做一个表单生成器+表单解析器+前端工作流平台，这样整个OA审批流业务都抽象出来了。再比如稍微大点的公司或者业务线较多的，可能会有大家比较熟悉的单点登录系统，其实就是把认证中心抽离出来，给其他各系统同步身份信息，让用户有更好的登录体验。其实微前端-微应用的思想简单来说（并不是很恰当）只是把类似的思想进一步的在业务范围扩大，将一个巨无霸应用的整个组成部分抽象出来封装，比如整个OA系统，登录系统，订单系统，工作流等。因此封装的概念不会局限于所谓组件本身，需要的话一个重复的功能，一段重复的业务，一条重复的流程，一个完整的系统都可以从封装的思路把它抽象出来，一个是缩小了无意义的代码量，一个是减少了不必要的重复劳作，也统一了行为一致性。
在阿里的感受&广告
简单来说，队友强，专业，有大腿，氛围像大片，节奏感爆炸。这样的队伍开一局只有一个体验∶酣畅。
福利，保障更是小地方的我生平仅见。
给自己的团队打个广告，前端和java一直比较缺，另外阿里业务广泛很多行业都有岗位，欢迎各位优秀的小伙伴快快到碗里来~~~
今天是转正的第一天，下半场继续挥洒吧，少年～
