part 01:

现在开始第一部分啦,说到职业,那么肯定是以公司为单位,公司里又以团队为单位,那么一个前端团队就是前端工程师的职场,在团队中团队的阶梯决定了你的职位高低,薪酬高低,包括专业能力的高低,负责的业务和技术的偏向,这对于做过team leader的人来说还是比较好了解的,发展瓶颈也很简单理解,当你处在一个前端团队中的时候,不同阶梯中的工程师如何跨域当前层次,就是你的发展瓶颈。

第二页:

从团队的角度来划分,一般的团队分为初中高,资深专家,架构师,项目负责人这几个通用的阶梯吧。

每一个阶段的开发人员,很多公司划分起来都是不一样的,有些公司硬性规定工作年限,有些公司可能放宽工作年限,更多以在公司内部的贡献来分层,俗话说的拿苦劳来堆,还有的公司比较随意,老板说你是什么就是什么,一般这是在小团队,还有一些大厂,无法人治的时候,则会使用技术委员会的方式进行职级评审,或者在面试的时候就决定了你的职级。基本工程师的分级机制的由来就是这几个手段。

所以不难看出,在技术扎实的前提下,工程师在一家公司的职级和职业发展好坏,技术能力仅仅只是系数之一,而不是100%。更多的人可能是靠运气,或者耐心,或者影响力得到的高职位,或者说,一些人更喜欢表现自己,领导更能发现自己,才得以晋升步步高升。这是职场现状,其实不仅仅在前端,任何团队,技术的非技术的,都会是这样,但是技术岗位,技术能力是准入门槛,门槛相对高而已。

而具体每个岗位的能力模型,我会在第二个部分,详细讲解,这一部分只说职业现状相关。

从阶梯角度来看,发展瓶颈我个人认为分几个维度的评判标准,前端的技术能力可能是50%,后端能力可能25%,业务综合素质能力可能又是25%。这也是为什么,有些人会很困惑,这哥们某一方面的技术深度并不如我,但是为什么他管理我,而不是我管理他,因为团队属性决定了,你要和外部团队交流,有技术,有运维,有产品,有运营,如果只是在前端某个技术领域专精,比如性能优化,比如前端模块化,比如代码抽象,设计模式,甚至说我对nodejs的每个API都非常熟悉,团队里没人比我还厉害了,我做运营活动页又快又bug少,我在team中最会和产品撕逼,再或者说我对代码重构非常了解,或者我对如何编写一个视频播放器,尤其是编解码部分的细节实现原理无人能及,再比如说我是架构组的核心人员,我专门给大家提供抽象的web组件或者插件。

每一项专精领域的能力只是你立足团队中的基石,甚至说,leader对你的预期就是这样,T字形人才的发展,都是深度和广度并重的,这也是为什么新人,专精了某些技术后,浮躁的表现之一,但是把你换一个领域,你就歇菜了,初中级别可能这样就算ok,但是中高级和资深前端,一定都是T字型的,在某一领域专精,其他领域和综合素质又非常优秀,把他扔到一个没接触过的行业中,也能快速给出解决方案的人,这些能力可以锻炼吗?肯定是可以的,比如后端能力,业务能力,通过看书自学,或者和兄弟部门进行交流甚至启一些业余项目都是可以锻炼自身能力广度的方式。

目前前端职业现状就是,精通一门的人少,精通多门的人更少,有业务能力的那就更更少了。所以这也是为啥初级前端不好找工作,中高级前端又迷茫自己无法晋升,高级前端根本招不到的一个现状。

很多公司在招聘的时候,软技能和项目经验可以快速帮你建立职场优势,比如你在linux下可以无阻碍开发,比如你之前有过相关领域项目经验,很多业务是之前上一家公司都做过的业务,上手起来领会需求非常快,一些名词不需要给你再科普。再还有就是沟通能力,无论是团队还是朋友,或者情侣,也没人愿意找一个闷葫芦一起工作。回想一下,你的领导比较信赖的下属或者重点提拔的下属,哪一个是半天打不出一个屁的主?

最后说一下前景,前景分两个吧,有些人觉得前景就是钱景,money,有些人觉得做自己喜欢的事,能够锻炼自身技能,钱不钱无所谓,我是个富二代。每个人对前景的定义都不相同。我分2个层次来理解,想获得职位,money的人,性格不保守,可以选择创业公司的一些岗位,性格保守的可以选择在大公司走正常晋升路线,技术管理都可以。而想获得改变世界能力的这部分工程师,性格保守的可以选择自己业余维护开源项目或者个人项目保持自己的成就感,激励自己前行,性格偏激点的可以找人合伙创业,技术创业等。

回到一开始说的,如何突破瓶颈决定了你能够接触和看到的前景到底是什么样,每个人阶段不一致,看事情和做决定都会千差万别。我举个实际的例子,你先画一个圆,代表你的所有能力,类似一个饼图(我可以拿纸笔画一下,反正直播),然后你想你的这个圆原来越大,那肯定要在你所有能力下,先有一个点的突破,这也就是叫 深度优先,当这个深度突破了你之前的深度时,你就会发现新的世界,那么瓶颈也就自然突破了,整体能力就会有一个对应的提升方向。

还是拿前端举例,我们对代码重构非常感兴趣,买了几本重构的书,代码大全,设计模式,函数编程,深雕细琢的系统学习之后,我突破了我之前代码组织的能力,那么我可能就像手里拿了一个锤子,看什么代码都想重构钉一下,钉完了会发现,哎,我对整个代码的流程又有了新的认识,在重构的基础上完成了几个性能上的优化,哎?好像貌似我在重构的时候还可以重构一些测试用例?代码注释,哎,代码注释是否可以拿工具生成?顺便又了解了一下jsdoc相关的内容,重构了几个同事的模块或者自己以前的模块,发现有不好的地方,又是一次学习。可能你会说,那你的意思就是去学重构呗?当然不是,我再举个例子,比如说一个前端从来没写过curd的后端接口,他可能就不太会理解,为什么要做前端静态化,因为他不知道接口背后的逻辑是要去拿缓存,缓存不命中的时候,要去读数据库,数据库nosql和关系型数据怎么选型等等一系列知识,他可能看后端,就是一个黑盒,那么肯定不理解静态化和非静态化本质的好处,减少消耗最好的办法就是什么数据都缓存起来,当数据有变化的时候通知到缓存做更新。如果理解了这些,那么前端的什么自定义事件啊,全局广播啊,不都是换汤不换药么,反之你理解了前端的通知,理解起来后端的通知,就会更好理解一些。

说了这么多还是,突破技术瓶颈,能力瓶颈的方法,就是深度优先,当深度深入到一定程度,广度自然出现在你眼前。

对前端工程师的职业现状分析和前景,以及如何突破瓶颈部分我就先说这么多。

results matching ""

    No results matching ""