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

常言道：三十年河东、三十年河西。这句话放到前端领域，就要变成 “十年河东、十年河西”，甚至每隔三五年，前端行业的技术格局就会大面积翻新。对于资深的前端开发者来说，已经适应了这种更新迭代的频率，嘴上说着“学不动了”却依旧乐于学习新工具、新框架。但对于前端新人来说，面对诸多语言、框架和工具，如何选择一套适合自己的技术栈依然是一个让人头疼的问题。前端人如何选择自己的技术栈？前端人如何更快地成长？带着这些问题，InfoQ采访了拥有 10 年工程师经验的 Scott。

面对前端如此迅猛的发展态势，拥有 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 人，专注供应链大前端的跨端工具工程化，目前已经裸辞，创办前端早早聊大会，专注社区建设及年轻工程师的能力与潜力挖掘。