前端工程师如何通过业务提升自我价值？

在一个公司中，前端工程师通常都扮演了一个非常重要的角色，他们去实现产品需求，实现各种交互效果，让需求能够最终落地。

但是很多时候，产品和后端往往对需求和业务的理解更加透彻，决定权几乎都偏向他们，而作为前端，由于并不太能够有机会理解太多的业务数据和更深层次的用户痛点，这样就导致自身发展受限，话语权不够，积极性下降。

那么前端工程师该如何通过业务来更进一步实现自己的价值呢？

在这里，我主要从以下几个点来分析一下

技术架构

• 技术选型，预见未来，比如是否有跨端需求，提前选择跨端框架
• 可维护性、可复用性、可测试性

降本提效

• 目录自动生成，参考 egg.js（提效）
• 低代码运营页面自动搭建（提效降本）
• 快捷键工具
• 自动化测试工具
• 批量处理国际化（提效）
  • nodejs-translate
  • react-intl 以及 I18N-loader

业务场景

• 大文件批量断点续传及优化
• 微应用模板、组件库和脚手架（提交）
• SSO 登录，CAS
• 异步流程控制

技术驱动业务

• 主动推进项目
  • 和后端约定接口规范
  • 推荐适合当前场景的技术
• 提出建设性的需求
  • 样式：美观、统一
  • 性能：首屏性能
  • 交互&体验：简单高效
  • 多端兼容
• 砍除不合理的需求
  • 实现成本，可行性分析
  • 替代方案
• 开发周期
  • 需求优先级
  • 开发排期

无论你想做什么事情，首先都要以开放积极的心态去面对，而不是打定了一个主意后就立马埋头苦干，在做之前先倾听其他人的意见，看看是否有更好的解决思路，或者是否已经有人做过类似的事情，不要重复造轮子。

作为前端，你可以提需求，也可以砍需求，也可以在对业务足够了解的情况下挑剔后端的接口设计（当然，还是要谦虚一点），但前提是一定要有足够的底气，而实际的数据和证据可以赋予你这个底气，比如文档或者视频，领导也比较喜欢你提供有力的证据，而不单单是一张嘴。

在绝大多数公司，一般都是由 PM 来主导产品研发流程，前端毕竟是开发人员，想要在产品层面上跟产品经理 battle，无异于是业余挑战专业，既不合适也没有胜算。

但并不意味着开发就完全无法参与到业务中去了，PM 对于整个产品的宏观把控肯定比你深，但在一些细节的实现上就不一定比一线开发人员清楚了，而细节往往是从具体的需求中体现出来，不可能在一开始就完全考虑到，这也是为什么会经常有需求变更和需求答疑环节。

当需求评审的时候，PM 更多地询问你的意见，当约定接口的时候，后端更习惯你来制定接口规则，当你关心的事情越来越多范围越来越大，这个时候，你还觉得自己只是个画页面的 CV 工程师吗？

总结

• 积极主动
• 多思考
• 多沟通
• 多参与