Scott:总结 10 年前端经验,谈谈前端人如何更快地成长

lgmyxbjfu
发布于 2020-9-8 14:04
浏览
0收藏

面对前端如此迅猛的发展态势,拥有 10 年工程师经验的 Scott 对此喜忧参半(曾任职阿里巴巴前端工程师、Moveha|CR CTO 和宋小菜大前端负责人,现创办前端早早聊大会,专注社区建设及工程师的能力与潜力挖掘)。

Scott 认为:这十几年来前端的高速发展,新老工程师的世代交替、工程架构与实施方式的演进、互联网产品形态的泛端化竞争,衍生出了三个问题:

就业市场供需两侧能力模型的高度不对称;
职场中的前端工程师,在心智成熟度和职业性方面的修炼难度加大;
行业头部和尾部的工程师在认知模型、思维方法、能力结构、薪资收入上的代差极大。
不过,前端行业依然处在高速发展期,红利仍在,比起其他行业的门槛和收益,前端行业的就业机会和上升空间仍然很好,优异的工程师工作 7 年,在一线大厂可以有过百万的年收入。前端,依旧是一个值得"入坑"的领域。

 

前端新人如何选择自己的技术栈?
很多前端新人都面临着一个问题:想去某大厂,但看了职位介绍后发现其技术栈与自己感兴趣的技术栈不同,应该选择自己感兴趣的技术栈还是应该为了心仪的大

 

厂而选择性学习技术栈?

Scott 的建议是:两者都可以,尤其在工作的头两年,无论是兴趣使然、收入驱动还是阴差阳错误打误撞,从投入时间和收益看,前端是一个很不错的行业。但两年后,挑战会迅速放大,无论是与同行的能力还是收入都会出现较大差距,那么再回到头两年,作为前端新人,无论是出于兴趣还是工作而选择了某个技术栈,都要保持耐心,专一专注的做沉淀,避免大而全。

技术栈会过时,而技术能力不会过时。

重点不在于选择什么,而在于选择后为此做了什么。程序员的成长,需要不断钻研专业技能,修炼技术能力,至于是通过哪个技术栈来修炼的并不重要,因为技术栈的价值,最终一定是通过业务结果体现出来的。一个工程师的技术栈,一部分由个人选择来决定,另一部分的主动权则握在企业手中,而企业的技术栈也需要根据实际情况进行调整,不存在可以一招鲜用到老的银弹技术栈。

换言之,入门时选择的技术栈对程序员来说只是领进门的“工具”,通过逐年逐月解决问题来塑造的技术能力才是程序员最需要的“修行”。Scott 鼓励工程师在某个技术栈掌握足够好了后,可以花一部分的时间去了解竞品技术栈、相关技术栈,吸收别家的优秀思想,来修炼自己的技术能力,避免抱有幻想:「选一个适合自己的技术栈,用到老」。

 

深耕已掌握技术还是学习新技术?
前端发展太快,总有新的轮子出现。刚把 Node 弄明白,又发布了 Deno 。有同学提出了一个问题:自己应该深耕已掌握的技术还是应该顺应潮流,不断学习新的技术呢?

Scott 认为:其实两者不冲突,在既有的专业领域,要保持深耕的力度,从而保持自己在此领域的竞争力,同时对于技术新潮流,要抱有好奇心,可以把新技术的起源历史挖一挖,再结合源码、文档和社区的调查,来了解它解决的问题、带来的新问题、它是如何实现的,做这些不会消耗多少时间,也不影响在既有领域的深耕,可以理解为开拓视野。

如果仍有兴趣,手痒痒,可以花时间用一用看一看,就像一些做工具做服务的同学,一开始是排斥用 TS ,一旦用上后,就觉得很香,再也回不去了。简而言之,对新潮流新技术要保持关注,并且不要仅仅满足于观望,能动手就动手把玩把玩。

 

一定要掌握的技术栈
技术栈是有生命周期的,我们把技术栈放大一些,并且放到 2020 年来看,作为前端新人,首先老三样是一定要花时间掌握的:

HTML5 ,呈现在眼前的页面元素,在 DOM 树中的角色,用法、语义化等;
CSS3 ,页面布局与样式装修,对 DOM 元素进行装饰的方式等;
JavaScript ,人机交互的事件处理、网络请求、DOM 操作,以及自身的语法演进等。
这三样前端的基础,每一个前端人都应该把它们学透。除此以外,前后端请求的网络层知识、浏览器的脚本运行环境、常见的接口设计、简单的数据结构和算法要烂熟于心。还有就是框架的选择,前端的三大框架:React、Vue 和 Angular。将每一个框架都深入学习的话,时间成本太高了,三选一深入研究即可。等这些都可以信手拈来之后,就可以玩一玩 Node.js,做做脚手架、组件平台之类的小工具,对操作系统、网络交互、数据库读写、文件管理等领域适当涉及一下就可以了。

同时,前端新人也应该注意训练自己的团队合作能力。技术栈掌握只是在团队中工作的一部分,还需要理解业务、参与项目、与人沟通,切忌抱有 「只要我代码写的好,怎么舒服怎么来」的想法,因为职场是所有人利益、意见、性格和情绪的集结点,除了把自己的事情做好,也要包容整个团队的能力现状,在其中琢磨什么是可以妥协的,什么是值得推动的。

如何快速融入新的团队
无论是刚毕业的新人,还是从后端转到前端的开发者,加入到新的团队一定会经历一段“磨合期”。融入团队有一个屡试不爽的办法,那就是 「脸皮子厚实」,敢问、敢做、敢改。

同时,还是要花心思去了解:

团队其他人都在忙什么;
目前团队有什么技术资产;
技术栈使用程度如何;
有哪些团队制度和规范;
代码是如何管理的;
项目是如何提测和发布的;
分到自己头上的业务和项目是什么,跟哪些人合作等等。
这都是最基本的信息,如果不了解谈何融入。通过多问多做多改正,快速适应团队的研发节奏和编码要求,了解业务和产品的特征,熟悉合作方的套路,保证项目按时有序的开发上线,团队同学对你的工作能力认可的时候,也就融入了。

有的同学,进团队两三个月就能成为骨干,有的同学进团队两三年还是在边缘,有人觉得是由编程的天赋、努力的程度和团队的机遇等各方面因素造成的,但实际上更多取决于自己的野心与选择。

这个问题的重点不是如何更快的成为骨干,而是自己想不想成为骨干,以及自己愿意付出多大的代价:可能是吃力不讨好的各种委屈,也可能是高强度的连续加班… 意愿越强,拼劲越强,就越容易成为骨干,但这并不是鼓励大家都跑去 996。团队的竞争是一种常态,越是优秀的团队越是如此,骨干一定是佼佼者,要拼脑力、体力、心力,拼不动或者不想拼的同学基本是进不去骨干队列,这就是选择。

既然是骨干,就要满足技术是拔尖的、业务是拔尖的,两者至少满足一者。如果技术不拔尖,那就去主动承担团队中最难且大家都不敢或者不愿意去做的事情,来修炼自己的技术实力;如果业务上不拔尖,那就跟业务方“同吃同住”(不是真吃住一起),多泡在业务里,能够“秒懂”业务方所说的业务道理,还能更有前瞻性的提出更多建议。“技术骨干”不仅需要技术上的积累,还需要对业务有足够的了解,除去智商极高的特例,绝大部分人想要成为技术骨干都需要付出更多的时间和精力,一份付出一分收获在骨干身上特别应景。

前端 Leader 技术选型
作为一名前端 Leader,在技术选型的时候该如何做决策呢?作为 Leader,做出决策就意味着要承担决策的后果。如果结果是正向的,那么皆大欢喜;如果结果是反向的,甚至给团队和公司业务带来了负面的影响,就得不偿失了。因此,有些团队 Leader 选择不做决策,求稳而不求变,但这样给团队中的同学带来的成长就很少了。

我做过很多技术决策,成功的比较多而失败的比较少,少的原因是我采用一个简单而粗暴的方法——只做 75 分的决策。简单来说,就是在妥协中用最短的时间寻求最优解,得到一个 75 分的结果,虽然尚有不足之处,但核心问题解决了,其他的小问题也就不足为虑了。
先调查:针对面临的问题 / 难题 / 痛点去调查再调查,听业务方、产品、运营、设计师、后端负责人的意见,问社区大佬、同行朋友、资深同事、竞品团队的意见,结合数据和场景形成预判,感知问题的严重紧急程度和解决思路;
问老板:跟自己的直接老板过思路,聊价值,理方向,听听他的建议(但不一定要 100% 听从);
拍脑袋:再次评估这件事的成本、收益和做了后的风险,自己能否承担,如果风险在可接受范围内就直接定目标;
立项干:挑最能吃苦最有拼劲的骨干或者高潜,来啃这个硬骨头,最快时间啃到 75 分结项。
这是针对一些复杂的高难度的场景下,所用到的技术决策方法。简易的场景就不需要大量的调查了,直接拍脑袋,立项干就行了。总结下来就是“快、准、狠”,不过在此之前需要大量的调查,数据和信息不充分,拍脑袋就拍不准。如果对行业了解不够深刻的话,还是老老实实做好调查,在征求老板同意后做好项目计划,再进行项目开发。

为什么只做到 75 分,这就是投入产出比的衡量。业务有生命周期,产品有生命周期,运营活动也有生命周期,在这样的背景下,项目方案、技术决策还有团队人员的入职离职、能力模型变化也就都存在着生命周期。这时候,10 天做到 75 分与 15 天做到 85 分是一样的效果。尤其在创业公司,做了比不做好,快做比慢做好,多做比少做好(项目数量),做少比做多好(项目体积)。

与 BAT 等巨头不同,创业公司在乎研发成本,不仅是技术决策方面,在选择技术栈的时候也会考虑“要花多少钱”:

技术栈是否最省开发资源,易上手、易开发、易维护三点起码要占两点;
技术栈是否好培养人,好招人,招人的成本相对于其他技术栈而言是高是低。
其次,选技术栈要保证 “统一”,团队的技术栈选定后就不要轻易更换,若需要更换也应该速战速决,以最快的时间全部切换,最忌讳以下两点:

隔一年半载,引入一套新的技术栈。比如 React 用的好好的,突然引入 Vue 全家桶;
历史债务技术栈有若干套,却迟迟不投入人力进行更换,导致维护的人怨声载道。
创业公司对于技术栈的选择并不绝对,要考虑业务的特征,产品的形态,老板的喜好,以及团队同学的接受程度等等,进行综合的评估。技术栈的选择不在于某个具体的技术,而是在于选择后能否保持统一,以及为了保持统一而塑造的团队编码风格和协作制度。
此前,Scott 在 GMTC 上分享过中小前端团队该如何进行管理:

《前端领域主管是刚需,中小前端团队 Team Leader 如何养成?》

这里提炼几个观点:

结构化思考、体系化推进,脑袋中要逼自己时刻装着一张公司全盘图;
这张图里面要行业、公司目标、老板目标、团队现状、人员诉求、组织环境…
以业务为坐标,以结果为导向,任何决策都要基于业务和结果设定和衡量;
心中要怀有慈爱,善待每一个招进来的同学,时刻把他们的成长放心上,学会包容;
眼中要不装沙子,看清楚每个同学的长短板,团队的长短板,不能假装看不见;
手中要有霹雳斧,包容不等于纵容,不合适的人不合适的事要敢下决定;
口中要有碎碎念,把自己当唐僧,再啰嗦的话也要天天讲天天念,你的身份之一是教练;
脚下要踩定海针,让自己泡在业务里,不玩虚的,实打实,忧业务所忧,步步为营。


嘉宾介绍
Scott ,10 年工程师生涯。曾任职阿里巴巴前端工程师、Moveha|CR CTO,最近 3 年,担任宋小菜大前端团队负责人,搭建团队从 6 人到 20 人,专注供应链大前端的跨端工具工程化,目前已经裸辞,创办前端早早聊大会,专注社区建设及年轻工程师的能力与潜力挖掘。

来源:InfoQ 

分类
标签
已于2020-9-8 14:04:52修改
收藏
回复
举报
回复
    相关推荐