你觉得自己不够优秀？眼界高,实力差？看看这些例子

 

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

 

场景一

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

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

 

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

 

场景二

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

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

 

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

 

场景三

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

B 遇到一个线上问题，上机看日志，预发断点调试，重跑测试用例，远程抓包…加扣 扣qun一起加入学习交流:953049818

 

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

 

场景四

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

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

 

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

 

场景五

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

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

 

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

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