思考-个人成长(面向前端,也不只是前端)_前端小白-Mr鹏帅

背景

个人成长一直是很多同学最为关注的话题，大家也都可以到处看到相关的一些想法：有迷茫的、有焦虑的、有吐槽的、有建议的等等。在最近的一次团队沟通中，也基本上和大部分的同学深入聊到了这个话题，这里也做一个总结和思考。

正文

成长的话题，个人理解，可以分为三个部分：What、Why、How 来依次解析。

What

首先要搞明白的就是，大家所说的成长到底是个什么东西，而不是泛泛而谈，我要成长，要弄清楚、弄明白到底要啥。

那成长这个词的含义，来自百度百科的解释：

成长，一般指长大、长成成人，也泛指事物走向成熟，摆脱稚嫩的过程。简而言之，就是自身不断变得成熟稳重的一个变化过程。

基本解释：

1. 长到成熟阶段

2. 向成熟阶段发展

3. 身体和心理向成熟发展的经历

按照百科的解释，成长本身的含义是：人长大的过程，泛指的是从稚嫩到成熟的过程。敲重点，我觉得成长的最最核心的就是过程这两个字，“长大”或者“成熟”更多的是代表的目标。

所以从这个视角来看，我们可以把成长拆解为：目标 + 过程。我们一直奔着某个目标一直努力前行的过程，就代表了成长。

Why

弄明白了成长到底是个啥，还要弄清楚为什么，就是为什么我需要成长。很简单，为了你的那个目标。

拿自然的人长大来讲，从小到大，你需要一直吃饭、补充营养、还需要不断学习各种技能，直至一般大家所说的18岁成年。那这个过程到底是为啥呢？是生物的本能？当然是，“人是铁饭是钢，一顿不吃饿得慌”，生物本身决定了你就必须吃饭，必须喝水，这样你的身体才能够成长。还有其他原因吗？当然，你的各种学习，除了模仿之外的技能学习是为了啥，小的时候其实我们是被逼着去学校学习的，长大一点后，我们是为了我们可以有更好的生活，人生可以变得更加精彩。

更直白、更狭义的理解：可以是利益驱动，成长了可以获得更丰厚的报酬，为什么可以有更丰厚的报酬呢？这是因为你可以承担更大的职责。为了这个职责的承担，你需要不断的学习各种技能，当有机会来临的时候，你可以把握住。你会发现，这是一个正向循环，如同游戏或者小说中的打怪升级。

听起来有一点点鸡汤的味道，用经典的话来讲就是：“活到老学到老”、“学无止境”。推荐大家仔细看看《终生学习》这本书。

How

职业规划-目标

在探索怎么成长之前，需要有一个基础，我们的目标是啥，对于程序员而言，你的目标是啥，对于前端而言，你的目标是啥。这个也就是大家日常所讲的，你需要有自己的长远的职业规划。

对于程序员而言，你的职业规划是哪个：技术专家、架构师、带团队、技术管理者、项目管理、业务产品专家等等。当然还可以是转行，甚至都不在互联网行业。

如果你还没有一个长远的规划，即长远的目标，那么就要认真考虑了，这个也是很多同学没有动力的最核心原因。当然，对于工作经历较少的同学，可以暂时没有这个长远的规划，但一定要有一个短期的规划，给自己一个清晰的目标。

推荐每个同学都有一个清晰的职业规划，为什么？因为可以试想，10年后的自己，看着自己的简历，有很多的经历，做了很多项目，用了哪些技术，如果都是流水账式的，没有核心的思考和技术，那么那个时候自己的竞争力来自于哪里，这也是为什么会有“中年危机”，为什么会有“程序员是吃青春饭”等等的焦虑话题。给自己一个长远的清晰目标，这样才会促使你不断前行，不断进步，不会成为那个“被后浪拍在沙滩上的前浪”！

对于普通程序员而言，我们期望的成长，最核心的有两部分：技术能力的成长和综合能力的成长。

• 技术能力（前端）

  • 技能图：基础、框架、组件/库、Node.js、工程化、性能/效率、安全、质量、新兴领域、其他领域（可视化、游戏）等，仅做参考。

  • 核心：基础知识的掌握，一定放在第一位的，如HTML、CSS、JavaScript，常见的数据结构、算法、网络等。

  • 操作：做自己的技能图，逐步完善和持续点亮。

• 综合能力

  • 技能图：项目管理、设计交互、沟通协作、owner思维、业务领悟能力、产品能力、带人能力等等，仅做参考。

  • 核心：理解业务、理解产品、理解设计交互、基本的沟通协作、基本的项目管理。

  • 操作：多观察、多思考，向优秀的专业同学学习。

那这个过程中，你自己到底如何努力，精力有限，如何选择？这个就要回归到职业规划上，也就是我们的目标。个人建议，可以把目标划分为两个阶段：一个是资深研发、一个是你决定的职业规划目标（技术专家、管理者等等）。

• 资深研发

  • 目标：期望可以在3-5年的时间里成为一名solid的资深工程师。

  • 解释：搞定所需的核心技术能力和综合能力。

• 职业规划目标

  • 目标：你所选择的职业规划目标，如专家、架构师等等。

  • 解释：有了前边的资深的基础，自己具备了一定的根基，不管去继续深耕还是横向的扩展，你都具备了一定的去迁移的能力。

这么拆分的原因是啥呢？一个是筑根基、一个是建高楼。

根基，是为了未来的高楼，不管建什么高楼，总是需要扎实的根基在的。我曾经见过一个有了多年经验的同学写，事件的绑定和解绑操作，为了处理 this 问题用了bind，但是没有真正理解bind的真正含义，也没有理解事件绑定和解绑的条件限制，做了无用功：on(xx.bind(this));off(xx.bind(this))。这就代表了基础的部分是有问题的，当然这里是举例，如果只是一个基础点掌握的不牢固还好，那如果是很多基础都不牢固，将来去做“高楼”：搞库、搞框架设计、搞SDK等等，是一定会出问题的。

高楼，相对应的就是你的长远的职业规划，在建高楼的过程中，我们不仅需要低头一层层的去建，而且需要经常抬头看看，离自己的规划多远，有没有跑偏，适当休息，多多调整自己。

那，似乎讲了很多，核心目的就是为了让大家认清自己的规划，合理规划自己的目标。

怎么做-坚持

怎么做，有没有方法？当然有，但是不管是哪个方法，最核心的也是最难的部分-坚持。最难的就是坚持本身！

我们先做好这个预期：让自己沉下来，耐心些，不浮躁，一步一个脚印。

这个也是有方法论基础的：10000小时的刻意练习理论。刻意练习的最核心是啥？是练习吗？不是，最核心的是刻意两个字，刻意代表的是这个过程中除了坚持做之外，还有思考，这个才是我所理解的刻意练习的核心：坚持+思考。

为什么需要这样一个预期，回到成长的定义的核心关键点：过程。成长是一个过程，它不是结果或者最终的目标，而是为了目标前行的过程。所以说，一定要坚持，并且要思考。

还有另一个关键点，需要深刻的认识到：成长的目标对象是自己，所以成长需要靠自己。当然，也不要钻牛角尖，也需要“站在巨人的肩膀上”，同时深知“师傅领进门，修行靠个人”。

那扯了这么多，都是我们坚持行动之前的思考，是思想层面的。接下来“不扯虚的，来点实际的”。

我们的日常其实一直都在做业务开发，已经这么繁忙了，哪有时间学习，让自己成长？翻译一下就是：怎么能够在业务开发中获得成长？

个人理解，答案就是：主动学习，具体的思路就是，由点及面，最终构建属于你自己的专业体系，建议这个体系是自己做一个脑图，这个图是一个面，它由一个个的技能点构成（当然，技能点本身也是可以是一个面）。

那具体该怎么做呢？我所理解的是，从你日常工作中所涉及的开始，逐步去辐射。当然，除了我们项目本身，你也需要对社区保持关注，有哪些新的东西，只需要了解即可，核心还是自己工作的周边。接下来结合前端本身的场景，来看一些实际一点的例子。

首先肯定是对于基础的学习，尤其是基础还不是那么牢固的同学，那这些基础哪里来？来自于你的项目。

• 项目

  • 涉及到的知识点，如：

    • 用到了 JavaScript 相关：变量声明、Promise、Map、Array、闭包、原型等等，这些可能是 JavaScript 中最基础的部分：语法、变量、运算、数据类型、函数、对象、事件、作用域、原型、异步、错误等等

    • 用到了 BOM、DOM 相关：window、navigator、元素、属性、操作等等

    • 用到了 CSS：display、position、overflow 等，那么这些 CSS 基础：选择器、层叠、盒模型、文本、颜色、BFC、定位、Flex 布局、层级、编号、过渡、动画、自定义属性等等

    • 用到了 HTML：div、span 等，你需要了解：哪些标签、标签的作用是啥、语义是啥、自闭和标签是啥、嵌套规则是啥 等等

  • 项目架构

    • 项目分层是啥样的：基础依赖、工程化、SDK、组件库、构建上线或者持续集成 等等

    • 每层中包含的内容：封装的一些SDK的设计、细节，组件库中有那些组件、功能是啥，构建上线做了什么事情、怎么演化而来的，基础依赖、框架 Vue、React 以及相关的周边生态了解程度如何

认真研究你会发现，太多太多基础的东西需要你去花时间和精力掌握他们，这些是根基的部分，需要掌握牢固。研究完这些，你会发现：原来我们的基础包中的沉淀，真的是经过时间的考验，慢慢积累的，踩坑踩出来的；框架的形成或者实现本身也是强依赖很多基础的掌握：数据结构、算法、前端基础 等等。

举一些例子：

• 对于 url parse 解析场景，是需要考虑到值包含=问题的，虽然理论上是应该转义的，但是实际场景很多情况下还是没转义的，如果让你写，怎么解决，直接split 吗？

• absolute left 50% + translate -50% 实现水平居中，文字会提早换行？

• 我们内部的 Biz DLL 方案，多了请求会不会让项目初始的请求数超出6个，怎么上传 CDN 的，怎么做到使用方无感知的？

• 框架 Vue、React 做了哪些事情，他们背后依赖的知识有哪些（队列、栈、链表、编译器、DOM 等等）？为什么他们可以大大提升我们的开发效率，提升项目的可维护性？

其次是思考，从哪里思考？答案还是你的项目。

• 项目

  • 业务产品上的：背景，要解决的问题，哪些收益

  • 设计交互：完整的流程、交互流畅吗，成本怎样，这个步骤可以省略吗？

  • 技术上的，如：

    • 这个布局可以有其他实现吗？这段超长的 if else 逻辑可以优化下吗？这个组件太大了可以拆分下吗？

    • 技术分层是啥样的，这样有啥好处、有啥坏处？

    • Biz DLL 这个方案又和 webpack 的 Module Federation 的异同是啥？

    • 你用的框架背后的实现，哪些考虑和取舍？

  • 项目流程：前期沟通、需求评审、技术评审、排期、接口文档、测试Case评审、提测Show Case、上线、线上回归、灰度、效果评估等等，为啥有这么长的流程，有啥作用？

  • 项目管理：需求拉齐、日会、周会、风险管控、协作依赖等等，做这些有啥好处，能保障项目如期上线吗？真的上不了怎么办？

这些都是源自于你所做的项目。这里边对于不同阶段的同学，所要抓的重点也不一样，也就是你要学会如何高效学习。

时间精力有限的情况下，怎么高效学习，就需要有自己的判断，抓住重点。对于刚毕业的同学或者经验较少的同学，还是建议把核心的重点放在基础上，这个也是你去面试的时候一面甚至是二面考察的重点；基础搞定了，再来看框架、性能、方案。

在初级阶段，比较高效的还是看经典书籍、看优秀视频、看优秀课程，然后和自己的练习或者项目实践相结合，互相印证、互相反哺。这样既能让自己掌握基础知识的全貌，也可以有正确的理解和应用，最终可以让自己的基础知识是比较系统、比较完整的。

在高级阶段，你已经对基础的知识有了一定的掌握，可以去看规范，阅读优秀的源码，去负责更复杂的项目，学会如何拆分、如何设计、如何协作、如何解决难题。

自己当年为了攻克CSS，去研究了CSS 2.1的规范，翻译他们，自己做实验和demo理解他们，全部完成之后，很多效果和布局，你都能理解背后到底是为啥，而不是一次次的去试，停留在模糊的理解上，换一种场景可能就又实现不了或者不能理解。

这里就不得不重点说下，学源码的这件事情，这个是被很多人认同和推荐的高效学习手段之一，看源码究竟是为了啥？有什么高效学习源码的办法吗？

我们都知道研究源码是一件十分耗费精力、且枯燥的事情，很容易中途放弃，尤其是针对于一些复杂的项目的源码。那我们学习源码的性价比也太低了些，相当低，你花了那么久的时间和精力，到底为了啥，为的是面试？不，终究还是回到自身，为了自己的成长，能够有所收获。

我自己定义的源码研究三个阶段：知其逻辑、体其精粹、融为己用。更多的时候，大家停留在第一个阶段，借助于【The Good Parts】项目就是期望大家能够往前一步，不求融会贯通，但求更进一步的深入思考，可以学到更多、思考更加深入。甚至于从个人成长的视角出发，第一个阶段能做到的就已经很可以了，讲实话，但是我们还是要追求性价比，追求学习效率。

融为己用本身的情况太过于量化，需要不断的实践，当然，这个里边也是有一个近似的做法：造轮子；这里的造轮子并不是为了让别人用或者让团队用，而是自己根据之前的研究和收获，从头做一个完整的轮子来实践自己的收获。这里边也是可以分为两个阶段：模仿和独立设计。

说到研究源码，最近我们做了 Vue2 的一些源码分析的文章，会有一些说“落伍了”声音。这个就是对源码分析的事情所产生的误解，我们看源码、研究源码的目的不明确，源码分析是为了研究他们的逻辑？还是为了追求时髦？最最核心的是，我们研究他们是为了学习，为了巩固我们的基础知识，加深理解，例如队列、栈、线程、进程、闭包、原型等；研究过程中学习其拆分、设计、模式，学习其技巧、思路、思想，学习其文档、示例等等。而且，这是你当下在你的项目中所用的，你研究了，对你设计代码、解决疑难杂症、性能优化、复杂场景的方案设计都有极大的好处，性价比很高，解决问题了的同时你也可以获得满满的成就感。不要为了看源码而看源码。看源码一方面是为了知道框架的逻辑，更多的却是为了巩固自己的基础，加深理解，融会贯通。这个也就是相对应的三个阶段：知其逻辑、体其精粹、融为己用。

在资深阶段，是需要自己有一定的架构设计能力的，在高级阶段，其实你已经有了一些思考了，到了资深阶段你需要更系统的去思考问题、思考痛点，怎么去解决他们，慢慢的去培养自己的发现问题、分析总结问题、解决问题的能力。从结果来看，一些沉淀、方案、框架等都是思考而来的。那么我们到底该怎样去思考呢？

就前端而言，有三大方向需要我们去重点解决：效率、稳定性和性能，我们可以从这三个方向去做一些思考。举一些身边的一些例子：

• 效率角度

  • 组件库 UI 库，典型的从效率出发，实现组件的复用，提升效率的利器

  • mpx的运行时渲染、mpx-cli@next，就是从效率出发去思考，怎么样可以让小程序开发更快，做工程化更容易、更快速，这里边是有很多的思考和取舍的

  • 帮助业务更容易投放、更好看清数据所做的系统，可以大大提升运营同学效率

• 稳定性角度

  • 构建脚本中增加一些check编译后代码的能力：如存在ES6代码、Polyfill问题等等，成功阻止了多次线上事故的发生

  • 基础库、基础组件库，做单测，尽量做到高覆盖率，保障稳定性

  • 做自动化测试工具，降低项目回归成本，同时很好保障稳定性

  • 做系统级别仿真环境，进一步保障稳定性

• 性能角度

  • Vue 中 v-for 循环中比较容易带来性能问题，总结形成最佳实践：多循环下可以使用子组件进行空间换时间的优化

  • 无限滚动组件，解决大列表情况下性能问题

  • Biz DLL方案，解决两个性能：构建性能和线上运行时加载性能。这个和 webpack 的 Module Federation 所探索的一些方向本质上是类似的。

从以上三个大方向去思考：目前项目开发存在什么样的问题、哪些痛点，可以是从流程上、规范、技术等视角去出方案去解决；当然，这些也是建立在你了解你的业务、你的项目、项目所用的已有的沉淀、相关协作流程、规范等之后才能有一个更为全面、适配性更好的方案或者解法。这样就形成了一种持续进化，个人在进化，整体团队也在进化！

最后，也就是专家、架构师级别了，如果你能解决多个方向的或者领域的难题，那你绝对已经成长为了专家了。

这里有个点就是，我们所说的架构师是做啥的？或者说架构是为了解决什么事情的？或者架构能力究竟指的是啥？个人来看，从技术视角，这个答案就是：架构师通过设计架构优雅地解决现在以及未来复杂的业务技术问题。何谓优雅：简单、可靠、合理。

总结

以上，就是自己关于成长的个人总结和思考，重点：

• 认清：成长是一个过程，目标对象是自己

• 态度：一步一个脚印

• 行动：坚持+思考（不要一直埋头，也要抬起头来，看看自己、看看别人、看看社区、看看世界）

而对于团队而言，我们能做的就是提供一个机会、规则或者渠道帮助大家更好、更快地成长，所以我们也才有了【技术研讨会】、【The Good Parts】等类似的项目。借助于这样的项目以及对应的规则，帮助大家更好的坚持、更深入的思考、也可以认识更多志同道合的伙伴，最终成就一个更好的你！