新人成长：新人在前端团队如何快速成长为技术骨干

著做权归做者全部。商业转载请联系 Scott 得到受权，非商业转载请注明出处[务必保留全文，勿作删减]。

不想当将军的兵不是一个好兵，不想成为技术骨干的技术人不是一名好技术。小菜的一个妹子如是说。

本文写于 2019 年初，写这篇文章以前，团队每一个小伙伴都给出了本身的答案，我挑几个给你们曝光下：

• 观点 1：有明确的职业规划、持续学习和总结输出；
• 观点 2：独立思考、消化吸取、深度钻研、心态好、沟通好、会合做、有团队精神；
• 观点 3：技术难题攻坚、技术方案比对、学会管理资源项目与情绪、会沟通、有感染力；
• 观点 4：作好视觉、把握视觉细节、拥抱业务、有担当、敢冒险、心态好；
• 观点 5：明确目标、心态开放、主动承担责任、跳出温馨区、持续积累；
• 观点 6：基础夯实、经验积累、学习能力、沟通协做、职业化、多看书。

不知道你们看完这些关键词做何感想，随便挑出几个词，你们能够摸着胸口问本身，作的足够好么？是否是在不少方面本身都有坚持去作了，不少方面执行的也还不错，好比多看书，好比主动承担责任，没有 10 分也有 7 分 8 分，但好像本身没有成为心目中那个朦朦胧胧的技术骨干呢？

我曾经在 2018 年 7 月份把团队的总体能力作了一次盘点，将它对比 2017 年 7 月份，一年先后团队成员的成长速度，你们也能够参考制做这张图（若是你是管理者建议每季度作一次），列出团队所须要的技术栈等能力，而后逐项标记，星星越多表明能力越好，红色的星星表明本身在 1 年内新 Get 到的和继续沉淀的技能，总体排下来，不只对本身的了解更直观，对于本身在整个团队中的位置也更了解：

而图中，像小 ABCD 属因而有必定工做经验的员工，但 AD 也是团队新人，为何能成长这么快，每一年会多出十几颗星星，以及像小 EFHI 则是属于职场新人，也能在一年时间内增加这么多技能点，我对全部人复盘后，发现全部人的成长路径是不一样的，但成长内核是相似的，我想这个内核是你们关心的，那咱们就往下看吧。

技术骨干不会凭空产生

技术骨干的定义是相对的，这个相对的参考系横轴是与同团队同窗比较，纵轴是基于当前公司业务的研发难度而言，前者与人的比较很残酷也很主观，工做年限的长短并不能决定一人是不是团队的核心骨干。一个工做 6 年的人不必定是团队的核心骨干，而一个工做 3 年的人有可能成为团队技术的顶梁柱，而公司业务的研发难度则是一块试金石，团队有人搞不定但也有人老是能攻坚下来。

咱们探讨这个话题的背景是几乎全部同窗都但愿本身成为技术骨干，而结果每每是只有部分人会在当下成为公司的技术骨干。事实上公司里是没有技术骨干这么一个岗位职称的，他每每存在于团队 Leader 的心目中，也能间接经过职级反映。在你们的眼中，每每是那个冲刺在一线攻坚最难项目的人，咱们既但愿本身成为这个他，又畏惧本身承担不起，本身也可能确实搞不定。这是一种变相的职场碾压，话很糙，但在哪里不是如此这般呢？

高考的班级里，长跑的赛道上，甚至是同行业处于竞争状态的几家公司，你们的视线都是随着领先者而移动，而领先者对于落后者的碾压始终是一种现象。

对于现象，咱们要中立观察：领先就是领先，而碾压无处不在。碾压也必定会给本身带来无形的压力，也可能产生负面情绪。碾压这个词是非褒义甚至非中性的描述，咱们应该关注的是领先的意义，碾压的本质不在于它的含义，而是领先的意义，领先是任何一家公司，任何一个团队，任何一个个体都但愿发生的事情，若是把它定义成一段周期内的领先，这段领先就是咱们所期待的奇迹。

而咱们但愿这个奇迹能够快速发生，持续发生，最好是发生在我所在的公司里，我所在的团队里，或者发生在我本身身上。

再回到技术骨干这个词，咱们就清楚的看到，它是一段周期内一我的处于领先时的状态，这个状态是一种人设，有可能不会一直持续，也会被他人超越，但这个状态必定不会凭空产生，由于领先的前提是，本身积累愈来愈多傲人的成绩，而傲人的成绩必定不是等出来而是拼出来的。

技术骨干身上的几个特征

前面咱们对技术骨干的存在合理性创建了一个认识，咱们接下来看看在他/她身上会存在的几个明显特征：

技术底子扎实

万丈高楼平地起，靠的就是深厚的地基，团队楠哥语录。

技术底子是工程师能力的核心基础，技术栈语言栈的广度深度，工程框架设计、原理的理解和运用的程度，这些方面不够扎实基本上与技术骨干无缘了。

至于说广度要多广，深度要多深反而没有一些清晰的指标。如今前端技术栈自己就是上下愈来愈厚，左右愈来愈宽，在 PC Web 的 Javascript 的单一技术栈上，若是积淀够深也足以支撑一个骨干的长成，一样在 ReactNative/Node 方面都如此，并非前端的主要技术栈每同样都逐一掌握的足够好才能成为技术骨干，反却是只要知足一专多长，这一专成立甚至是多个擅长项成立，那么就具有成为技术骨干的实力硬件基础了，接下来就要看软件实力了。

小案例：团队有个小伙伴 A，喜欢思考，关于 React 全家桶的知识储备很是扎实，从框架设计到内部运行原理以及同类型数据流方案的优缺点，全部人与他交谈都能有所收获，甚至醍醐灌顶。

善于独立解决难题

不管是在业务的技术架构中，仍是纯技术性的攻坚中，咱们知道工程实现会遇到五花八门各类各样的问题和难点，这些问题的解决和难点的突破，有许许多多能够尝试的办法，其中一个快捷键就是去请教团队里更资深的人，也就是场外求助迅速解决，但一个技术骨干在这方面每每能独立性的快速推动。

这里强调独立性并非说他也不去咨询团队内外的人，而是说他不依赖团队内外的人，经过咨询是给他提供更多分析问题的视角，最终的解决依然是靠他我的。

问题解决的过程也因人而异，有的会快速的 Github/StackOverflow/Google 甚至百度/搜狗微信参考和 review 各类开源实现，有人会直接进入框架代码的阅读和逐行 Debug，有人会拿一支笔在画板上反复勾勒推理，不管哪种，最终都是靠我的的能力解决问题，而每次解决问题后，能看到他征服困难后的成就感，用各类表情写到了脸上，身边的人也会受他感染共享征服感，你们能够设想下若是身边好多个技术骨干，天天都连续上演征服成功的案例，这对于团队士气提高是很是有益的。

小案例：团队有个小伙伴 B，喜欢独辟蹊径，不管多难受的问题到了他这里，总能独立以异于常人的方式把问题解决掉，这种问题解决的愈来愈多，功力也日渐增加，每次解决完都要在团队里炫耀吹嘘一下本身多牛逼，全部人都跟着开心片刻，这种氛围最终会影响到身边人。

不畏惧陌生领域的挑战

在一家增加型的公司，除了能感觉到组织架构和业务上每一个季度的变化外，还有一块技术人最看重的东西，那就是业务进程内外潜在的巨大技术机会与挑战，所谓技术成长空间。

这种机会一般是伴随业务的快速发展和大胆试错而来的，它有多是业务驱动、运营驱动或者产品驱动，也有多是技术驱动，不管哪一种均可能会在原有的团队技术栈里面炸开一个口子，这个口子可能就是全部团队的工程师都不熟悉的领域，你们都不熟悉怎么办，除了快速招人外，就必须有技术骨干顶上去硬啃，至少能支撑项目的 1.0 粗糙版跑出来。

那么这时候技术骨干身上的不畏惧等于什么？怎么才叫不畏惧？一句 “都闪开，老子来” 口号算不算，我以为只能算一半，前一半是刚开始时的勇气，另一半是持续去挑战所带来的征服欲，征服欲越强或者兴趣越浓，越有驱动力去想法设法钻研，征服欲越弱，眼前的问题就会变成枯燥的任务，就算解决了，带来的征服快感也随之变弱。

小案例：团队有个小伙伴 C，遇到的一个技术领域上黑盒，在咱们团队决定花精力去钻研个初步方案后，小伙伴自费搞了必要的设备，甚至整个过年期间都在强攻技术难点，终于春节后，带着可行性的方案来公司，为业务带来了极大的想象空间，驱动他的不只仅是任务，更是征服欲所带来的知足感。

极少让别人失望

这个更可能是在说结果，这个别人多是合做方，多是你的主管。为何把这个单独拎出来，是由于不是全部技术好的同窗都具有这样一个使命必达的执行力，只要允诺下来的事情，不管多难不管成败，都能拿出必定的成果来让等待的一方有所收获，这是一个技术好的同窗走向技术骨干最重要的一个特征之一。

技术骨干的同窗技术必定好，但技术好的同窗未必是技术骨干，这一点每每被忽视，也是童鞋们在工做中最容易想固然的一件事情，若是你让别人失望的次数到了必定数量，那么距离技术骨干也还有一段距离了，由于骨干脱离了公司脱离了团队就会失去实际意义。而一个团队必定有它特定的定位和目标，目标的达成是衡量这个团队战斗力很是核心的标杆，也是主管脑海中的骨干的画像特征，定义骨干与非骨干的分水岭就在于此了。

如何快速成长为技术骨干

上面咱们聊了技术骨干存在于咱们大脑中的投影，也知道了他身上具有的显著特征，那怎么成为技术骨干呢？能够从下面几种路径入手：

1. 弄清楚任务的 what 和 why

任何一个任务都有特定的背景和目的，好比老板让你去预研下 Electron 开发客户端软件的可行性，这是必定要问清楚这个可行性的软件客户端开发方案是为了承载什么场景的需求？为何要用客户端而不是网页的方式来实现？

这就是任务的 what 和 why，须要你跟老板明确对焦，有可能他须要的仅仅是一个能够收发消息的聊天功能实现方案，这时候一个 socket 的聊天室网页版可能就能知足需求，应该是去调研 socket 更有价值而非是 Electron。一旦真的是去调研了，即使调研过程很漂亮，但对于最终问题的解决不是最优解，损失的不只仅是老板对你的信任，更是失去了一次独立最优解拿下问题的机会。

有了这样的一个任务的对焦过程，咱们会更了解到本身作这件事情的价值，对于结果也会更有期待，原始的驱动力自然就存在了。

2. 从过程当中而不是从结果中学习

在微信群和社区常常看到提问的同窗，很是焦急的等待一个问题的答案，或者是本身独立解决问题的过程当中各类快捷方式求结果，拿到结果或答案后便迅速用到项目中，以后便丢到脑后，这是很是不可取的学习方式，每一次丢弃都丧失了一次成长的机会，要知道结果的价值是相对于业务和项目而言，而过程的价值才是相对于本身而言。

每一次拿到结果后，能够写一篇博客记录，也能够记个笔记，也能够弄张纸 review 一下，也能够讲给别人听，本质上是让本身从新播放刚才解决问题的过程，从中观察是什么样有意无心的动做和思考方式，启发了本身最终找到关键线索和路径，这样的一个思考过程反复锤炼会造成一个解决问题的套路库，好比什么问题直接 Google 就能够，什么问题要深刻到代码中去深究，什么症状大几率是人为使用错误而非程序设计 Bug，从外向内再从内向外，让本身不只仅对于技术框架或方案的细节更了解，也对于它们宏观上的特征更了解，最终让本身的问题解决能力愈来愈高效。

3. 以开放的视角看待一切技术存在

现在互联网全部上层的繁荣集市都是创建在各色各样的技术底层之上，不管是从 ASP 到 Go 这样的语言层面，仍是 jQuery 到 React 这样的框架层面，从硬件到软件的方方面面杂糅在一个无限复杂的网络中执行着本身 0 和 1 的信号逻辑，任何一只能抓老鼠的猫都是一只有用的猫，技术一样如此，合理存在必然有特定场景下的价值，咱们能够打开胸怀去观察甚至去接纳。

但开放到什么程度呢，是无限开放么？答案确定不是。咱们凡胎肉身不可能把目前极度细分的技术领域都摸过来，只能在特定的工程背景下作必要的心态开放，在未见到一个技术的真正价值以前不轻易否认它，在未评估好在本身项目中落地可能性以前不轻易使用它，这是两个层面的接收和拒绝，前者是价值与合理性的接收，后者是可行性落地与成本评估的拒绝。

聊这么多，跟技术骨干有什么关系呢？是由于技术骨干永远不知道本身接下来会面临一个来自什么领域的挑战，而保持视界的开阔和心态开放会给本身注入足够多的信息线索，有选择性的尝鲜，保持试错的好奇心，老是尝试去琢磨一个技术方案的核心价值点和设计策略，这样即使面临陌生领域的挑战，也能够用各类参照比对的方法为本身快速构建一个解决问题的路径坐标系，在这个坐标系里面，上下左右延展总会碰到以前大脑中索引的一些信息线索，从而触发一些灵感的产生，这些灵感的产生可能就是问题获得有效解决的关键。

4. 坚持高强度的学习和持续性的总结

当咱们能够正确的认知一个任务的特征，也能有一个开放的心态和开阔的视野观察问题，也能从问题解决过程当中回收套路进行索引的时候，咱们距离一个技术骨干就差一个习惯了，这个习惯就是高强度的学习和持续性总结的习惯，为何学习要高强度，而总结要持续性呢？

学习是为了输入，知识体系变得有力量必定须要足够的输入，而输入从哪里来，连续作两年 React 框架内的业务代码能够带来沉淀么？其实也未必，若是常年作业务但没有深刻框架内部学习，也没有对框架以内的设计（如数据、状态、交互、异步、更新等等实现原理）更没有对框架以外的意义（组件、API、工具链、维护与封装等成本与效率）有足够的认识，那么所谓的内修基本功是站不住脚的。

至于说高强度，是由于低烈度的输入会伴随着遗忘，更会致使整个学习周期过长，更容易看不到质变而感受枯燥无味甚至弃坑而去，这尤为在新人身上容易发生。若是让我建议一个学习的周期，我以为 1~2 个月的高强度学习，分红 2 ~ 4 个小阶段是可取的，若是 2 个月没有明显进阶，那么须要推倒重来从 0 开始，而不是续命。

伴随着学习的必定是总结，全部的美食入口到胃，长长的肠道蠕动好久后，养分成分才能被机体充分吸取，最终再合成为新的动力之源要么燃烧要么存储备用，这时候的摄入才转成本身身体的一部分。不管是项目开发仍是单纯的学习，都要给本身创建一套 review 机制，经过 review 把本身摄入的零碎的知识点进行重组串联，反反复复的理解消化，并从新输入一套新的知识蓝图把它刻到本身的记忆硬盘中，经过这样的持续性的总结概括，本身的记忆硬盘会的不断的升级调整，最终对于全部知识的理解会愈来愈立体。

小结

以上从准备、过程、心态和习惯上为新人设定了一个骨干长成的路径，但真实的技术开发远远比这个复杂，须要再投入更多的心力精力帮本身迈过去一个个的天花板，所谓打怪升级再升级打怪，对于一个前端新人来讲，在 2 ~ 4 年的工做过程当中，最容易成长为技术骨干，而这段周期最好也有稳定的职场环境和社交环境，避免频繁跳槽，避免受到太大干扰，把握住这段黄金期，随后的技能大树、职场之路会越长越健壮越走越宽阔。

Scott 近两年不管是面试仍是线下线上的技术分享，遇到许许多多前端同窗，因为团队缘由，我的缘由，职业成长，技术方向，甚至家庭等等缘由，在理想国与现实之间，在放弃与坚守之间，摇摆不停，心酸硬扛，你们能够找我聊聊南聊聊北，对工程师的宿命有更多的了解，有更多的看见与听见，Scott 微信： codingdream，也能够来 关注 Scott 跟进个人动态，本文未经许可不准转载，得到许可请联系 Scott，不然在公众号上直接转载，尤为是裁剪内容后转载，我都会直接进行投诉处理。