内容简介:曾经在知乎的一个问答我觉得,随着互联网产品越来越多,用户们必定也会不断的索取更好的用户体验,前端同学也会扮演着越来越重要的角色。责任越来越重,天花板就越来越高。 (诶,自己说的话,貌似也没必要加什么引用....)当时的角度主要注重产品体验上。现在入职蚂蚁1年左右,对其又产生了一些新的想法。虽然前端的能力越来越强,技术栈要求也越来越高。但从工程角度出发,前端目前还处在一个较低的阶级水平。
曾经在知乎的一个问答 <从事前端真的没有后端工资高?> 中谈到自己对前端工程师的天花板的认识:
我觉得,随着互联网产品越来越多,用户们必定也会不断的索取更好的用户体验,前端同学也会扮演着越来越重要的角色。责任越来越重,天花板就越来越高。 (诶,自己说的话,貌似也没必要加什么引用....)
当时的角度主要注重产品体验上。现在入职蚂蚁1年左右,对其又产生了一些新的想法。虽然前端的能力越来越强,技术栈要求也越来越高。但从工程角度出发,前端目前还处在一个较低的阶级水平。
首先,我们作为前端工程师,是怎么定义这个“工程”的呢?
何谓前端工程
我刚毕业的时候,在一家创业公司做全栈,职称是web开发工程师。当时前后端未分离,而我内心的工程,就是我手头整个前后端工程代码。当时对前端工程是没有概念的,对我而言,前端就是js+css+html,它脱离了服务器就没了意义。单把这些代码拎出来,我也无法称之为工程。
后来三大框架出现,前后端逐渐分离,开始出现“前端工程化”的概念。17年初时,曾面试过一家小创业公司,面试官问我前端工程化怎么做?当时我回答:“前端工程化就是:代码模块化、功能组件化,打包、构建、发布自动化、流程化。”在后面的一年中,我的工程化概念,大致还是如此,可能还会加上一个开发规范。
在这个“工程化”概念下,我所认为的“前端工程”,就是我眼前的“前端代码”,它的最终目的是为用户输出前端页面。我最关注的即是: 如何更高效率、更高质量的为用户输出体验更好、能力更多的页面。 这些年前端coder围绕着这点也做了很多:
高效率
- ES6+
- 多端统一
- 接口管理与mocker
- 框架、 工具 库、组件库
高质量
-
开发高质量
- git
- code review
- 开发规范
-
线上质量保证
- 监控系统
- 应急-快速回滚能力
更好的体验
- 多尺寸适配
- 小程序
- 高性能
能力更多
- 复杂交互
- native能力
- 动画、游戏
当然这其中也有一些交集,比如三大框架的出现既为高交互页面提供了可能性,也提高了整体开发效率与质量。比如围绕高效率与高质量会统一建设一个前端迭代管理系统,负责工程迭代、构建、发布、回滚。
其实我也就随便列列,有很多东西都没涉及,但也能感受到这几年前端领域的突飞猛进。再站在现在这个时期,看前后端未分离的时期,那段后端兼职js、视觉兼职css的上古年代,确实不能称前端代码为“工程”,更不太好意思说前端 程序员 为“工程师”。这也难怪很多高校老师、后端同学不屑前端。
但立足现在,前端所涉及的范围已经远远超出了当年,我们的“工程”复杂度与其能拥有的能力也超出当年的想象。我们可以骄傲地说自己是一名前端工程师了。但我觉得,我们似乎离软件工程师还差一点点。
前端工程师,首先是软件工程师
网上有很多人,都说过这句话。说的似乎很有道理,却又没啥体感。而近几天我对这句话感受日深,这其中很大原因归功于蚂蚁在Node上的丰富实践。
蚂蚁应该是实践Node比较多的公司了。目前蚂蚁的大部分移动端业务,都有对应的体验适配层-BFF层,也即大家通俗理解中的Node中间层。它的主要职责为:衔接页面与后端,聚合后端接口,做好数据转化,输出最满足页面期望的数据结果。它的主要目的为:让后端更专注于领域模型,将页面数据的设计交与前端,彼此更专业高效。更通俗点说:让业务开发更快!
而加入蚂蚁后,BFF层可以说给我增加了很多工作量。我们需要开始给自己页面设计接口,需要对接多个后台系统。新增接口,可能需要考虑拓展性;旧的接口变更,需要考虑兼容性。如果涉及后端变更,需要评估其变更影响,需要评估系统的依赖与发布的先后顺序。此外还需要考虑需求上线时,node层与前端的灰度方案、监控方案、应急方案。
所以在我们组,业务需求所涉及的前端变更是需要做系统分析的,后端系统分析也是要参加的,这些涉及了上述所说种种。尤其是当需求变更较大、波及较广,甚至还同时涉及了多个系统间的迁移、升级、重构,这其中的复杂度便会迅速上升。对于体量较大、用户量较多的业务,这就是对工程师的一个考验了。
当你不断的经历这些挑战,可能突然有一刻,会有种感觉:作为一名工程师,以前都只关注自己手头的前端代码,对于整个软件系统工程的思考实在太少了。在这个软件系统中,前端所涉及的工程扮演着哪些角色?哪些系统影响着它?它影响着哪些系统?它们的变更都会产生什么影响?
所以前端工程师,其作为一名软件工程师,应该从整个软件系统工程去看。前端工程师不仅仅是完成自己的前端工程,而是完成了整个软件系统中的一部分,它也不会脱离整个系统而独立。而作为整个系统工程的一部分,前端工程要懂得去索取,懂得去影响,了解整体工程的能力与痛点,思考整体工程如何去提高。
这时候再来看这句话:前端工程师,先是软件工程师。不知道大家能否多了一些体感。
前端地位低
但如果我们从整个软件工程来看,这时候我们就会意识到一个惨痛的事实:前端工程在整个系统工程中的地位太低了。在蚂蚁,前端工程师往后走了一步,多了一层node层,在整体系统工程中扩大了自身占比,还算好一些。而对于大多数只涉及web页面工程的同学来说,望着这个巨大的软件系统工程,即使有心,似乎也无力。
其实我觉得很多前端工程师是很厉害的。尤其是这几年,越来越多的优秀毕业生加入了前端。有时候我会觉得,前端的交互逻辑如此复杂,其对代码水平的要求比后端大部分的业务场景高到不知道哪里去了。但纯粹的代码水平并无法决定前端工程的影响力。即使你能用0和1敲打出一个天花乱坠的页面,那它也就是一个页面。
前端工程在一个软件系统中是处于最上游的(用户入口)。因此,也就没有其他系统需要调取前端系统的服务。在整个软件系统中,前端对接的系统少,所影响的系统也少,工程地位低。不像后端,它既需要为前端提供能力,又需要问中后台、数据层索取能力,也可能需要问其他业务后端索取能力,对接系统很多,工程地位自然也高。
由此又会导致, 前端往往不是产品能否实现的决定性因素 。在软件系统中,需要上游系统调取下游系统服务。换言之,上游依托于下游。这自然而然的导致技术评估从下游开始。到前端评估时,已经是最后一道坎了。而这一道坎,业务方往往是无论如何也得过的。如果坎比较高(交互视觉难以实现),最终也是通过降低交互复杂度与用户体验,来保证产品功能先上。
有很多同学认为 前端对业务的参与度太低了 。但我们自我感觉对业务参与度也挺高呀,我知道产品都有哪些页面,都有哪些功能。 但了解并不是参与,影响才是参与 。前端的工程影响力以及业务影响力,导致了前端对业务的参与度本质上是很低的。在这种情况下,说白了,很多前端只是流水线工人。视觉稿来了,实现它。实在实现不了,打回换一份更简单的视觉稿。可不甘心做一个流水线工人啊,似乎都能看到年纪大了以后被裁员的结局。那这又该怎么办呢?
前端的焦虑
前端仿佛一直处在焦虑当中。前两年我们的主要矛盾是 日益爆发的前端新技术同前端程序员学不动之间的矛盾 。而这一两年前端技术栈趋于稳定,轮子相对也少了。加上前端程序员也比较拼,学不动的感觉也随着无数个夜晚的学习而渐渐逝去。
这时候前端又开始了新的焦虑,前端的天花板是不是太低?工资是不是没后端高?前端开发的壁垒在哪里?我认为我们的主要矛盾已经发生了变化,变成了 前端日益增长的工程地位诉求同前端工程局限性之间的矛盾 。
聪明或勤奋,再加上时间的积累,总是能解决“学不动”的问题的。但前端工程地位诉求怕是自身再怎么努力也不一定能解决的。解决当下前端焦虑的办法只能是打破前端工程局限,增加前端工程影响力,拔高其工程地位。最终让 前端人员也能在软件系统工程中当家做主,平等的参与到软件系统建设当中 。
只有前端崛起,前端工程师才能摆脱焦虑,而这不是一两个人的战斗,需要大家一起去努力实现。我个人想了三条计策。
崛起三计
无中生有
能从现有工程中发现痛点,创造出一个系统或服务,提高效能、促进业务出成果。典型的如Node层,利用node服务端能力,搭建一层为前端服务的BFF层。于是便在一个软件系统工程中,硬生生造出一层系统,拓展了前端工程师的工程地盘。
远交近攻
在一个系统工程中,我们多做了一部分工作,自然就有人少做了一部分。现在我们无中生有的,是人家不愿意做的“脏活累活”。如果我需要侵占下游的核心能力时,他们便不一定让步了。这时候我们可以采取“远交近攻”。如果我们能直接对接下游的下游,同时又能拥有下游的能力。那我们下游还有什么存在的意义呢?现在流行的FaaS似乎就给我们提供了一个idea、亦或者就是个契机。
反客为主
前端虽然是上游系统,但可以通过提高自身工程能力, 主动地放大业务可能性 。将可能性的瓶颈下抛,进而促进下游系统提高自身能力。 化被动为主动,改接受为影响 ,进而提高自身工程地位。典型的如小程序。小程序最初是由客户端同学去实现,最开始其实也是致力于平台生态问题。因其技术栈基本与前端契合,极大了利好了前端开发者(而不是客户端开发)。前端开发同学疯狂涌入后,一方面做了非常多基建工作,极大提高了小程序开发效率。另一方面,大量的小程序让业务看到小程序的无限可能。进而对小程序本身能力也多了很多诉求,如微信小程序支持了Npm包。社区里,前端程序员在小程序建设上不断努力,如今说到小程序,大家似乎都在夸前端厉害。
相信随着无数优秀的前端同学不断的奋斗,几年以后的前端工程师必然又是另外一番成就。希望届时,我们可以骄傲的称自己为一名软件工程师。我们依旧会不断学习,但学习的背后不再是因为焦虑,而是纯粹对于工程与代码的热爱~
加油吧前端程序员们!让我们一起为前端工程之崛起而编程。
本文作者:蚂蚁保险-体验技术组-阿相
崛起邮箱:fengxiang.zfx@antfin.com
掘金地址:相学长
以上所述就是小编给大家介绍的《为前端工程之崛起而编程》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- Docker和微服务的崛起
- 崛起的 Python,真的影响了 76 万人?
- 钉钉崛起:疫情中的硬核输出
- 开源改变通信业未来:中国力量悄然崛起
- 编程语言流行新动向,Groovy重新崛起
- Unix 风雨五十年:老兵远去,新秀崛起!
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
.NET本质论 第1卷:公共语言运行库
博克斯 (BoxDon) / 张晓坤 / 中国电力出版社 / 2004-1 / 48.00元
本书由10章组成,探讨了CLR即公共语言运行库,涵盖了基本类型、实例、方法调用和消息、AppDomain、安全、以及CLR外部世界。一起来看看 《.NET本质论 第1卷:公共语言运行库》 这本书的介绍吧!