著作权归作者所有。商业转载请联系 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，否则在公众号上直接转载，尤其是裁剪内容后转载，我都会直接进行投诉处理。