怎样才是优秀的前端工程师?

总是看到各个大神们在微博、知乎、QQ群等抱怨市面上优秀的前端太少。那么什么是优秀的前端呢?主要体现在那些层面上?
关注者
2,216
被浏览
219,999

45 个回答

从某一两个维度去定义优秀的前端工程师会显得比较狭隘,用词太宽泛似乎对所有的工程师甚至其他行业也适用,所以还是罗列几组场景对比好了:


场景一

A 写的代码每次来需求都需要大面积修改,需求做的越多代码越看不懂

B 每次也加很多代码,但是需求做的越多,整体结构越清晰,尽管有些细节处理有点恶心


原因是 B 做了两件事,一是在早期就摸清楚了业务的打法,owner 了业务的前端开发,所有的业务方默认他是技术接口人了;二是用到了几个设计模式,把代码布局得十分清晰,并做好了未来多人开发的技术架构设计。


场景二

A 写了两年代码,做了十几个项目,啥也没留下,无任何产出

B 干了一年,在三个大项目中抽象了两套通用解决方案,沉淀了七八个常用组件,开发了三个小工具,并推广到团队


原因是 B 每写一行代码就在思考,以后能不能不写这行,能不能少写一行,别的同学有没有可能也在写这行;还在思考,不同项目整体工程环节是否存在缺失或者雷同,等等。


场景三

A 遇到了一个线上问题,特别着急,到处找人帮忙看问题,一会儿联系同事,一会儿联系客户,一会儿联系用户

B 遇到一个线上问题,上机看日志,预发断点调试,重跑测试用例,远程抓包…


因为 B 平时遇到问题从不回避,硬着头皮也要向问题冲过去,对各种环境、工具和业务流程已经十分熟悉;你给他描述症状,他可以立马定位大致问题。这是基础能力扎实,和经验丰富的体现。


场景四

A 在大型项目中扮演着民工角色,成天被人催着赶工做需求

B 在所有项目中都扮演包工头角色,技术兼任 PM


因为遇到复杂的场景,B 总是能够拆解问题,有计划的安排解决问题,上传下达,做好风险把控,有预案,有效跟进,而且每次都能拿到较好的结果。


场景五

A 来了需求,第一句话是,我没空,往后排期吧

B 会问清楚需求的背景,产品的思考,运营的思考,对产品的整体推进作用,后期的策略,以及衡量结果的数据维度等等,最后还会适当修正需求


因为 B 从来都不把自己当做一个前端开发,他觉得产品是团队的,是公司的,好的内容他会接受并执行,不好的不认同的部分,产品必须先说服他。他平时就善于站在不同角色(合作伙伴、用户、老板)的角色去思考问题。


以上,手机码字,列举几个场景,不同场景背后对应的优秀工程师能力在表达上可能存在重复,仅供参考。

2019.1.18更新:

滴滴跨端解决方案 chameleon 发布啦

didi.github.io/chameleo


最近面试有个微软亚洲研究院出来的做C#和Java的同学,工作了四年,最近做了一年时间前端,目前年薪大概40万。整体算法、数据结构等计算机基础知识比较扎实,然而前端开发经验比较缺失。

面试到结尾聊到他之后的职业发展规划,他说前端就是切页面实现功能,不知道后面的成长路线是什么。

以下说了一下自己的理解;

如果说前端就是切页面实现功能,其实对应服务端也是调接口、存数据。很大的区别在于服务端有明确的成长路线,有明确的困难暴露出来,比如随着产品用户量的增长,高并发、高可用的需求越加暴露明显,后端工程师遇到到困难之后,可以寻找到明确的前人架构经验(最佳实践)可以积累学习;后端是随着业务的发展,做的服务承担越来越多的用户挑战,就这样解决稳定性问题,就像打怪升级一样,经验值水涨船高。

而前端则不会随着用户增加而提出更高的服务要求,运行代码的机器(客户端)会随着用户增加而增加,不会有高并发的稳定性问题;所以前端就一直是切页面吗?

首先前端开发的需求一直存在,而且是大量缺少人才;其次前端的入门很简单,导致大量人才涌入,涉及的利益方越发多,让这个行业充满了生机,从GitHub的代码开源就能窥一斑而知全豹;大量人才为行业做贡献容器(浏览器、nodeJS、RN/weex)、语言(ES*)、协议、效率(前端工程化)等改进优化不断提升web性能和可用性。

然而像前面说的,前端以其大量行业需求和入门简单特点,虽有大量人才涌入,但是成为真正优秀的工程师却不多,大量的前端工程师停留在切页面水平,一方面是大部分工程师缺乏计算机基础,另一方面前端开发上就像其本身JS语言一样的自由性,既能用document.body.onclick = foo,又能$('body').click(foo),也能 <body v-on:click="foo"></body>实现,反正不会把服务器跑挂掉。

90%前端工程师停留在用什么框架去撸页面的水平上,就是不断升级新框架,以为我用react/vue就比你用jquery/zepto技术水平高,剩下还有5%再进一步就是看源码,看vue源码、react源码,再进一步剩下3%就是造轮子,反复造轮子。

前端开发的松散(不是指语言本身)性等原因,前端工程师的成长路线是前期平缓后期突然陡峭。很多人说前端天花板低,遇到之后就止步不前,反正可以堆人力用最简单的方式实现。

那我觉得真正的前端工程师成长路线是什么呢?前端工程师首先是一个工程师(程序员),前面的”前端“修饰词意味着你是偏向前端领域的工程师,用通用计算机基础知识和工程师思维解决前端行业领域内的问题。

一个产品需求出来,你能开发一个页面,那是你只能完成需求,一个普通大学生从零开始半年学习,就能完成大公司的普通页面开发需求;随着能力提升,高级一点的工程师应该知道抽象一个组件解决”这类“需求;”这类“的类代表什么——Class,回到程序员最熟悉的内容Class,它意味着抽象,看你能抽象解决到哪个维度的问题,基本的是抽象一个组件(图片上传组件、轮播图组件)

更进一步是更高抽象比如mvvm框架,它将了端开发的本质抽象出来——用户点击界面->代码接收到(数据拉取或数据本地修改)->数据反馈到界面,框架接管了用户点击通知代码和数据更新更新到界面的代码,开发者只需专注处理反馈和拉取数据。

再进一步是什么,前端工程师无需开发简单页面,直接让非研发拖拽页面发布的H5工具——H5Editor(我团队研发的平台),工程师开发的组件可以积累给其他工程师使用,也可以接入到h5Editor使用;工具接管了简单页面的开发。

在更进一步是什么现在业内微信小程序、android、ios、支付宝小程序越来越多,很多功能需要重复开发实现重复测试,如果有一套代码实现多端呢?——Chameleon一套代码运行多端的整体解决方案。

更进一步泛前端全明星整体解决方案

chameleon 跨端cli(AST分析转化)和runtime:跨端实现方案。
chameleon组件库:基于chameleon实现的组件库,将跨端组件实现这单一工作收敛到一起集中开发。

chameleon前端工程化(开发到上线):规范统一、线下/线上/真机debug、数据 mock(ajax/ssr/jsBridge等数据)、资源引用(线上线下地址自动应用)、模块化、语言预编译扩展(less、es7、图片base64化、宏变量能力)、线上优化(md5 url、打包、压缩)

chameleon前端服务化和ssr:web端组件服务化,跨项目仓库使用组件,组件单测、版本灰度更新收敛;服务端(BFF in NodeJS)侧高性能渲染充分利用浏览器的加载渲染优化,分级下发页面块bigpage。

chameleon 端渲染能力接入:小程序渲染方案还是RN/weex渲染方案

chameleon editor:前端工程师无需开发简单页面,直接让非研发(产品、运营)拖拽页面发布的支持多端页面的工具

chameleon show :桌面上预览所有页面,解决移动前端页面分散碎片化,关联页面开发者、统计、依赖组件功能、监控统计信息。

抽象维度越高你产出的价值越高,影响到更多人,如同后端工程师的代码为更多人服务,你的能力经验值越高,同时对你的计算机基础能力要求越高,技术视野、技术规划能力、经验积累广度要求越高,不可能会html/css/js就能完成。

除了技术广度,也有对应各方向深度比如前端游戏计算机图形学相关知识解决相关通用的问题,而非用一些游戏框架实现功能,连重力引擎api都没用过,更别提原理理解后抽象重力相关需求了。

前文说了,我们首先是一个工程师,意味着前端工程师不要给自己设限贴标签,要学习通用计算机基础知识,解决某一领域的问题,条条大路通罗马,当你把自己当成工程师,并热爱这一个编程行业,保持学习态度,有一天会抽象到不在考虑前后端,无论前后端,语言仅仅是工具,解决通用问题才是工程师的思维。

————————————————————

半夜脑子一热写完,我用双拼输入法,有错别字抽时间改。

泛前端全明星整体解决方案即将开源~

想一起做优秀前端工程师工作的同学请发简历(秒回):

zhangnanconan#didichuxing.com