少不更事爱前端,每天都想着转后端。

我的故事

我叫Jeff,是一个软件专业学生,学习前端满打满算两年了,大二接触了三大件,当时写一个go的全栈项目,当时看着视频做了个连起来的webapp,但是还是一知半解,后因为当时(2020.1)网络上没有啥go的资料,(学了gin和orm,当时也不想学java)我也找不到学习的方向,就学了react,之后在某老师的实验室做前端,react,老师很有想法,做的是实际项目,蛮累的,但是很有收获,后来我如愿在大二下拿到了某一线大厂前端实习生offer,暑假入职,实习中leader和mentor都很照顾我,我也能胜任这份工作,也能获得一定的成就感,但是蜜月期一过,哪些光鲜亮丽的光环褪去,我看到了前端程序员发展前景残酷的真相。

前端程序员发展空间很窄,晋升难

现实

高级前端很少,T9/P7以上前端就是风毛菱角,前端组长,一般是某个后台组的组长兼任或者找个前端当副组长,总之,真正前端组长很少,在往上的管理者都是后端或者产品,前端真的见不到。我唯一看到的高级前端是做文档的,有且只有做文档这种真正重前端项目才有高级前端的晋升机会,其他做CMS系统的前端就很难晋升,做一个项目,1个产品,1个前端,5个后端,做完上线了,绩效不错,分功劳,后端5个中3个能升级,产品能升级,前端没有份。前端晋升难也就导致前端为了晋升需要做的更多,后端把项目高质量的完成,不出错就能晋升,前端不行,前端必须造轮子,这就导致了前端轮子多,但是能跑的不多,圆的轮子被造完了,就只能造方的轮子,还要吹方轮子比圆轮子跑的溜,晋升上去了,轮子就可以丢了,地位就很尴尬,一个组,10个人,就一两个人是正经造轮子的,正经造轮子的也升到高级的门口就有点升不动了,同年龄的senior开发者,做后端的一般比前端高。所以现在前端就很多用node抢后端工作的,不管合适不合适,造就完事了,前端也就图一乐,真要看技术还得写服务端(nodejs/Ts),redis集群,分层架构都搞起来。前端想晋升就得比谁更像后端,晋升卷不了的前端就去搞社区影响力和转行教课去了。

原因

至于前端为什么会落到这步田地,我认为有如下原因

  1. 前端程序员离业务远。网上有讨论一说前端离业务远就一堆人出来说前端的发展快,难度不必后端低啥的,少不更事的我被这些花花言论迷住了眼。确实,前端难度不必后端低,但是,前端离业务远,这是前端最大的弊端,老板要的是业务,不是开发,会跟老板讨论流程和业务的会更得到老板的青睐,后端,产品,都是深入交流业务的角色,你不找老板老板也会来找你,他们天生就带有“向上管理”的属性,只需要把工作做好就会得到赏识和认可,就是老板眼中的功臣,就可以升职加薪
  2. 前端程序员很多时间要做不属于自己明面上工作内容的琐事。产品的需求直接体现在前端,产品一般不懂前后端职责,一般都是指着页面说我要这个我要那个,前端在这里就承担了需求到技术评审的第一环节,需要沟通很多东西,更不要说产品很多时候没想清楚需求要改需求一般也是从页面入手,接口改的不多;客户和测试出了问题先找前端(除了接口压测),前端是现网问题的第一个经手者,你可能不需要onCall,但是出了问题,他们一定会先找你,你要定位问题,再周知各方;后端经常不管前端的需求,后端常常会随意修改api字段名,有很多问题也会抛给前端,比如让你查询列表项所有项目的详情来获取某些信息,比如从a接口和b接口查询不同的信息聚合在一起,你要做很多“服务聚合”的工作,即使这应该是后端的工作,还有的糟糕后端把树形结构化,很多计算问题都抛给前端,会给前端带来困扰,还有的时候你们定好了接口,你用mock数据做好了页面,但是后端说他要改实现,你那他没办法,闹到产品哪里,一般产品不懂后端在干啥,知道前端在写页面,后端咬住说做不了的时候,就会让前端“辛苦辛苦”。前端来来回回这些时间都付出了,汇报的时候老板觉得这是你分内的,不是你的“功劳”,你得给我看点别的东西,比如你的“轮子”。(我听过后端最离谱的理由:标签和查询是不一样“重要性”的服务,不能放到一起,你自己查询一下吧)
  3. 前端技术自动化水平不足,前端工作主要内容差别不大,不需要太复杂的设计。前端虽然有很多组件化之类的工作,也有很多公司专门分出UI前端开发,专门写样式,但是由于ui难以进行合理的自动化抽象,前端仍然摆脱不了原始的生产模式,组件的位置,组件的状态都是要仔细的一个一个放上去,这是一个脏活累活,前端其实很大的工作在这里,直到今天还是摆脱不了,前端很多工作其实还是写页面,一两年经验的前端和五六年经验的前端在主要工作上基本没有区别,多的是CI/CD工具使用,安全工具的接入方式,接入层部署的知识,node写服务的技能,所以前端其实很容易被替代,要换个人来,也能很快的通过调试工具找到各个代码写在哪里,上手没有什么问题,不像后端,写的不太直观,要一个一个接口找也有很大上手成本,所以换一个前端项目顶多推迟1个月,换一个后端项目可能要推迟3个月,老板更想留住这个后端,就会给他升职加薪。
  4. 前端程序员整体水平参差不齐,成为了团队推行新技术的阻力。前端确实很缺人,所以会点就会往上赶,非科班,转行的,能用就行,这就导致前端程序员水平参差不齐,你要换技术栈,他得学半天,你要推行BFF写服务node接入层,他连sql和nginx都不懂,网络协议也只会常见的那点,更他说rpc更是对牛弹琴,新技术推行阻力巨大。
  5. 前端变化太快导致前端代码包袱严重。前端模块化方案现在不说啥了,但是我看到很多项目都要要用CMD的,这只是很小的一部分,还有用react16导致和基于react17的库不兼容报错的,更有的是react15,需要单独拆分两个模块,更不要说Ts的问题了,以前没有Ts,代码维护起来真的是很困难,接口字段都没有定义,还有有的程序员代码写的真的不太讲究,各种不该混一起的混在一起用if/else进行分支,各种对象手动赋值,维护老项目常常心里憔悴。
  6. . 老板在前端身上付出的成本低,会认为从前端身上得到的效益低。后端掌握的是数据,公司的服务器数据集群的开销主要是后端在用,后端就像老板的理财助理,投入在他身上的资金,流水更多,自然看他更顺眼,前端顶多用个cdn,老板在感情上就没有付出,就觉得这些回报都是后端赚来的,而且后端的东西就像老板的私有财产,前端的东西,别人一下子就能保存和拿到,自然感情上有意无意有所偏向。
  7. 终端技术大发展,前端性能瓶颈较少。前端的app工作在客户机上,现在客户机性能上去了,没啥性能问题了,性能主要是网络和后端,这就导致前端又少了kpi和贡献值了。

破局

很多人研究图形学,研究跨端,研究交互,在我看来其实这些都没有真正达到真正摆脱前端困境,现在前端最主要的不是如何画的更好看,好看不好看是产品和UI/UX的工作和功劳,和你没太大关系,前端要破局只有两个方向:1. 亲近业务,成为业务的主导。2. 提升前端开发效率。

  1. 亲近业务:现在很多公司都是一个前端对接3-6个后端,前端活儿很碎,又因为上手新项目快,所以一个前端常常要支援其他项目,所以前端身上挂3-4个项目也很常见,在这种情况下,前端很难熟悉业务,产品后端跟一两个业务,搞明白业务和需求也够呛,更何况前端还有很多时间被其他人的事务挤占,前端想要亲近业务有两个路子
    推行BFF,前端业务化,后端服务化,前端变成JS全栈,前端负责打通业务流程和逻辑,后端负责提供高性能存储,解决“存储”这个最大的性能瓶颈。

    1. 优点:开发更快了,接口都由你定,开发很顺畅;前端也能更熟悉业务,更能专注理解互联网运营和商业模式,更了解后端服务的知识,为以后转架构和管理做铺垫
    2. 阻力:前后端开发者水平有限,后端往往不能很好的设计和划分服务,前端很多开发者对后端一窍不通,阻碍了架构的转型,让团队用个graphql都够呛,还要前端业务化,后端服务化。
    3. 缺点:NodeJs终究扛不住很高的并发量,开发效率是高,运行效率一般,但是一般业务都够了。不过这些我都懂了我直接进行一个转后端不香吗?
  2. 做重前端业务:比如比如gis系统,数据大屏,WebGl,甚至转行做游戏。
  3. 工具建设:前端也想少点“劳动密集型”的工作,老板也想少雇两个前端,你能通过工具建设能少几个前端还能把项目推进和完成,就是大功臣,现在前端主要目的不是交互,不是跨端,就是交付!交付!交付!你能按时上线,给产品变卦和后端拖延留足空间,你就是最靓的前端仔,所以浏览器插件,IDE插件,Webpack插件,低代码平台,性能监控和日志上报系统是造轮子的好方式
  4. 转后端:我要转后端了,等我背八股文和算法题出去乱杀。
翻开高级前端秘籍,里面写满了学后端

感谢大家的关注,没想到一点小小的牢骚,居然能获得大家如此的共鸣,我真心的希望所有的程序员都可以跳出自己的圈子,有所涉猎,开眼看世界,成为独当一面的程序员,而不是一个单独定义自己为的前端或者后端。长路漫漫,与君共勉。


ps : 前端好找工作是真的。薪资水平也差不多。

你可能感兴趣的:(程序员)