你是否头痛于，每天做不完的需求、改不完的bug、背不完的锅。

        你是否头痛于，没有时间，没有精力，没有方向进行自我提升。

        你是否有猜想过，自己的代码经历了时间变迁，业务变革，反复锤炼之后成为业务腾飞的基石，而现实是变成历史遗留，任人嘲笑，在反复迭代之后无影无踪。

        无论小、中、大厂，90%的前端业务都是非常简单，只需要学习编程1到两年的人即可熟练上手的。从业内的职业划分的角度来看，前端的职业天花板也比较低，页面开发3到5个月的培训即可，没有后端的高并发、大流量、持久化等稳定性考虑，也没有大数据方向的数据挖掘、算法应用的专业深度。

        结论就是：前端开发并不是核心岗位，全文完。

        大雾，先不要喷，作者还有话要讲。

        前端的出路在哪，用一个词来形容的话，就是赋能。

        很多文章讲的很大很空，要搞组件库、平台建设，做业务中台等等等等，压根就不考虑996、007的人哪来的幺蛾子时间做这些东西。还有些直接就把软件工程的标准甩出来，什么代码质量、鲁棒性、项目架构一套一套的。都是废话哈，我跟你讲。要突破目前境况的第一件事就是让自己不那么忙。

        第一步，要分析自己忙碌的原因。一般来讲都是需求多，其他情况你就看着办，毕竟这里要说的是普遍情况。这里再加几个前提：

赶着上线、需求很多、天天加班。解决的方法就是谈（kan）需求。先端正一下心态，这个不是为了让你摸鱼用的，而是确实有效的方法论。

        谈需求需要提前分析以下几点，不熟悉的话就按着下面的步骤来套：

        1、需求细分到点，涉及到什么模块，模块里有什么功能被影响，修改的量级由轻微到完全重写之间处于哪一步，每一步需要经过开发、测试、预留扩展性的时间。

        2、逻辑性，包括系统逻辑、驱动逻辑、功能逻辑，从市面通用和人机交互的角度去分析需求的合理程度，需要纠正的地方。

        3、变更记录（日志），变更导致的需求蔓延，变更的有效性（人家口头说的不能为准，尽可能要有书面证明，否则出事了你就是背锅侠，切记切记）

        谈的时候按下面的流程来走：

        1、优先级，核心 or bug修复大于普通需求，把不那么重要的事情往后挪，那些人家都不看重的事你加班做给谁看呢。

        2、开发工期，如果工期是让产品或老板来定就输了，不是你输，是这个项目已经输了。专业的事让专业的人负责，这点要切记切记，你是开发，你才是项目完成的保障，没有这个底气来定工期，早点转行吧。

        3、加/改需求，沿用1、2点的步骤，把它作为新需求来看待，而且要按照正式流程来走，再说一次口头改需求不算数的哈。

        熟悉了上面的步骤之后，有些同学学会了举一反三：根据项目内容、产品数据、市场情况反推需求，从接需求到影响需求到自行发布需求，也符合了那句人人都是产品经理。

        这时候你就不再是个单纯的前端开发，你拥有了普通开发没有的业务能力、产品思维，这是第一步赋能。同时你还可以更灵活地安排时间了。这时候你就可以往这几个方向去发展：

        1、提高开发效率，不仅仅是前端的，包括但不限于组件库、开发脚手架、平台化、扩展到各个端（PC、移动）等等，现在网上关于这些的东西太多了，我就不细说了。

        2、深入业务，结合你的优势去拓展业务，这个需要你去深入了解公司的业务、盈利模式等事业环境因素、组织过程资产的内容，把业务链路拓展到上下游，附加的产出有大数据可视化、业务中台。像业务中台，很多情况下属于后端的项目，前端将其挖过来要符合以下两种条件，要么自己有后端技术能力承载，这个比较少见，但不是没有；另一种是使用自己丰富的产品经验，将自己代入到产品的位置去做这个事情，这样一来可以名正言顺地申请资源进行项目。

        3、深入技术，这个需要结合公司的业务，作者之前待过的一家公司是开发K歌一体机的，将系统迁移到web平台之后出现了严重的性能问题，需要针对底层的渲染引擎做特殊处理，这里就涉及到一些前端平时不大有机会接触的内容，比如OpenGL编程、比如嵌入式编程等等。掌握了这些核心工作的你在老板眼里就是最靓的仔。

        看到这里点个赞如何？