技术路线：前端开发已进入深水区

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

Scott 近两年不管是面试仍是线下线上的技术分享，遇到许许多多前端同窗，因为团队缘由，我的缘由，职业成长，技术方向，甚至家庭等等缘由，在理想国与现实之间，在放弃与坚守之间，摇摆不停，心酸硬扛，你们能够找我聊聊南聊聊北，对工程师的宿命有更多的了解，有更多的看见与听见，Scott 微信： codingdream

正文开始

对于普通人，最大潜水深度通常不超过水下 30 米，极限为水下 40 米，超过 40 米就进入到技术潜水的范畴，就会面临各类复杂的危险情况，须要各类装备的集成和系统化的训练才能保证必定的安全性。

• 为何技术晋升愈来愈难了
• 为何高薪资的岗位 Offer 愈来愈难拿了
• 为何公司老是说作技术也要懂业务
• 为何不少团队主管总把价值挂在嘴边
• 为何 What/How/Why 必需要搞清楚
• 为何单纯技术硬很难向前突破了
• 为何前端开发往上走比以前更难了
• 为何我想发力却老是懒于动手
• 为何我趴键盘上看不到明天看不到但愿
• ...

红利已逝，今非昔比。对比 2010 年，整个前端生态已经翻新了好几遍，直到近几年的 Node BFF、IDE Cloud，抑或是客户端 AI，仍是 Serverless 的建设，前端想要深度参与的话，单纯依靠原来的 HTML/CSS/JS 三件套技能也远远不够了，再抛开技术，整个互联网创业生态也重构了好几遍，生意的本质没变，但作生意的理念和方法论以及辅助的工具都发生了巨大的变化。

新的商业环境下就有新的公司组织架构形态，以及新的产品研发流程和合做模式，这些也对今日的前端开发工程师提出更新更高的要求，不管是技术层面仍是意识层面，现在的前端开发已经进入深水区，要在深水区中生存以及捕捞猎物，就须要有深水区所须要的系统化的技能体系以及配套的软硬件能力，以及从浅水区进往深水区所须要的进阶方法论，本文试图向你们传达这样一种观点，但愿带给你们一些启示，不管是新人老人都要居安思危，提早作出储备，以应对新的职场挑战，更灵活的延展本身的职业路线。

本文是小菜前端 TL 内训课程中， 《上手技术管理的初级套路》 这一节里面，关于前端已迎来深水区这个观点的展开陈述，文中会截取几页 PPT 来辅助叙述帮你们理解:

浅水区须要哪些技能

站在 2019 年，一般一个工程师履历中体现的是跳槽历史、参与项目的难度、React/Vue/Angular 等框架底层熟悉度、编程方法论的掌握程度以及职位的变迁等，而在工做中的确与编程强相关的技能有不少（该图是我多年前整理修改而来，有同窗知道出处能够告知我）：

抛开 BATMD 这种大致量的公司，放在市面上任意一个 50 人规模如下技术团队的公司里面，大几率掌握最好的是 IDE/框架/API 这一层，至于代码实现的足够优雅很难保障，更不要提程序设计的娴熟套路、项目背后沉淀的方法论等等，单纯在这张图上打怪升级花个 5 年 10 年丝绝不为怪，而对于前端工程师，这张图的技能点花个 7 年 10 年所有打满打透，此时也差很少三十而立了，而立之年也就是摸到了技术路线的第一个天花板，这个天花板就是技术专家，即使如此，用 10 年时间碰到这个天花板的人依然是极少数，大部分人须要花费更久甚至一直到不了这个高度，这张图上我把它定义成浅水区技能，是肉眼可见的，是能够量化的，是最容易产生共鸣而造成学习动力的，可是放在现在的新商业环境中就显得很单薄了。

为何单薄呢？咱们把图上的能力和知识体系打碎重组，提炼后就是三个关键字：架构、编程、运维，一个是意识和逻辑层面，一个是过程实现层面，一个是环境保障层面，这些能力依然是落纯技术体系内，并无跟外部的商业和职场环境发生多少交集。

深水区须要哪些技能

在深水区，脑海中若是只有编程二字是不够的，就算带一些沟通合做也仍是远远不够，可是不是必定须要深水区技能才能把工做作好，答案也并非，深水区技能是更长期性更深入的，从长期看具有这些特质能够更快更好的跨过技术专家的这个天花板，走到更高的一个 Level，但不具有这些特质也未必会严重影响浅水区的表现。不过当更多同龄人具有深水区能力的时候，只具有浅水区能力的你慢慢就变成了裸泳，而更多更多的新人跳入到浅水区和你一块儿竞争，此时你跟深水区已是隔绝的两个世界，看到的和收获也大相径庭了。

我把深水区的技能，更口语化的总结为： 技术创新、流程优化、团队合做、影响大盘、驱动业务、商业决策和团队管理，以下图：

每个能力的解释我也标注在了图上，再通俗的解释一下：

• 技术创新，从技术面、业务和产品面出发，以技术做为突破点，取得技术上的突破，好比兼容多端的框架研发、客户端浅层次 AI 的实现
• 流程优化，更可能是从产品研发流程上发力，借助向上向下的管理，推进流程变得更高效，好比先后端的接口联调方式、好比产品 PRD 到测试流程的介入更敏捷的迭代方式，多是规范多是工具层面
• 团队合做，这个最好理解也最难作好，一样是从管理和业务的视角切过去，促成团队成员之间有更高层面的共识达成，有更信任的纽带关系，以及有更匹配的使命目标驱动，好比与业务同窗一块儿出差拜访客户，并在过程当中发现更多共鸣点，从而驱动彼此更快调整协做方式，最终为客户解决问题
• 影响大盘，所谓大盘就是公司或者部门的业务大盘，这个必定须要对业务的前景有较为客观深入的认识，而且造成本身的独立判断和决策，去发现业务缺失哪些核心的因素点，并去补全这个遗漏甚至是发现一个机会点，去发掘实现一个新的业务可能性，好比公司的内容生产是一个核心业务，去发现它将来规模化生产会遇到人力瓶颈，有没有可能经过产品化背后的技术能力提供生产力，让业务看到一个新的可能性从而修正整个内容的规划方向
• 驱动业务，与影响大盘不一样，驱动业务更可能是有实质性的推动而不只仅是想法，好比经过配套的埋点监控工具，来捕捉用户一些有意义的行为，从而不断从中发现问题并推进业务去优化解决，或者发现有价值的方向，从而开放这些价值点背后的技术能力给到业务和产品，赋能他们更好的迭代业务流程
• 商业决策，这一点更可能是从数据价值层面，好比可视化不少时候是从前端来主导研发和推动，从各类展示模型中为业务提供更好的决策视角，但在它以前必定是对业务和产品有足够深的理解才会造成有效的决策路径和模型
• 团队管理，这个则是一个很大的话题了，站在组织的视角把团队从弱带到强，从小带到大，从层次不齐带到规矩有章法能冲能创，成为公司具有核心影响力的团队

通过咱们再次简单分析后，能够发现这些技能背后，是四个核心能力，分别是：技术、产品、业务和管理能力，把它们再拆到每一个能力上，按照影响的权重，是这样的对应关系：

大部分仅仅是靠技术都不可能去推动了，甚至技术都未必是它的重要影响权重，好比团队合做、影响大盘、商业决策等，通通这些能力的集合就是一个足够资深的工程师，他能在深水区存活，而且靠此打出一片天所须要的软实力了。

怎么修炼深水区能力

聊清楚深水区对于工程师的 What 和 Why 之后，咱们来聊一聊 How。开始以前咱们必须认识到这些能力不是一蹴而就的，不管是你已经具有了部分能力，仍是丝绝不具有，咱们都要认识到它的习得须要一个过程，这个过程一般就分为这三个阶段：初级练习阶段、渐变娴熟的阶段、质变内化为能力的阶段，在初级练习阶段没有足够的沉淀前，直接跳日后两个阶段都是不切实际的。

首先是初级阶段怎么练习，我把 PDCA 修改后造成这一个作事套路，你们能够参考：

工做中的每一项具体的任务，均可以按照这个路子走一遍，一开始的时候会不适应，甚至有点僵硬的硬套模仿，多来几回慢慢就会成为一种习惯，举个例子：

团队里有不少表单开发的场景，你们的效率都很低，开发很痛苦，我看到这个问题后，就想要作一个复杂表单组件，我首先就是研究各类市面方案，研究公司的业务场景，研究已有的端产品上业务表达的交互表达方式，团队有没有人研究过表单的方案，我去收集相关的信息，而且我也弄明白为何要开发这个表单组件，它能为业务带来实际的价值么，这个表单应该承载什么核心功能呢，作完能推进落地么，我本人能推得动么.... 这个环节就是造成判断决策的时候，也就是捉摸。

捉摸明白后，我开始制定目标，这个要符合 SMART 法则，尽可能的可量化，好比：我要用 2 周时间开发一个表单组件，这个组件要能够被兼容替换到 AB 两个业务的 DEF 三个产品的 10 个页面的交互中，而后开始制定具体的开发计划，哪一个时间点找老板征得赞成，开始定出分几个版原本迭代，每一个版本的周期是几天，每一个版本完成的具体功能是什么，在这个过程当中须要哪些资源，好比架构组同窗的支持，业务组同窗的反馈，交互组同窗的设计配合，产品经理同窗的理解和认同，而后把整个开发过程以可被感知的方式量化出来，透明化出来，这就是规划的阶段。

规划后开始进行技术方案的设计，模块的设计，三方库等等直到编码完成，开始推进组件在匹配的业务线和产品中使用，推进并帮助其余同窗使用该组件，跟踪组件使用的效果并及时的修理 Bug 优化交互等，这个就是执行阶段。

在业务线用了一段时间后，组织一个小小复盘，针对实际应用中的问题作个收集整理，而且把过程当中本身的不足也作一个检视，好比常常忘记跟老板同步进度，常常疏忽其余同窗的吐槽建议等等，另外根据复盘和反馈来确保这个组件的确有提效的价值。

最后是沉淀开发组件的方法论，相应的技术文档（这个每每在开发过程当中就沉淀下来了），以及组件化立项开发的套路，本身我的能力有什么成长，这种能力如何快速复制给其余新手同窗...也就是沉淀 Share 的阶段。

实际工做中的问题，每每比一个组件要复杂的多的多，这就须要咱们更加谨慎的对待每一个阶段，把它们灵活应用并保障每次都比上一次拿到更好的结果，我的每次都比上一次方法论用的更纯熟。

上面抛砖引玉介绍了单纯实现层面能够训练的方法论，这种方法论一样适用了任何能力的练习，但方法论毕竟是方法论，真正决定它们训练结果其实还有一个前置条件，就是你的作事驱动力，也就是能力和意愿的状况。

能力意愿是前置条件

咱们先讲了方法论，让你们更明确的感觉到一些可执行的套路，而后再来看能力和意愿的重要性，所谓能力就是你断定问题和分析解决问题的能力，所谓意愿就是你面对任何一个突入飞来的难题或者任务，心里是抵触、认同仍是兴奋这样的一种情绪。

首先，咱们分析下一个员工的作事动机，一般有这几类：

• 不知道不关心，对这个任务不清楚 what/how/why，也不关心它作不作的价值有多大
• 这么作是由于必须这么作，依然不理解它的价值，但知道这样作是由于我是前端工程师，这是我份内事
• 不这么作会有罪疚感，老板对我有信任，我若是不作好会以为很差意思，心理过不去
• 这么作对我很重要，我认同这件事交给我作的缘由和意义，这件事对个人成长及将来晋升都有意义，我很重视
• 喜欢并专一去作，这件事是我一直以来期待的机会，我很喜欢很想去实现它，我很理解它作好的意义

因此一个同窗有可能作不一样的项目会有不一样的动机，即使作同一个项目的不一样阶段也会有不一样的动机，这是一个彻底主观的事情，可是它很重要，由于不一样的动机会带来三个结果：老板及周围同事经过你作这件事所看出的你的作事态度，这件事你作完达成的结果，以及你由此而得到的成就感或者成长，固然全部的团队都但愿你不管喜欢与否，都至少是理解并执行这个任务：

最怕的是理解不执行和不理解和不执行，最终反映在能力和意愿上，在一个团队的分布中，你就有了不一样的象限，是能力好意愿度高的，仍是能力高意愿度低的，只有意愿高能力高的人才能得到最大程度的受权和自由空间，反之不只得到受权会缩水，甚至必须遵从具体的拆解后的任务去作执行的角色，因此如何让本身不管能力高低，先让本身具有一个高意愿度都是一个明智的选项。

那么存不存在一些事情是无心义的，作了也是白作呢，必定存在，如今这样高节奏的创业环境中，试错始终是一种常态，作一件事而拿不到结果也是常有的事，可是不是所以就否认了组织的动机，从而把本身束缚的愈来愈紧，正面看过去好像本身再也不亏什么了，反过来看本身却失去了进入深水区而该有的历练，这个历练中必定有汗水也有委屈。

面对深水压力不需紧张

其实何止前端开发，整个技术行业都已步入深水区，只是前端工程师的感知来的晚一些而已。只要把眼光投向深水区，问题就会一个接一个的浮上来，当愈来愈多问题浮起来的时候，就是你慢慢沉向深水区的时候，这时候不须要太过紧张，此时的发生正在见证者你的成长，欢迎你们文后提问更多问题，咱们能够再换一期来针对性讨论，本文主要帮你们引导到深水区已然到来，在它之上须要储备技能的必要性和重要性，目的就达到了。