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

面对前端如此迅猛的发展态势，拥有 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