当做了3-5年的前端工作以后，我感觉我和很多人都不可避免的感到了焦虑，并且认识到了一个事情，即自己陷入了一个瓶颈。而瓶颈的来源无外乎以下几点：

1.无法深入业务，也做不到反向推动业务

2.听说过架构，但不懂何为架构

3.不知道自己接下来的学习及发展方向

4.无法形成自己的竞争优势

5. .....

我接下来会从三个方面：业务、技术深度、闭环思维，去聊一下如何提升自己。

                                      深入业务

       我认为如果不去我们深入了解业务，而是去一昧的专精技术，那么我们的职业天花板将会来的很快。

        首先，我主观的认为在阅读这篇文章的大部分人应该不是在研究院进行技术研究的学者专家，而是一些在应聘公司上班的在职员工。业务是在土壤中开花结果的植株，而技术这是提供给这株植株良好发育的土壤，它只是一个工具，如果没有业务，那么一抔泥土将变得毫无意义，因为任何好的技术都需要通过业务去施展出来。首先，你得意识到我们去完成一个需求或者一个项目都是为了解决一个明确的问题或者痛点，只是为了提高技术而去使用技术，但却达不成预期的结果那么这只是存粹的浪费时间而已，因为用户不会关心背后的技术实现，只会在意呈现到他们眼前的东西。并且现在市面上有五花八门的技术、前端库以及开发工具，等工作久以后你就会发现，如果没有深入了解业务的去开发，结合实际场景的去盲目选择，后期的维护开发成本都会急剧变高。

  其次，这段思考适合已经有工作多年的前端开发工程师，有一句非常鸡汤的话流行在我们的行业里，“前端是离用户最接近的岗位与工作”。但是只要有一定工作经验的人，都会发现往往离业务有最深关联的是在服务端，而我们前端往往对业务的了解只停留在表面。

  这是因为其实即使没有前端，服务端也是可以直接和用户直接交互的，因为只要服务端提供接口，只要用户录入对应的参数调用其接口就能完成对应逻辑的数据调整。只是这样子的交互过程，对用户的使用成本，所以慢慢出现了前端，前端及移动端的出现就是为了降低用户的使用成本，提高用户的使用体验，所以这也是为什么往往为什么接口和页面是一对多的情况，因为最核心的业务逻辑其实已经封装在接口中，而前端只是为了满足在不同场景去调用它罢了。

  在了解到以上两点之后，我们去了解一下应该如何去深入业务。我认为有两个步骤：

       首先是思考上的转变，学会换位思考，拔高自己的思想层次。比如我们不去以员工的角度，而是以老板的角度去对待项目，那么你思考的问题就变得更多。首先，你得知道你公司的商品（手中的项目）是到底用来做什么到底要怎么来盈利，因为你连它的完整形态都没有认知，你拿什么去和别人销售它或者推广它。那么这就会促使你去关注它的每个功能每个需求如何实现，能不能确切的解决痛点，思考该实现方案是不是最优解，当你在一个需求评审的会议中开始提出你的思考和方案的时候，你在这个项目中的参与度就会变得更高，甚至去主导一些方案和迭代。你也会去开始关注项目上线后的使用情况，哪个页面或者按钮或者功能使用量很低，到底是设计的交互链路不人性还是这其实根本是一个伪需求。

       其次是开始主动发现问题，你常常在面试中听到的一句话就是，“你有没有曾反向推动过业务？”。首先推动的前提一定是你发现了现在的项目有这样那样确实存在的问题，这就需要上面说的进行思考上的转变，你可以从用户的角度出发你会发现页面的渲染很慢秒开率很低，那么就会进行各种各样的性能优化。你也可以从开发的角度出发，发现公司某些项目和服务可以集成你的项目，可以是前端通过iframe，也可以是通过服务端改造，在这个过程你就要学会主动去和产品沟通，去和服务端进行技术评审、进行一些技术的改造后提高项目使用的数据量。也可以从产品经理的角度开发，你无法收集项目中的用户交互数据，那么主动提出一个埋点交互系统方案，在有一个案例后甚至是做成一个通用的方案服务于公司其余业务。

                                    提高技术深度

       技术深度的前提一定是你的技术基础足够扎实，包括计算机基础、网络协议、算法思维、设计模型、框架思想等等，这就和地基一样，没有地基的房子就会格外的脆弱不堪，基础不扎实会导致你的后续学习事倍功半，这个在从业多年会慢慢体现出来。

       就像前面所说的，现在的行业技术五花八门，每天都有新的技术或者新的文章产出，等你打好地基以后，你才有能力去甄别什么样的技术是目前的你需要的或者去了解的。

       首先，要关注一些行业潮流以及咨询，你可以通过去订阅一些前端或者更大范围的技术杂志《Fronted Weekly》或者大厂的一些技术微博等方式。

       比如我随便挑选几篇文章举例：

        《Prettier 2.5: TypeScript 4.5 and MDX v2 comment syntax!》

           讲的是与TS相结合的代码风格编排工具，如果你刚好在做公司内部的前端代码规范的工作可以阅读，否则也可以跳过。

        《Remix: A Newly Open Sourced React-Based Framework for Web Apps》 

          这个讲的是一种新开源的基于React的web app框架，如果你在仔细关注react相关的生态，可以浏览，不然可能对你用处不大。

       其次，去专精一些有需求场景的技术，为什么说需要有需求场景，就像我上面说的，只有解决痛点的技术才不会成为无垠之花，就比如你想做富文本的开发，或者项目的秒开率优化，让某某项目的网页的白屏时间从1s优化到了0.5s，因为项目是你技术的载体，只有能拿得出具体数据及案例的技术才是有价值的，才能被别人认可。而具体的实践则是可以通过和公司里的其他感兴趣的小伙伴组成一个技术team，或者在部门会议中说出自己的想法拉壮丁等等，然后制定具体的计划分工以及时间节点去完成，最后尽量进行经验总结，把技术沉淀出来形成自己的竞争优势。

                                     形成闭环思维

         我常常听到一个词就是架构，很多人想成为架构师又不知道该如何成为。我对架构的理解就是——对一个系统的抽象描述指导。

        什么是系统，前端有很多复杂的系统，比如发布系统，比如埋点及数据上报系统，比如工作流系统等等。而我们需要努力攻克的系统，往往都是像这些包含着复杂模块划分，涉及到的知识点非常多的这么一个闭环集合。

        什么是抽象描述，首先你需要一个自上而下的角度去俯瞰整个系统的构成，有更高更广的视野，把他们从各种各样的具体的技术实现转化为一个是抽取出共同的、本质性的特征，通过抽象可以让你不会局限于用某种工具、某种框架甚至是某种语言去实现功能，然后清晰的模块区分会使你在真实开发中条理更加清晰。

        当然，很多人可能一直没有机会去深入参与开发这样一个大型系统，但是你可以通过去网上、或者公司内部获取相关的架构图获取相关资源，理解每一个抽象层所表达的意义和大概实践原理，这就像在大脑里拼拼图，把每一块空的版块进行填充，直到形成一个完整的闭环。然后对于每一块内容的具体技术实现就是给拼图上色，因为总体的一个框架已经有了，你是会有大概思路的，当然每一个具体的技术细节其实都是值得深挖的。

        我一直提到了闭环，我认为一个好的架构思想应该是完整的，不单单是单个架构的理解，而是可以从单个架构中进行延伸，举一反三。

       在本文中几乎没有涉及到任何代码，但是我却觉得这对一部分人非常重要，我觉得遇到瓶颈是好事情，起码你知道自己在停滞不前，都渴望达到下一个阶段，而大家都常常因为被繁重的业务麻木了大脑，停止了“思考”。永远不要停止思考，有时候停下来想一想接下来的方向再去做，接下来的路会走的更好，你我共勉。