今天, 我们要共同分享的专题内容, 聚焦于前端领域的个人成长与发展进程。这个话题本身, 所探讨的核心要素, 正是关于个体如何在技术与职业道路上实现持续进步与提升的这一重大命题。许多人都有这样一种感受, 那就是, 在听了非常多来自技术领域内的各个方面的经验分享之后, 其中有些内容是具有一定深度的, 还有些内容则是能够循序渐进、耐心地进行引导并且把复杂的道理讲得浅显易懂的, 但是呢, 经过这几年的时间过去之后, 回过头去仔细想想, 究竟究竟哪些内容最后真正派上了用场, 又有哪些内容是对自己真的产生过切实帮助的, 这种情况下反而就变得有些模模糊糊不那么清晰明了了。在2015年, 我在不同的场合分享了很多内容, 这些内容包括移动端的性能、适配、Web对比, 但是, 其实我一直比较担心, 真正有深度的内容, 其实是面向比较小众的群体的, 比如说那个专业领域, 其实在大部分公司里面, 是只能使用现成的东西。所以我这次打算尝试去分享一个我觉得可能对所有前端人员都有助益的话题。这个话题主要是关于前端的职业发展与成长路径。 如果在这次分享活动中, 台下的听众里有那么几十个人能够成功拿到BAT等知名大公司的录用通知, 或者迎来升职加薪的机会。那么从我的角度来看, 我就认定自己是成功了。前端这个职业其实是一个特别苦逼的职业, 因为前端的技术一直在以非常快的速度进行革命, 新的技术以及新的技巧在不断被发明出来。为什么呢? 当他觉得自己对前端的所有的东西都无所不知, 并且什么都能够做得来的时候, 忽然之间看到了一段代码。他对于这段代码是完全无法去理解的, 于是他的整个世界的观念就全都崩塌了。从他那个时候开始以后, 他就再也不敢说自己会从事前端方面的工作的这一些事情了。我就对他讲, 这里的不足之处在于缺了对头的方法, 你认定那种全知全能、啥都行得通的标准究竟是个什么样子, 难道是指在工作中很长时间都没有碰到了搞不定的难题这种情况吗, 他听了之后觉得的确就是这样的道理, 接着我就进一步问他, 那你有没有系统地去学习过前端开发方面的知识, 经过了一番思考之后他也承认确实没有系统地学过, 因为在大学里面根本不开设这方面的课程, 这个情况也是实实在在存在的, 因为直到目前为止, 世间还没有任何一个大学机构会把前端技术纳入到教学体系中去进行讲授, 反而是有一些专门的培训机构, 会向学员传授网页开发中常说的所谓三剑客之类的技能。我所讲述的这部分内容, 期望能够为大家提供一种指引, 告诉大家到底需要怎么做才好去深入进行学习前端相关的技术知识, 并且在这一过程中逐步实现自身的全面成长与提升。关于成长这一话题, 首先我必须发表一个免责声明。这并不是因为我对我所讲述的内容缺乏信心。而是因为个人的成长终究是自己必须去承担和面对的事情。在英语里面有一句话, 那些在外资企业工作的人士经常会听到。您是您的全部事物的主人, 这句话的意思就是您所拥有的一切都属于你本人掌控。你是自己职业发展的责任人, 这句话的潜台词是, 你这个人, 而不是你的老板, 也不是你的爸爸妈妈, 也不是你的女朋友, 是你职业发展的责任人。这句话是我在职业生涯刚开始的时候听到的, 它一直指导着我的职业发展。甚至在我带领团队、培养团队成员的时候, 它也是核心的指导思想。之前我带的下属里有不少人现在也在带团队, 他们其实也在用这句话来实践工作。所以在这儿, 我把这句话以及其中的道理分享给大家。在讨论前端技术发展的时候, 大家往往会提到两个重要的维度, 一个是叫做能力方面的表现, 另一个则是知识储备的积累。根据我自己一直以来的理解和体会来看, 我认为其中的重要性分布大概是大致分为百分之八十为能力, 剩余百分之二十则是属于知识的范畴。大家从这个图上可以看到, 我们一直认为那些变化特别快的东西, 包括最新推出的React, 其实都包含在知识这个领域里面。然后知识又被分成了两个部分, 其中有一个部分, 我会把它称为标准, 标准这个东西相对而言是比较稳定的, 几乎不会发生把某个标准彻底推翻的情况。另一部分则是技术, 像是 jQ、React 这些框架, 像是 MVC、Flux 这些架构, 这些东西是由各个公司主导的, 变化非常快, 你看 Grunt 还没有发展多久, Gulp 就来挑战他, 然后又有了、这些东西。而我认为, 重点在于那些非常稳定的能力。我觉得能力主要就是由三大块组成的: 一个是编程能力, 一个是架构能力, 还有一个是工程能力。所谓的编程能力, 实际上指的就是利用代码来解决问题的这种本事。你的编程能力越强, 就能够解决那些变得更加复杂的事情。在细分这个领域里面, 又有着调试、算法、数据结构以及操作系统原理等等这些内容作为支撑。你必须要拥有这些方面的基础, 才可能解决各种各样的麻烦问题。架构能力, 它是用来解决代码规模问题的。当一个系统变得足够复杂的时候, 你哪怕能把每一块都写好, 能够解决每一个具体问题, 那也不一定意味着你就可以驾驭整个庞大的系统了。这时候, 就需要用到所谓的架构能力了。具体说说这所谓架构能力, 它里面包含了一些必要的意识方面的东西, 比如说要懂得解耦、要做到接口隔离啊等等。除此之外, 它还要求你能去深入理解业务层面, 并且据此建立起抽象模型来。当然, 这里面也包括像那个大家都不陌生的经典 MVC 这种常见模式在里面。还有就是在设计这个大层面的时候, 还得考虑到面向对象这个东西, 以及各种各样的设计模式, 这也都是属于这一部分的。最后一点是关于工程能力方面的这一点主要是为了解决协作方面存在的问题, 当咱们提到的系统规模变得更大的时候, 只依靠一个人的力量是绝对没有办法完成的, 那么应该怎样才能保证好几个高水平的专家之间能够配合得非常良好呢?另外还得想办法保证项目团队里水平最差的那一类人不会因为自身能力的不足而拖累整体进度?这种针对工程化所进行的建设工作, 在多数情况下会跨越多个不同的业务领域, 一般会以在汇报关系上构成团队的这些组织单位作为基本单元来开展实施工作, 其中包含的内容涉及前端与后端在技术层面实现解耦、系统进行合理的模块化拆分工作、质量保证环节的全面把控以及统一的代码风格规范等等。大家其实不难看出来, 这三项内容是存在一定先后顺序的。处于低等级阶段的人, 或者在小团队中工作, 仅凭扎实的编程能力就能应对大多数情况。反过来讲, 如果是一名资历较深的前端开发专家, 身处大型的科技公司且属于庞大的团队编制, 那么他就必须掌握后续所列的其他各项技能。不过, 在此处我需要着重强调一个关键观点, 那就是对于资深前端开发人员以及大团队的架构要求而言, 在能力考察方面实际上是既要、还要的多重要素叠加模式。这并非意味着作为一名资深的从业者, 就可以允许自身的编程基础能力出现下降或退步的现象。在社区里面, 总会有一些人有那样的声音, 那就是对工程能力抱有抵触的情绪, 对架构能力也是抱有这样的态度, 觉得这些内容比较虚浮, 觉得根本就没有必要去掌握。如果站在某些人目前所在的岗位上来做判断的话, 这种想法确实没有错, 那是因为毕竟公司现在的运行状态, 还有团队的具体情况, 可能确实是用不到这些东西的。但是如果从个人自身成长的这个角度来看待问题的话, 这种做法就是大错而特错了。下面我们来具体讲一讲, 关于知识的学习的这件事儿。对于知识, 我一直秉持一个看法, 认为应该宁可缺乏也不要是低质量的, 这张图片上面书写了一句话叫做好的前端才会去区分正确和错误, 的确是这样, 实际上很多人, 在进行学习的时候, 就喜欢进行挑选, 只挑选简单的进行进行学习, 选择书籍的时候就寻找那些写着非常浅显易懂的书籍的内容, 在这种心态的影响之下, 是一点没有学好的一种可能性存在的。所以我, 把知识学习的目标, 理解为两个亮点。一个叫做准确, 另一个叫做全面。当年学习一部分知识的时候, 如果你能做到这两点。那你将来在业务上做技术决策的时候, 你面对面试官技术问题的时候。你的信心, 跟你只看过皮毛是完全不一样的。究竟该如何实现这两项要求呢? 我寻思着, 可行的门道大概有许多条。而我打算在此处与大家进行分享的具体建议则是建立自己的知识体系。要建立一个属于你自己的知识体系, 依据我自己总结的经验教训, 其实是有好多个具体的步骤能够去照做的。首先是去做寻找线索的这个步骤。你要去掌握某一个学问, 好比说你心里头琢磨着, 说我想把那个Web平台上面的API给学明白, 那好吧, 肯定第一步得去找一本相关的书来看一看, 翻阅瞧瞧别的人都在这儿写了啥内容在里面, 不过嘛我不大喜欢这么去做。我在大学期间学习前端技术的时候, 为了搞清楚 id 和 name 这两个东西到底有什么区别, 我曾经向周围借来了十几本书, 把书全都放在一起进行对比阅读去理解, 在那个阶段, 确实没有人专门告诉我究竟哪些书的质量比较好、值得看。所以, 当面对别人已经总结归纳好的知识内容时, 我的第一反应往往是产生质疑的态度, 并且不会轻易地去相信它们。因此, 我更为推荐去寻找那些精确度较高的资料, 这些资料你能够确认它们确确实实具备足够的全面性, 并将它们当作参考线索。针对Web平台上的API处理工作, 我便使用反射技术。浏览器里面显示出来给到的这个属性的列表, 是不会产生欺骗效果的, 利用这个东西当作线索使用, 我就具有了相当程度的确信与把握。同样, 可能还比较适合去弄一些资料, 比如说那些标准文档的附录部分, 还有就是一些源代码里面的结构定义内容。那第二步做的事情呢, 就是建立联系。举个例子, 咱们来瞅一下下面的那些个 DOM 属性吧:在这里, 左边的那一列是用来对 Node 进行操作的, 而右边的那一列则是用来对另一个对象进行操作的, 所以这两者之间是存在一种对应关系的。一般情况下, 我们去找对应关系的时候, 所依据的那些方面, 主要包括下面这些。需要被特别注意的是, 对同一组数据进行操作这件事儿, 恰恰就是面向对象里的那个核心概念。不过在咱们前端这里, 稍微有那么一点点差别。因为所有的 API 它的根节点都是空白的或者是指定路径这个情况, 所以说实际上呢, 大部分的那些 API, 完全可以从面向对象里头的数据层面, 还有那个操作层面这两个观点去分开来看待, 进行划分。到了第三阶段, 这一步的主要任务是进行分类。这里我给出一个实际一些的例子下图是我对 zepto(移动简化版)的 API 分类在建立了联系之后呢, 我们是依据知识之间存在的各种关联来实施的分类操作, 这一系列动作实施完毕以后就可以获取到一张结构化的图谱资料对于身处在该图谱环境中的人来说而言, 你能够非常明确地辨识出其中究竟有哪些特定的知识点构成了核心要素以及扮演着至关重要的角色, 同时在另一方面也可以清楚无误地了解到究竟是哪些具体的内容模块彼此之间存在着相互替代的可能性。而在你遇到此前未曾见过的东西, 并且能够将这个东西放进到你那个已有关于知识的体系里面去的时候, 你是可以借着这种方式来快速地把它的样子和理解给搞清楚, 或者是能够找出一些很不错的替代性办法的。比如说, 在参加面试的时候, 如果面试官问你 bind 和 该怎么用, 而你对此还不太了解, 此时, 如果你脑海中能够浮现出这张图表, 那么你就不会感到一脸懵圈了。在这种情况下, 你可以坦然回应说, 尽管我不太清楚 bind 和 的具体用法, 但是我对 live 和 die 是有一定认知的, 同时, 我也知道 on 和 off 的含义。从这张图中我们就可以明显地看出来, 图像内部所呈现出来的这些内容, 其中大部分实际上并没有产生太大的实际用处, 相比之下则在节点操作流程里面所涉及的这些部分, 毫无疑问每一部分都具备了非常显著的实际使用价值。第四步的工作, 是去把源头和根本的地方进行追溯和研究。在对知识体系全貌形成概念, 并且涵盖了全面这个含义之后, 接下来就要去确认其准确性。众多知识在社区里面存在许多争议, 至于该信任哪一方, 这是一个需要面对的问题。而我的应对方案, 就是追根究底, 去寻找它们最初的讨论情况以及明确定义。存在真实案例, 这个概念以往许多人理解都有偏差, 将闭包与作用域的概念混为一谈, 误以为闭包就是函数的执行环境上下文, 有个叫 hax 的人大家应该都比较熟悉, 哈哈, 就提出了质疑, 他说闭包本质上就是函数, 因此我去核查了关于闭包的准确定义。大多数人心里都清楚, Wiki里面的内容其实并不准, 但是其中有一块部分, 基本不太会出现什么大问题, 那就是关于历史的那一段。下图是词条“这个”里面历史部分的展示图片:我从这一段历史里头寻到了一个名字, 就是Peter J, 他作为那个提出者存在, 于是我就想要去瞧瞧他究竟是怎么讲明的, 就这样我跑到了学术搜索这块地方进行查找, 目的就是为了找到他所写的那些文章。果然找到了于是我们看看原始的文件这个定义, 对应到我们今天 里的闭包, 是稍微有点区别的, 但是它毫无疑问, 是包含了两个部分环境部分和控制代码部分, 所以其实, 闭包就是对应着 js 的函数, 而之前, 普遍的观点是认为闭包只包含环境。因此, 这种回溯调查的手段方法, 可以协助我们彻底地将正确和错误这两个方面的具体事实给厘清并确定下来。除了使用 wiki 这种学术搜索组合以外, 还有非常多其他的内容形式也是非常适合去查证一些概念以及技术的发生历史的, 这些内容形式主要就包括了那些邮件列表以及系统的提交历史文档。最后再说, 我刚才所讲的这关于建立知识体系的过程的事情, 它是一个不断接受新知识, 它要对原有的体系进行挑战, 它要质疑那原有的体系, 它要去推翻然后再去重建, 这每一一次循环下去, 你的这个知识体系啊就变得越来越坚固, 也变得越来越强大。接下来要分享的内容, 是涉及到怎么培养能力这一块。能力培养的重要性是非常高的, 可是说到的时候, 具体的内容就太少了只有两个点, 一个是教材, 另一个是训练。在知识学习这茬儿上, 我倒是觉得要建起自己的一套逻辑框框。千万别轻信书本上的说法。不过, 要是说到能力培养, 我的想法就完全反过来了。我看能力的积累, 特别难靠自己去瞎琢磨出来个模样。这时候就得依靠教材来带节奏和指路。之所以会分化出这么两码事, 说白了, 还是因为这两者的里头门道复杂程度不一样, 另外它们变化的速度也压根儿不是一个量级。如果想要培养自身的能力, 那么就应当去寻找那些公认的、经典的教材来进行深入学习, 比如说《算法导论》以及 C 编程语言相关的经典书籍等等, 这些内容在长达几十年的时间长河里, 都始终没有失去其应有的价值和地位。在这里我是使用了教材, 这个做法跟使用书本是完全不一样的。关于教材和书之间最大的不同之处, 其实就是看它是否包含有习题。从我这边的看法来说, 不管书里的内容有多难, 都可以用一个星期的时间把两本的阅读任务完成掉。但是这种情况针对教材是绝对不行的, 教材这类学习材料一定非得花费好几个月的时间来对待不可, 在这样漫长的时间里既要进行阅读同时还要伴随着做习题这一环节。于是接着就开始谈论起了关于进行训练的事情。其实有一个事实是明确的, 就是在参加工作之后, 只有非常少数的人仍然能够坚持进行训练。就拿我自己的编程能力这个例子来说吧, 在我看来, 即便是在工作之后的这七到八年的时间里, 我几乎也谈不上有什么实质性的进步。训练这一事应当是系统的, 这意思就是说需要教材参与进来同时呢也必须是主动去进行的, 这两点都是绝对不可缺少的东西, 有人会觉得, 我确实工作是非常辛苦的, 几乎每一天都要去加班, 但是其实情况会是怎么样的, 凡是那些属于被动的痛苦, 是完全无法让人获得任何进步的, 而你在那里的痛苦表现倒是有可能给你的老板带来更加多的收入。当一个人碰到了困难的时候, 他或许会挑一种由系统来主导的训练方式去努力把自己变强。然而对于绝大多数的人来说, 他们更加心甘情愿去尝试那种把复杂的事情拆分成小块、逐一应对的灵活解决办法。这就好比去培养某些固定的行为准则与日常规律。通过这样做的目的, 是让原本可能会让人觉得单调的工作, 增添一些值得去迎接的全新难度和趣味性。关于这事儿, 其实背后有不少理论在支撑, 其中比较有名的一个是Noel Tichy提出来的。他划分出了心理舒适区、学习区和恐慌区这几个概念。所以, 选择一份对自己来说具有挑战性的工作就是正确的方向。在这个过程中, 你要正面地去解决遇到的各种问题。在技术圈里面, 大家经常讲这样一个笑话, 这个笑话说的就是某个人, 他虽然在岗位上一共工作了差不多有三年那么长的时间, 可是实际上他只具备一年的工作经验, 产生这种现象的主要原因是因为在后面的两年时间里, 他所做的事情其实一直都在重复第一年曾经工作时的内容。我们应当去做的那种事情, 就是一直都不要去进行重复性的劳动。当你发觉现在所做的工作, 变得越来越舒适, 变得越来越缺乏风险了之的时候, 你就必须引起警惕了之。虽然训练这个过程做起来很困难, 可是大家其实也没有必要去过度担忧。尽管现在到处都在说“需要一万小时的训练”, 但在我看来, 目前各大公司的招聘门槛, 我觉得应该只是卡在了几百小时训练的这个程度上。所以我认为一万小时时间太久了, 我们应当珍惜眼前的时光。我希望能够看到大家都成为更好的前端工程师, 去做一个更好的自己。