作为前台,我对业务的一点了解

作者 : 开心源码 本文共8532个字,预计阅读时间需要22分钟 发布时间: 2022-05-13 共145人阅读

一直都是写关于技术的少量东西,素来没想过我会写一篇与技术没什么关系的文章,由于在之前的我看来,这种文章完全就是假大空

技术至上?

三年前我毕业进入第一家公司,个人很水的技术实力让我经常在实际的开发工作中捉襟见肘,于是就想着肯定要尽快提升自己的技术水平,每天都在公司待到很晚,除了做需求就是自我学习,在这种情况下,我几乎所有能坐在电脑前的时间都用在了技术上,这就造成了一种后果,那就是我只关心技术方面的东西,其余的我一概不论,并且越来越严重

评审需求的时候,我不关心pm想要做什么,也不关心需求的目的是什么,更不关心能否是不正当的需求,我只考虑怎样从技术上实现pm的需求,哪怕是再复杂再不正当的需求我也肯定要用我的技术手段去实现,甚至以此为荣,我认为这是表现我个人能力的方式,有些时候我的组长由于考虑到少量实现比较复杂,主动给我说少量简单的实现方案,我反而内心还有点鄙视,觉得组长太老油条了,什么复杂需求,不存在的,多给我一天的时间我就能给你实现出来

我相信很多做技术的小伙伴,都跟我有过相似的想法,但是三年过去了,回头想想,再思考一下现在,现在的我更想学习少量跟技术不那么相关的东西,比方业务

技术还是业务?

相辅相成

曾经的我认为,技术和业务就是两条不相干的路,我投入在业务上的时间多了,那么在技术上的时间必然减少,与其技术、业务两手抓,做出两个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,那么你会这些也没多大用,也没人会关心

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

工作经验?

是,也不是

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

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

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

什么是业务

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

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

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

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

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

第二,业务并不仅由技术支持,还包含了其余很多方面

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

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

前台如何赋能业务

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

很难说清楚业务这个词究竟是什么,但工作中处处是业务

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

经营页面自动搭建

经营手段对于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更多地讯问你的意见,当商定接口的时候,后台更习惯你来制定接口规则,当你关心的事情越来越多范围越来越大,这个时候,你还觉得前台只是切图仔吗?

假如你成了最熟习业务的人,那么团队中其余成员遇到不了解的业务问题,第一个想到的一定是你,那么你在这个团队中就有了具备实质性存在的价值,而且是不容易被替换的那种

需要注意哪些事情?

不要闭门造车

无论你想做什么事情,首先都要以开放的心态去面对,而不是打定了一个主意后就立马埋头苦干,在做之前先倾听其余人的意见,看看能否有更好的处理思路

比方,你想做一个前台错误监控系统,你可能从网上查了详细丰富的关于前台错误监控的资料,而后觉得信心满满可以开干了,而后你自己一个人起早贪黑默默干了几个月,终于弄出了一个像样的项目,这个时候你拿出来准备一鸣惊人的时候,结果你leader却满脸诧异地跟你说你难道不知道有Sentry这个东西吗?

或者者你在网上查找前台错误监控资料的时候,无意间发现了Sentry,于是决定自己先上手熟习一遍,弄清楚了所有开发部署流程之后,拿出来准备干一票大的,结果你leader满脸诧异地跟你说你难道不知道隔壁部门前段时间就已经基于Sentry搞出了一套适用于咱们公司的监控系统了吗?

所以,肯定要多跟外界进行交流,一方面是为了能从外界获取更多的信息,另外一方面则是让其余人知道你在做什么事情(至于为什么要让其余人知道你在做什么事情,这个各位自行领悟)

用数据说话

作为前台,你可以提需求,也可以砍需求,甚至可以对后台指手画脚(当然,我更建议你谦虚一点),但前提是肯定要有足够的底气,而实际的数据可以赋予你这个底气

你要提一个性能优化的技术需求,需要好几天的时间,假如你只是说前台性能不好需要几天优化一下,这显然无法说服担心项目进度被延误了的pm,但是假如你能拿出实际的数据,例如,现在网站加载需要多长时间、发起多少个http请求、代码体积多大、FP/FMP/TTI都是多少、低于行业标准多少距离、可能会对业务造成什么样的影响,而后优化后又能达到什么样的效果,有理有据地摆好数据后,pm只需是个正常人,一定会认真考虑一下你的建议的,即坚持以理服人

良好的心态

不同于技术的纯粹,业务上的事情一定跟人有关,跟人有关的事情一定就会有磨合的过程,在推进一项业务发展的过程中,一定会遇到很多有意无意的阻力,这可能会让抱着一番好意努力做事的你感到憋屈,觉得自己一番好意不被认同,还不如每天划划水算了,这不仅是对工作不负责,更重要的是,对你自己不负责(毕竟,你一定不想35岁就失业了吧)

业务基本是都由团队推进,几乎不存在个人单打独斗的可能,团队中的每个人都有自己的长处,每个人的长处汇聚到一起,才成就了团队的战斗力,能够顺利地推动团队融合与发力,可能比你攻克了一个技术项目还要重要的多

不要总觉得同事sx,你们既然同属于一个公司甚至部门,就说明你们的能力是差不了多少的,假如你觉得身边人都是sx,那么你大概率也是,所以当你斗志昂扬地要完成一个业务目标却遇到了阻力的时候,先别急着骂同事sx,心平气和地讲事实摆道理,实在不行就走个流程,大家都是打工的,谁没事去成心针对你?

你只是在工作而已,犯不上由于工作上的事情让自己不开心,有问题就处理问题,做好你认为该做的事情就行了,要相信领导能坐在那个位置上成为领导,大概率不是傻子(假如真的是,建议你为了前途着想还是赶紧换一家公司吧),真正实干的人,一定更容易得到机会与赏识

在前台领域混了这几年,总结了一套前台学习的精讲视频和学习路线,假如有对前台开发感兴趣的伙伴,不论你是想转行,或者是大学生,还有工作中想提升自己能力的web前台党,欢迎大家的加入我的前台开发交流群:603985993 希望大家诚心交流!,与企业需求同步。好友都在里面学习交流,每天都会有大牛定时讲解前台技术!也可以关注我的微信公众号:【前台留学生】 每天升级最新技术文章干货。

小结

原本只是想写怎样深入业务的,但后面感觉写着写着更像是职业发展指导了,就这样吧

以上只是我目前个人的少量见地,毕竟经验有限,所以可能有些观点还不是太成熟,欢迎更多的探讨

最后

听过很多道理却仍旧过不好这一生,同样的,看过很多心灵鸡汤,却仍旧不知道如何挣脱瓶颈,这个时候,我建议你换一个环境

不要埋头苦干,借助于外力的作用,会更加轻松,当身处于一个朝气蓬勃的环境中时,你哪怕是跟着团队的惯性也能持续往上走,巧的是,字节跳动就是这么一家充满干劲的公司(手动狗头)

说明
1. 本站所有资源来源于用户上传和网络,如有侵权请邮件联系站长!
2. 分享目的仅供大家学习和交流,您必须在下载后24小时内删除!
3. 不得使用于非法商业用途,不得违反国家法律。否则后果自负!
4. 本站提供的源码、模板、插件等等其他资源,都不包含技术服务请大家谅解!
5. 如有链接无法下载、失效或广告,请联系管理员处理!
6. 本站资源售价只是摆设,本站源码仅提供给会员学习使用!
7. 如遇到加密压缩包,请使用360解压,如遇到无法解压的请联系管理员
开心源码网 » 作为前台,我对业务的一点了解

发表回复