背景
个人成长 一直是很多同学最为关注的话题,大家也都可以到处看到相关的一些想法:有迷茫的、有焦虑的、有吐槽的、有建议的等等。在最近的一次团队沟通中,也基本上和大部分的同学深入聊到了这个话题,这里也做一个总结和思考。
正文
成长的话题,个人理解,可以分为三个部分:What、Why、How 来依次解析。
What
首先要搞明白的就是,大家所说的成长到底是个什么东西,而不是泛泛而谈,我要成长,要弄清楚、弄明白到底要啥。
那成长这个词的含义,来自百度百科的解释:
成长,一般指长大、长成成人,也泛指事物走向成熟,摆脱稚嫩的过程。简而言之,就是自身不断变得成熟稳重的一个变化过程。
基本解释:
-
长到成熟阶段
-
向成熟阶段发展
-
身体和心理向成熟发展的经历
按照百科的解释,成长本身的含义是:人长大的过程,泛指的是从稚嫩到成熟的过程。敲重点,我觉得成长的最最核心的就是 过程 这两个字,“长大”或者“成熟”更多的是代表的 目标 。
所以从这个视角来看,我们可以把成长拆解为: 目标 + 过程 。 我们一直奔着某个目标一直努力前行的过程,就代表了成长 。
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】等类似的项目。借助于这样的项目以及对应的规则,帮助大家更好的坚持、更深入的思考、也可以认识更多志同道合的伙伴,最终成就一个更好的你!