最终目标：学习技术与业务，两者相辅相成
如果没有做业务的主动意识，而是被业务方赶着走，这种行为就是搬砖，反之，如果是主动推着业务走，让业务方因你而改变，那么就是你赋能了业务。
1、拓展壁垒
技术这条路可以很宽广，但对于绝大多数人绝大多数场景来说，能够被实际使用到的技术只是一小部分，特别是前端，相比于后端、算法来说，技术含量较低，更倾向于技术的广度而非深度
可能从业三五年的C++程序员都还会写出有语法错误的C++代码来，但在前端很难发生这种事情，稍微勤快点的应届生毕业半年就不该再写有语法错误的前端代码了，有bug基本上也都是业务逻辑bug，一个五年工作经验的C++程序员和一个只有一年工作经验的C++程序员，他们的技术水平可能有着本质上的差距，但如果换成前端程序员，很可能两人的技术水平就是差不了多少了
但是很显然，就算是前端程序员，一般情况下还是会认为五年工作经验的会比一年工作经验的能力更强，技术水平可能二者差不了多少，差的是其他方面。
真正好的工作经验应当是持续学习与进步的，不仅限于技术上的进步，如何写好易于维护的代码、如何用技术能力保障业务的稳定性、如何引领新人快速融入团队，都是不可或缺的东西，想要获得这些能力，需要时间，但更需要你的主动探索与实践，而这些是无法速成的东西，也是你作为一个技术老鸟，能跟应届生真正拉开差距的地方
2、什么是业务
在绝大部分情况下，技术都是要为业务提供服务的，这句话蕴含着两层意思
第一，技术的唯一目的就是支撑业务
第二，业务并不仅由技术支撑，还包含了其他很多方面
业务是一个商业公司的命脉所在，而技术只是支撑业务的关键之一，所以业务真的很重要。
技术所服务的就是业务，而你能够让业务蓬勃发展的一切正向能力（包括但不仅限于技术能力），都是业务能力
3、前端如何参与业务？
在绝大多数公司，一般都是由pm来主导产品，前端毕竟是开发人员，想要在产品层面上跟产品经理 battle，无异于是业余挑战专业，既不合适也没有胜算，但并不意味着开发就完全无法参与到业务中去了，pm对于整个产品的宏观全貌肯定把握得比你深，但在一些细节的部分就不一定比一线实际开发人员清楚了，而细节往往是从具体的需求中体现的
需求一般是由产品提出的，但需求往往需要开发来实现，而产品提需求的目的是为了实现这个需求，侧重于产品层面，目的性较强，开发层面的事情还需要开发来评估，那么这个gap天然就是开发参与业务的机会
3.1 提需求
提需求并不完全是pm的特权，作为开发同样可以提需求，业务需求或许不是那么容易就能提出的，但是技术需求却是你作为开发人员的专利
作为前端，肯定是要关心自己所做前端页面的一系列的指标的，主要围绕性能、交互与风格样式这三个方面，页面加载快不快、交互是否流畅、风格是否舒适统一，都是需要时刻关注的点，出了问题你就要去主动解决它，而不是等pm来找你，这是技术上的事情，该由你来负责
所以你可以光明正大地提技术优化需求，不敢保证一个流畅的页面会让用户忠诚度更高，但一个糟糕的页面肯定会让用户流失的（除非你是银行网站），所以技术需求表面上是技术需求，实际上也是为了业务考虑需求可大可小，小的如样式风格统一，大的则可以建立一个前端技术项目.
例如，产品希望通过持续的运营活动迭代来维持用户活跃度，那么他想要的就只是开发人员能够按时完成运营页面的上线，至于开发怎么去做这件事他不关心，只要达到产品目的就行
那么作为前端开发，你意识到运营页面可以做成可配置化的形态，所以就需要你去跟pm进行商讨，例如这种做法是否可行、配置后台做成什么样、需要预置哪些模板、需要预置哪些页面能力、数据存储的形态等
再进一步，你还可以继续跟产品确认，这这些运营活动将来是否可能会在多端铺开，如果是，那么你就还需要考虑多端兼容的问题了
看起来，本来一个简单的运营活动，没啥难度也没啥工作量，应届生一天就搞完了，然后你作为开发参与进去，硬是把这个需求拆成了好几个大项目，好像是自己没事给自己找事
确实，有些人就擅长无中生有，整天搞些看起来高大上实际上屁用没有的东西，但也别一棍子打死一群人，无中生有并不一定是贬义词，如果运营搭建后台和多端适配确实是有需求的，那么这件事情早晚得要做，而你能提前看到这一点并且提前做好准备，为业务的平滑过渡提供了保障，这就体现出了你工作经验的价值
3.2 砍需求
pm提出的需求并不一定就是合理的，一个负责的技术人员对于需求应当有一定的判断力，对于不合理的需求要坚决说不
这里的意思并不是让你去鸡蛋里挑骨头给pm的工作制造人为障碍，相反的，而是给出更好的见解，共同为业务负责
比如，你事先和产品约定好了一套解决方案，在某个具体的功能上，产品发现数据不达预期，于是想要你专门为这个功能开发一个特定的逻辑以提升数据，这件事情可能确实可以做，并且技术上也不难实现，但作为开发人员你还要为整体的技术方案负责，约定好了的方案，为了某个特定的功能添加额外的逻辑，会不会对整个技术方案造成破坏？会不会因小失大产生长远的负面影响？还有没有其他更好的解决方式？
如果你的出发点确实是为项目考虑，并且理由足够让人信服的话，能够有理有据地阻止不合理的需求，将有限的人力、时间花费在更重要的需求上，才能更好更快地推进业务。
4、如何平衡技术与业务的关系？
对于前端这一行来说，前两到三年，更多的精力（最起码80%以上吧）投入到技术上面，保证在两到三年内在前端技术层面，能够达到合格的状态
\
5、什么是合格的状态？
网上正常场景下的任意前端面试题，你有80%以上的把握能答出来，可以实现工作上提出来的任意前端需求，能够保证自己所写代码项目的稳定性和可扩展性，前端领域新出现的技术你都能快速上手并且理解其原理。
然后，剩下的20%用来关注业务，注意是关注业务，至于参不参与不太重要，因为两年工作经验之内的菜鸟，在业务上是没有多少话语权的，并且思考方式还不成熟，这个阶段更多地是观察，观察业务是如何运转的，观察其他更高级别的人是如何参与业务的，学习他们身上的优点，进而形成自己的思考观念。
两到三年后，你再开始尝试着去参与业务，将自己在前两年学到的、总结下来的技巧和观念，真正地运用到业务中去
6、不要闭门造车
首先都要以开放的心态去面对，而不是打定了一个主意后就立马埋头苦干，在做之前先倾听其他人的意见，看看是否有更好的解决思路。比如，你想做一个前端错误监控系统，你可能从网上查了详细丰富的关于前端错误监控的资料，然后觉得信心满满可以开干了，然后你自己一个人起早贪黑默默干了几个月，终于弄出了一个像样的项目，这个时候你拿出来准备一鸣惊人的时候，结果你leader却满脸诧异地跟你说你难道不知道有Sentry这个东西吗？
或者你在网上查找前端错误监控资料的时候，无意间发现了 Sentry，于是决定自己先上手熟悉一遍，弄清楚了所有开发部署流程之后，拿出来准备干一票大的，结果你leader满脸诧异地跟你说你难道不知道隔壁部门前段时间就已经基于 Sentry 搞出了一套适用于咱们公司的监控系统了吗？
所以，一定要多跟外界进行交流，一方面是为了能从外界获取更多的信息，另外一方面则是让其他人知道你在做什么事情。
7、用数据说话
作为前端，你可以提需求，也可以砍需求，但前提是一定要有足够的底气，而实际的数据可以赋予你这个底气。你要提一个性能优化的技术需求，需要好几天的时间，如果你只是说前端性能不好需要几天优化一下，这显然无法说服担心项目进度被延误了的pm，但是如果你能拿出实际的数据，例如，现在网站加载需要多长时间、发起多少个http请求、代码体积多大、FP/FMP/TTI都是多少、低于行业标准多少距离、可能会对业务造成什么样的影响，然后优化后又能达到什么样的效果，有理有据地摆好数据后，pm只要是个正常人，肯定会认真考虑一下你的建议的，即坚持以理服人。
8、良好的心态
不同于技术的纯粹，业务上的事情肯定跟人有关，跟人有关的事情肯定就会有磨合的过程，在推进一项业务发展的过程中，肯定会遇到很多有意无意的阻力，这可能会让抱着一番好心努力做事的你感到憋屈，觉得自己一番好心不被认同，还不如每天划划水算了，这不仅是对工作不负责，更重要的是，对你自己不负责，所以端正态度。
业务基本是都由团队推进，几乎不存在个人单打独斗的可能，团队中的每个人都有自己的长处，每个人的长处汇聚到一起，才成就了团队的战斗力，能够顺利地推动团队融合与发力，可能比你攻克了一个技术项目还要重要的多。与同事心平气和地讲事实摆道理。
