在前三年，经常有资历更高的同事跟我提起业务这个词，听得多了，我有时候也想去了解它，但总是发现这个东西太虚无缥缈了，编程语言的语法、关键字、设计模式、算法我都可以实实在在地看到并运用，但业务到底是什么？我怎么学？我又该怎么去关注业务？
总之很苦恼，老是有人跟我说业务，但我却无从下手，硬着头皮去模仿，最终也只是学了个皮毛，于是逐渐放弃
目前在第二家公司入职的团队，相比于之前来说，业务压力大很多，几乎没法再像之前那样优哉游哉地搞自己的技术研究，然而在这种环境下，反而加速提升了我对于业务的理解，也明白了为什么之前那么多人跟我说业务很重要，但没有一个人能教会我到底什么是业务，因为这个东西真的很难说清楚，或者换句话说，其实每天都有人跟你说什么是业务，但因为你自己本身无法领悟，所以你觉得他们什么都没说
在绝大部分情况下，技术都是要为业务提供服务的，这句话蕴含着两层意思
第一，技术的唯一目的就是支撑业务
第二，业务并不仅由技术支撑，还包含了其他很多方面
业务是一个商业公司的命脉所在，而技术只是支撑业务的关键之一，所以业务真的很重要
那么，什么是业务其实也就很好理解了，你的技术所服务的就是业务，而你能够让业务蓬勃发展的一切正向能力（包括但不仅限于技术能力），都是业务能力
前端如何赋能业务
肯定有人会吐槽我说了半天还是啥都没说，没错，确实是这样，对始终不明白业务是什么的人来说，别人说得再多也很难理解，对于已经理解的人来说，业务就是业务，根本没什么可说的，可能真的就需要你自己领悟才行，或许某一天你自己就突然明白过来了
很难说清楚业务这个词到底是什么，但工作中处处是业务
前端如何赋能业务的话题比较大，但具体的例子却很多
运营页面自动搭建
运营手段对于 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 端产品，对于专属组件库都是存在需求的，所以如果你所在公司业务场景主要在移动端，而且你发现还没有专属于公司内部的组件库，那么不要犹豫，马上放手去做，这么明显的事情你不做，早晚有人做
其他的还有很多，例如脚手架、国际化、工具函数库等，都是一些有实际需求的东西
前端如何参与业务
在绝大多数公司，一般都是由 pm 来主导产品，前端毕竟是开发人员，想要在产品层面上跟产品经理 battle，无异于是业余挑战专业，既不合适也没有胜算，但并不意味着开发就完全无法参与到业务中去了，pm 对于整个产品的宏观全貌肯定把握得比你深，但在一些细节的部分就不一定比一线实际开发人员清楚了，而细节往往是从具体的需求中体现的
需求一般是由产品提出的，但需求往往需要开发来实现，而产品提需求的目的是为了实现这个需求，侧重于产品层面，目的性较强，开发层面的事情还需要开发来评估，那么这个 gap 天然就是开发参与业务的机会
提需求
提需求并不完全是 pm 的特权，作为开发同样可以提需求，业务需求或许不是那么容易就能提出的，但是技术需求却是你作为开发人员的专利
作为前端，肯定是要关心自己所做前端页面的一系列的指标的，主要围绕性能、交互与风格样式这三个方面，页面加载快不快、交互是否流畅、风格是否舒适统一，都是需要时刻关注的点，出了问题你就要去主动解决它，而不是等 pm 来找你，这是技术上的事情，该由你来负责
所以你可以光明正大地提技术优化需求，不敢保证一个流畅的页面会让用户忠诚度更高，但一个糟糕的页面肯定会让用户流失的（除非你是银行网站），所以技术需求表面上是技术需求，实际上也是为了业务考虑
需求可大可小，小的如样式风格统一，大的则可以建立一个前端技术项目
例如，产品希望通过持续的运营活动迭代来维持用户活跃度，那么他想要的就只是开发人员能够按时完成运营页面的上线，至于开发怎么去做这件事他不关心，只要达到产品目的就行
那么作为前端开发，你意识到运营页面可以做成可配置化的形态，所以就需要你去跟 pm 进行商讨，例如这种做法是否可行、配置后台做成什么样、需要预置哪些模板、需要预置哪些页面能力、数据存储的形态等
再进一步，你还可以继续跟产品确认，这这些运营活动将来是否可能会在多端铺开，如果是，那么你就还需要考虑多端兼容的问题了
看起来，本来一个简单的运营活动，没啥难度也没啥工作量，应届生一天就搞完了，然后你作为开发参与进去，硬是把这个需求拆成了好几个大项目，好像是自己没事给自己找事
确实，有些人就擅长_无中生有_，整天搞些看起来高大上实际上屁用没有的东西，但也别一棍子打死一群人，无中生有并不一定是贬义词，如果运营搭建后台和多端适配确实是有需求的，那么这件事情早晚得要做，而你能提前看到这一点并且提前做好准备，为业务的平滑过渡提供了保障，这就体现出了你工作经验的价值
砍需求
pm 提出的需求并不一定就是合理的，一个负责的技术人员对于需求应当有一定的判断力，对于不合理的需求要坚决说不
这里的意思并不是让你去鸡蛋里挑骨头给 pm 的工作制造人为障碍，相反的，而是给出更好的见解，共同为业务负责
比如，你事先和产品约定好了一套解决方案，在某个具体的功能上，产品发现数据不达预期，于是想要你专门为这个功能开发一个特定的逻辑以提升数据，这件事情可能确实可以做，并且技术上也不难实现，但作为开发人员你还要为整体的技术方案负责，约定好了的方案，为了某个特定的功能添加额外的逻辑，会不会对整个技术方案造成破坏？会不会因小失大产生长远的负面影响？还有没有其他更好的解决方式？
看起来，似乎有点推诿扯皮的意思了，但如果你的出发点确实是为项目考虑，并且理由足够让人信服的话，谁又能说你是在推诿扯皮呢？
能够有理有据地阻止不合理的需求，将有限的人力、时间花费在更重要的需求上，才能更好更快地推进业务
只是前端？
很多人都说后端比前端更加贴近业务，理论上似乎是这样，但我的看法是，具体到个人的话，还是要看你自己的态度，如果后端只是日复一日地 CRUD，既不主动了解业务，也不赋能业务，再贴近业务又有什么用？同样的，前端如果只是甘心于当切图仔，哪怕每个需求 pm 都专门给你讲得清清楚楚也没用
所以还是要看个人的主观能动性，在技术之外，要主动去看更多的东西，我不是让你去一行行看后端代码，当然，你有时间看也可以，只是没必要，业务代码没什么好看的，反而看得脑壳疼，业务由一个个需求迭代而来，那么想了解业务就从需求着手
pm 提了一个需求，你不仅要关心前端需要切哪些图片做个什么样式使用什么组件等技术问题，还要弄明白 pm 为什么提做个需求，这个需求解决了什么问题，涉及到的上下游关系等业务层面的事情
跟后端约定接口字段，不仅仅是盯着后端给你返回所需的字段就行了，还要多考虑一些，例如，接口是否有可复用性、字段是否冗余、有没有必要做接口的拆分或整合、前端如何保证接口出错的情况下页面仍旧是可被用户接受的？有些可能应该是后端应该做的，但你不能保证所有人都尽职尽责，那么你就可以多关心一些事情
当需求评审的时候，pm 更多地询问你的意见，当约定接口的时候，后端更习惯你来制定接口规则，当你关心的事情越来越多范围越来越大，这个时候，你还觉得前端只是切图仔吗？
如果你成了最熟悉业务的人，那么团队中其他成员遇到不理解的业务问题，第一个想到的肯定是你，那么你在这个团队中就有了具有实质性存在的价值，而且是不容易被替换的那种
需要注意哪些事情？
技术是立身之本
上面说了那么多业务多么多么重要的东西，可能会引起一些人的误解，觉得既然是这样，那我赶紧 all in 业务得了，反正技术似乎也不重要
这种想法也是错误的，你既然是一名技术人员，那么技术对你来说就是本职工作就是立身之本，想要往外延伸到更多的领域，首先必须要先把自己的根基打牢才行，若是连技术这点事情都没整明白，就嚷嚷着要搞什么业务和管理，可能最后得到的只是一盘散沙
那么如何平衡这二者的关系呢？
对于前端这一行来说，我的建议是，前两到三年，更多的精力（最起码 80% 以上吧）投入到技术上面，保证在两到三年内在前端技术层面，能够达到合格的状态
什么是合格的状态？量化一点地说，就是网上正常场景下的任意前端面试题，你有 80% 以上的把握能答出来，可以实现工作上提出来的任意前端需求，能够保证自己所写代码项目的稳定性和可扩展性，前端领域新出现的技术你都能快速上手并且理解其原理，对于大部分人来说，这个应该不难
然后，剩下的 20% 用来关注业务，注意是关注业务，至于参不参与不太重要，因为两年工作经验之内的菜鸟，在业务上是没有多少话语权的，并且思考方式还不成熟，这个阶段更多地是观察，观察业务是如何运转的，观察其他更高级别的人是如何参与业务的，学习他们身上的优点，进而形成自己的思考观念
两到三年后，你差不多也升了职级，在团队中的地位有了少许的提升，你说话的分量也能引起其他人的注意了，这个时候，你再开始尝试着去参与业务，将自己在前两年学到的、总结下来的技巧和观念，真正地运用到业务中去
不要闭门造车
无论你想做什么事情，首先都要以开放的心态去面对，而不是打定了一个主意后就立马埋头苦干，在做之前先倾听其他人的意见，看看是否有更好的解决思路
比如，你想做一个前端错误监控系统，你可能从网上查了详细丰富的关于前端错误监控的资料，然后觉得信心满满可以开干了，然后你自己一个人起早贪黑默默干了几个月，终于弄出了一个像样的项目，这个时候你拿出来准备一鸣惊人的时候，结果你 leader 却满脸诧异地跟你说你难道不知道有 Sentry 这个东西吗？
或者你在网上查找前端错误监控资料的时候，无意间发现了 Sentry，于是决定自己先上手熟悉一遍，弄清楚了所有开发部署流程之后，拿出来准备干一票大的，结果你 leader 满脸诧异地跟你说你难道不知道隔壁部门前段时间就已经基于 Sentry 搞出了一套适用于咱们公司的监控系统了吗？
所以，一定要多跟外界进行交流，一方面是为了能从外界获取更多的信息，另外一方面则是让其他人知道你在做什么事情 (至于为什么要让其他人知道你在做什么事情，这个各位自行领悟)
用数据说话
作为前端，你可以提需求，也可以砍需求，甚至可以对后端指手画脚（当然，我更建议你谦虚一点），但前提是一定要有足够的底气，而实际的数据可以赋予你这个底气
你要提一个性能优化的技术需求，需要好几天的时间，如果你只是说前端性能不好需要几天优化一下，这显然无法说服担心项目进度被延误了的 pm，但是如果你能拿出实际的数据，例如，现在网站加载需要多长时间、发起多少个 http 请求、代码体积多大、FP/FMP/TTI 都是多少、低于行业标准多少距离、可能会对业务造成什么样的影响，然后优化后又能达到什么样的效果，有理有据地摆好数据后，pm 只要是个正常人，肯定会认真考虑一下你的建议的，即坚持以理服人
良好的心态
不同于技术的纯粹，业务上的事情肯定跟人有关，跟人有关的事情肯定就会有磨合的过程，在推进一项业务发展的过程中，肯定会遇到很多有意无意的阻力，这可能会让抱着一番好心努力做事的你感到憋屈，觉得自己一番好心不被认同，还不如每天划划水算了，这不仅是对工作不负责，更重要的是，对你自己不负责 ~(毕竟，你肯定不想 35 岁就失业了吧)~
业务基本是都由团队推进，几乎不存在个人单打独斗的可能，团队中的每个人都有自己的长处，每个人的长处汇聚到一起，才成就了团队的战斗力，能够顺利地推动团队融合与发力，可能比你攻克了一个技术项目还要重要的多
不要总觉得同事 sx，你们既然同属于一个公司甚至部门，就说明你们的能力是差不了多少的，如果你觉得身边人都是 sx，那么你大概率也是，所以当你斗志昂扬地要完成一个业务目标却遇到了阻力的时候，先别急着骂同事 sx，心平气和地讲事实摆道理，实在不行就走个流程，大家都是打工的，谁没事去故意针对你？
你只是在工作而已，犯不上因为工作上的事情让自己不开心，有问题就解决问题，做好你认为该做的事情就行了，要相信领导能坐在那个位置上成为领导，大概率不是傻子 (如果真的是，建议你为了前途着想还是赶紧换一家公司吧)，真正实干的人，肯定更容易得到机会与赏识
小结
–
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数前端工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Web前端开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上前端开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：前端）
完整版面试题资料免费分享，只需你点赞支持，动动手指点击此处就可免费领取了。
回顾项目
往往在面试时，面试官根据你简历中的项目由点及面地展开问答，所以请对你做过的最好的项目进行回顾和反思。回顾你做过的工作和项目中最复杂的部分，反思你是如何完成这个最复杂的部分的。
面试官会重点问你最复杂的部分的实现方法和如何优化。重点要思考如何优化，即使你项目中没有对那部分进行优化，你也应该预先思考有什么优化的方案。如果这部分答好了，会给面试官留下很不错的印象。
重点在于基础知识
这里指的基础知识包括：前端基础知识和学科基础知识。
前端基础知识：html/css/js 的核心知识，其中 js 的核心知识尤为重要。比如执行上下文、变量对象/活动对象（VO/AO）、作用域链、this 指向、原型链等。
学科基础知识：数据结构、计算机网络、算法等知识。你可能会想前端不需要算法，那你可能就错了，在大公司面试，面试官同样会看重学生这些学科基础知识。
你可能发现了我没有提到React/Vue这些框架的知识，这里得说一说，大公司不会过度的关注这方面框架的知识，他们往往更加考察学生的基础。
这里我的建议是，如果你至少使用或掌握其中一门框架，那是最好的，可以去刷刷相关框架的面试题，这样在面试过程中即使被问到了，也可以回答个 7788。如果你没有使用过框架，那也不需要太担心，把重点放在基础知识和学科基础知识之上，有其余精力的话可以去看看主流框架的核心思想。
前端基础知识：html/css/js 的核心知识，其中 js 的核心知识尤为重要。比如执行上下文、变量对象/活动对象（VO/AO）、作用域链、this 指向、原型链等。
学科基础知识：数据结构、计算机网络、算法等知识。你可能会想前端不需要算法，那你可能就错了，在大公司面试，面试官同样会看重学生这些学科基础知识。
你可能发现了我没有提到React/Vue这些框架的知识，这里得说一说，大公司不会过度的关注这方面框架的知识，他们往往更加考察学生的基础。
这里我的建议是，如果你至少使用或掌握其中一门框架，那是最好的，可以去刷刷相关框架的面试题，这样在面试过程中即使被问到了，也可以回答个 7788。如果你没有使用过框架，那也不需要太担心，把重点放在基础知识和学科基础知识之上，有其余精力的话可以去看看主流框架的核心思想。
扫一扫
956
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
