总结起来就几个字吧：“为研发提效，为业务赋能”

为研发提效

具体也可以分为两个方面：

第一，一个项目的诞生到迭代完善以及后续维护需要各个环节的人员各司其职，这样才能做到效率最高

第二，成为一个领域的熟练工是对项目和其他人员最大的帮忙

很多人都说后端比前端更加贴近业务，理论上似乎是这样，但我的看法是，具体到个人的话，还是要看你自己的态度，如果后端只是日复一日地CRUD，既不主动了解业务，也不赋能业务，再贴近业务又有什么用？同样的，前端如果只是甘心于当切图仔，哪怕每个需求pm都专门给你讲得清清楚楚也没用

所以还是要看个人的主观能动性，在技术之外，要主动去看更多的东西，我不是让你去一行行看后端代码，当然，你有时间看也可以，只是没必要，业务代码没什么好看的，反而看得脑壳疼，业务由一个个需求迭代而来，那么想了解业务就从需求着手

pm提了一个需求，你不仅要关心前端需要切哪些图片做个什么样式使用什么组件等技术问题，还要弄明白pm为什么提做个需求，这个需求解决了什么问题，涉及到的上下游关系等业务层面的事情

跟后端约定接口字段，不仅仅是盯着后端给你返回所需的字段就行了，还要多考虑一些，例如，接口是否有可复用性、字段是否冗余、有没有必要做接口的拆分或整合、前端如何保证接口出错的情况下页面仍旧是可被用户接受的？有些可能应该是后端应该做的，但你不能保证所有人都尽职尽责，那么你就可以多关心一些事情

当需求评审的时候，pm更多地询问你的意见，当约定接口的时候，后端更习惯你来制定接口规则，当你关心的事情越来越多范围越来越大，这个时候，你还觉得前端只是切图仔吗？

如果你成了最熟悉业务的人，那么团队中其他成员遇到不理解的业务问题，第一个想到的肯定是你，那么你在这个团队中就有了具有实质性存在的价值，而且是不容易被替换的那种，也成为了最有效率的一个前端

为业务赋能

具体可以从两个方面展开讲 第一，技术的唯一目的就是支撑业务

第二，业务并不仅由技术支撑，还包含了其他很多方面

业务是一个商业公司的命脉所在，而技术只是支撑业务的关键之一，所以业务真的很重要 那么，什么是业务其实也就很好理解了，你的技术所服务的就是业务，而你能够让业务蓬勃发展的一切正向能力（包括但不仅限于技术能力），都是业务能力

怎么做是为业务赋能？

从工作的具体方面举例：

运营页面自动搭建

运营手段对于C端产品来说是很重要的，运营迭代的速度也是影响产品发展最直接但也是最实用的关键因素之一，比如天猫618盖楼活动，美团的满减活动等，这些都是很常见的运营手段，几乎任何直面C端用户的产品都少不了这些 而这些运营活动往往是少不了各种各样前端层面的用户玩法，可以说是比较依赖前端的一个业务了，那么作为一名前端开发工程师，如果你的目标只是实现业务方提过来的具体的运营需求，当然也算是合格了，毕竟是完成了自己职责，但可能还不够

来一个运营页面你就做一个运营页面，来两个你就上两次线，难度倒是没什么难度，就是避免不了要走一遍整套开发流程，于是聪明的人就想到，是否可以把这种固定路径搬砖的行为自动化，于是运营页面自动搭建的概念就出来了，以后运营页面的开发与上线都不需要研发参与了，直接让运营来搞定，又快又稳又好，以前一个运营活动需要评审、排期、开发、验收、上线等多个流程，现在简化到只有验收和上线两个节点，极大地提高了生产力，这就是对业务的成功赋能 那么你能做什么呢？

业内知名的运营页面自动搭建项目有很多，例如阿里云凤蝶、阿里飞冰等，但是这些不一定完全适合你的公司，因为运营页面跟具体业务是强相关的，特比是C端，业务场景不同，运营页面自然不可能一样，如果你公司并没有这么一套运营页面自动搭建的工具，并且业务上又高度依赖于线上运营，那么这就是你的机会

adapter

移动端已成为主流，前端开发主要聚焦于app、m、小程序三端，而小程序端又可以细分为微信小程序、字节小程序、百度小程序、支付宝小程序、快应用等，如果为这些端每一个都专门开发一套代码，显然会对人力产生较大的需求，如果这么多端全做了的效果是 1+1等于2，那还算能说得过去，但现实情况肯定是1+1小于2的，如何能以最小的成本覆盖那么多渠道，就是一件很迫切的事情了

于是，多端适配的解决方案出现了，它极大地提升了开发效率，不仅又快又好地完成了一套代码多处运行这件事，同时还间接地为公司节约了一大笔研发费用，价值毋庸置疑 那么你能做什么呢？

类似于Taro这种多端适配框架，确实适配了很多东西，但适配的都是开放的东西，例如微信小程序、字节小程序、ReactNative等，这些都是对外开放的开发平台，但是你公司自己开发的app，例如抖音app、支付宝app，肯定有自己私有的一些协议，比如唤起app、打开页面、调起拍照功能等，这些私有协议一般是不对外开放的，如果你不仅想让一份代码运行在小程序、m端，还想让这份代码也能在app端正常运行，那么适配app这部分的能力，显然需要公司内部员工来完成

组件库

哪怕是在前端刀工火种的时代，Bootstrap 这类前端框架就已经大行其道，到现在前端组件化大行其道，各类前端组件库层出不穷，本质上都是为了提升开发效率，一些通用的UI与逻辑拿来即用，作为开发者只需要专心业务逻辑即可 但也并不是说 iview、ant-design这些组件库就可以横行无忌了，pc后台项目还好，但如果是移动端C端的产品，对于组件库的选择就需要谨慎很多了，特别是那些知名度较高或者场景较为鲜明的产品，对于风格的要求比较高，被广泛使用的开源组件库并不一定能满足要求，比如，支付宝和微信显然都有自己独特的UI风格，开源组件库不可能专门去适配某一个产品的风格，否则就失去了通用性，而支付宝或微信这类具体的app也不可能为了省事就放弃自己的风格直接用开源组件库，所以打造专属于自己的组件库就成了一件很明显的事情

实际上用户量稍微多点的C端产品，对于专属组件库都是存在需求的，所以如果你所在公司业务场景主要在移动端，而且你发现还没有专属于公司内部的组件库，那么不要犹豫，马上放手去做，这么明显的事情你不做，早晚有人做 其他的还有很多，例如脚手架、国际化、工具函数库等，都是一些有实际需求的东西