作为前端，我对业务的一点理解

最新推荐文章于 2024-11-12 11:19:19 发布

2401_84094868

最新推荐文章于 2024-11-12 11:19:19 发布

阅读量383

点赞数 5

分类专栏：程序员文章标签：前端

本文链接：https://blog.csdn.net/2401_84094868/article/details/138945388

版权

程序员专栏收录该内容

265 篇文章 1 订阅

订阅专栏

相辅相成

曾经的我认为，技术和业务就是两条不相干的路，我投入在业务上的时间多了，那么在技术上的时间必然减少，与其技术、业务两手抓，做出两个 50 分的成果，我作为一个技术人员，不如只抓技术，争取做出一个 100 分的成果来，但实际上这种想法有点天真

首先，除非你天赋异禀，否则很难将一件事情做到极致的 100 分，甚至 80 分都很难；其次，技术跟业务并不冲突，花费一些时间在琢磨业务上，并不会减少多少你在技术上的投入度，相反的，二者是相辅相成、互相促进的关系，是 1+1 大于 2 的组合

因为能够发现业务的痛点，所以想用技术去解决，带着明确的目的去学习与尝试，必然会有更高的效率；因为有了足够强的技术，所以能够解决更大的业务问题，获得更多的成就感

如果你没有做业务的主动意识，而是被业务方赶着走，这种行为就是搬砖，反之，如果是你推着业务走，让业务方因你而改变，那么就是你赋能了业务

经常看到一些三到五年工作经验的前端很迷茫，明明知道路已经走到底了，却不知道下一步该怎么走，于是开始尝试着去改变，但路子可能走得不太对，例如看 Flutter 比较火，所以跑去学 Flutter，看到 WebGL 可能有前途，于是跑去学 WebGL，甚至有的人跑去学 java/python

不是说这些尝试新事物的行为不好，相反的，很好，敢于尝试敢于行动无论什么时候都是值得鼓励的事情，但是得明确你做这些事情的目的，考虑一下 ROI，比如，你看好 Flutter 未来的发展，并计划好将来投身于 Flutter 领域，于是先自己学起来，打好基础为将来进入一个 Flutter 团队，甚至是在自己的团队内推广 Flutter 做好准备，那么显然是正确的思路

但是如果你只是觉得现在的工作到瓶颈了，觉得大家都在吹 Flutter，反正自己也不知道要干啥，那就跟风学学吧，或许可能将来就派上用场了，到时候自己一鸣惊人，那么这种思路其实就有点跑偏了，Flutter 确实能带给你新鲜感与学习到新东西的成就感，但这并不能解决你目前工作碰到瓶颈的问题，你只是选择去回避它而已，leader 给你打绩效并不会看在你学会了 Flutter 的面子上，就手下留情，除非你团队真的在用 Flutter 并且你也参与其中做了贡献了

同样的，作为一个前端问如果会一点 java/go 会不会更有竞争力？我的答案是，聊胜于无（会一点当然最好，但不会也没关系）

你毕竟是前端，如果在前端面试的时候，连前端的基础知识都答不好，你哪怕会背Spring源码又有什么用？而如果你能做到无论是基础题、算法、项目经验都对答如流，跟面试官谈笑风生，谁还关心你是否知道什么是高并发？

拓展壁垒

技术这条路可以很宽广，但对于绝大多数人绝大多数场景来说，能够被实际使用到的技术只是一小部分，特别是前端，相比于后端、算法来说，技术含量较低，更倾向于技术的广度而非深度

可能从业三五年的C++程序员都还会写出有语法错误的C++代码来，但在前端很难发生这种事情，稍微勤快点的应届生毕业半年就不该再写有语法错误的前端代码了，有bug基本上也都是业务逻辑bug，一个五年工作经验的C++程序员和一个只有一年工作经验的C++程序员，他们的技术水平可能有着本质上的差距，但如果换成前端程序员，很可能两人的技术水平就是差不了多少了

但是很显然，就算是前端程序员，我们一般情况下还是会认为五年工作经验的会比一年工作经验的能力更强，技术水平可能二者差不了多少，差的是其他方面

技术广度吗？

可能不是，有较大技术广度的人在做技术选型的时候，可以有更多的选择与搭配，但这种能力并不是必不可少的，公司团队作战，很少会因技术栈的选择而产生困惑，你或许会因为从业时间较长，所以学会了更多的技术，例如 React Native、Flutter、WebGL 等，但这些更多地是赋予你切换技术栈的能力而非增加你个人总体的技术实力，如果你公司不用 React Native、Flutter、WebGL，那么你会这些也没多大用，也没人会关心

如果你公司真的就用这些技术了呢？不好意思，这些又不是什么很难的东西，并不存在技术上的循序渐进，给一个应届生一段时间，他也能学会，一般情况下，一个部门或者团队也不可能用很多种技术栈，技术广度到达一定程度之后，再继续往上增加的意义只会越来越小

技术深度吗？

或许是

但是这个很难，还是前面说过的话，除非你真的是擅长技术，否则你很难有深入的机会，特别是前端这个领域，99.9%（可能需要在小数点后面再加几个 9 才符合实际）以上的场景，根本不需要考虑什么深度，也根本不需要考虑什么性能什么优化，我实在是想不到哪些前端的工作场景下，会需要用到编译层面或者操作系统层面的技术攻关

做出（注意是做出不是会用）小程序或者是做出 React 这种级别的东西，对于前端技术确实是一个重大考验，但是绝大部分人跟这些根本就没啥关系

真正需要深入到底层，比如编译层面或者操作系统层面，这种已经不能称为是前端开发了，而能深入到这个地步的技术人员，大概率也不会是前端出身

工作经验？

是，也不是

如果你工作三年，只是按部就班地搬了三年砖，那么你可能只是一年的经验又被你重复了两年而已

真正好的工作经验应当是持续学习与进步的，不仅限于技术上的进步，如何写好易于维护的代码、如何用技术能力保障业务的稳定性、如何引领新人快速融入团队，都是不可或缺的东西，想要获得这些能力，需要时间，但更需要你的主动探索与实践，而这些是无法速成的东西，也是你作为一个技术老鸟，能跟应届生真正拉开差距的地方

而无论是技术水平、技术广度、工作经验，它们之所以有价值，归根结底，还是因为它们都有服务业务的能力，所以一切都是围绕着业务展开的，既然无法避免，那么自然是越早学会游戏规则越好

什么是业务

在前三年，经常有资历更高的同事跟我提起业务这个词，听得多了，我有时候也想去了解它，但总是发现这个东西太虚无缥缈了，编程语言的语法、关键字、设计模式、算法我都可以实实在在地看到并运用，但业务到底是什么？我怎么学？我又该怎么去关注业务？

总之很苦恼，老是有人跟我说业务，但我却无从下手，硬着头皮去模仿，最终也只是学了个皮毛，于是逐渐放弃

目前在第二家公司入职的团队，相比于之前来说，业务压力大很多，几乎没法再像之前那样优哉游哉地搞自己的技术研究，然而在这种环境下，反而加速提升了我对于业务的理解，也明白了为什么之前那么多人跟我说业务很重要，但没有一个人能教会我到底什么是业务，因为这个东西真的很难说清楚，或者换句话说，其实每天都有人跟你说什么是业务，但因为你自己本身无法领悟，所以你觉得他们什么都没说

在绝大部分情况下，技术都是要为业务提供服务的，这句话蕴含着两层意思

第一，技术的唯一目的就是支撑业务

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

业务是一个商业公司的命脉所在，而技术只是支撑业务的关键之一，所以业务真的很重要

那么，什么是业务其实也就很好理解了，你的技术所服务的就是业务，而你能够让业务蓬勃发展的一切正向能力（包括但不仅限于技术能力），都是业务能力

前端如何赋能业务

肯定有人会吐槽我说了半天还是啥都没说，没错，确实是这样，对始终不明白业务是什么的人来说，别人说得再多也很难理解，对于已经理解的人来说，业务就是业务，根本没什么可说的，可能真的就需要你自己领悟才行，或许某一天你自己就突然明白过来了

很难说清楚业务这个词到底是什么，但工作中处处是业务

前端如何赋能业务的话题比较大，但具体的例子却很多

运营页面自动搭建

运营手段对于 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 都专门给你讲得清清楚楚也没用