在一个公司中，前端工程师通常都扮演了一个非常重要的角色，他们去实现产品需求，实现各种交互效果，让需求能够最终落地。但是很多时候，产品和后端往往对需求和业务的理解更加透彻，决
在一个公司中，前端工程师通常都扮演了一个非常重要的角色，他们去实现产品需求，实现各种交互效果，让需求能够最终落地。
但是很多时候，产品和后端往往对需求和业务的理解更加透彻，决定权几乎都偏向他们，而作为前端，由于并不太能够有机会理解太多的业务数据和更深层次的用户痛点，这样就导致自身发展受限，话语权不够，积极性下降。
那么前端工程师该如何通过业务来更进一步实现自己的价值呢？
在这里，我主要从以下几个点来分析一下
技术架构
技术选型，预见未来，比如是否有跨端需求，提前选择跨端框架
可维护性、可复用性、可测试性
降本提效
目录自动生成，参考 egg.js（提效）
低代码运营页面自动搭建（提效降本）
快捷键工具
自动化测试工具
批量处理国际化（提效）
nodejs-translate
react-intl 以及 I18N-loader
业务场景
大文件批量断点续传及优化
微应用模板、组件库和脚手架（提交）
SSO 登录，CAS
异步流程控制
技术驱动业务
主动推进项目
和后端约定接口规范
推荐适合当前场景的技术
提出建设性的需求
样式：美观、统一
性能：首屏性能
交互&体验：简单高效
多端兼容
砍除不合理的需求
实现成本，可行性分析
替代方案
开发周期
需求优先级
开发排期
无论你想做什么事情，首先都要以开放积极的心态去面对，而不是打定了一个主意后就立马埋头苦干，在做之前先倾听其他人的意见，看看是否有更好的解决思路，或者是否已经有人做过类似的事情，不要重复造轮子。
作为前端，你可以提需求，也可以砍需求，也可以在对业务足够了解的情况下挑剔后端的接口设计（当然，还是要谦虚一点），但前提是一定要有足够的底气，而实际的数据和证据可以赋予你这个底气，比如文档或者视频，领导也比较喜欢你提供有力的证据，而不单单是一张嘴。
在绝大多数公司，一般都是由 PM 来主导产品研发流程，前端毕竟是开发人员，想要在产品层面上跟产品经理 battle，无异于是业余挑战专业，既不合适也没有胜算。
但并不意味着开发就完全无法参与到业务中去了，PM 对于整个产品的宏观把控肯定比你深，但在一些细节的实现上就不一定比一线开发人员清楚了，而细节往往是从具体的需求中体现出来，不可能在一开始就完全考虑到，这也是为什么会经常有需求变更和需求答疑环节。
当需求评审的时候，PM 更多地询问你的意见，当约定接口的时候，后端更习惯你来制定接口规则，当你关心的事情越来越多范围越来越大，这个时候，你还觉得自己只是个画页面的 CV 工程师吗？
总结
积极主动
多思考
多沟通
多参与
