一个前端开发者的自我修养

今天给大家分享的主题是前端的自我成长,这是一个关于成长的话题。

很多人都有这样的感觉:听了很多技术圈子的分享,有的有深度,有的循循善诱,深入浅出,但是呢,几年下来,到底哪些用上了,哪些对自己真的有帮助了?反而有些模糊。

2015 年我在不同的场合分享了很多内容:有移动端的性能、有适配、有 Web vs Native,也有 hybrid,但是其实我一直比较担心,真正有深度的内容,其实面向的是比较小众的群体,比如说 Hybrid,其实它在大部分公司里面,是只能用现成的。

所以我这一次尝试分享一个我认为可以帮助到所有前端的话题,关于前端的成长,如果说这个分享的内容,听众里面有那么几十个人拿到 BAT 的 offer,或者升职加薪,那么我觉得我就认为我取得了成功。

前端其实是个特别苦逼的职业,因为前端技术一直革命的特别快,新技术、新技巧在不断地被发明出来。之前我有一个朋友,他讲说他对自己的认知是了解前端、熟悉前端、精通前端、熟悉前端、不懂前端。为什么呢,他说当他觉得自己对前端所有的东西觉得无所不知,无所不能的时候,忽然看到了一段代码,他完全无法理解,于是整个世界就崩塌了,从此再也不敢说自己会前端。

我就跟他说,这里,缺少的是一种正确的方法,你觉得无所不知、无所不能的标准是什么,是工作中很久没遇到解决不了的问题么?他说还真是这样。我就又问他,那你系统学过前端么?他想了想,还真没学过,大学里不开这个课。的确如此,到目前为止,还没有任何一个大学会教前端,倒是有些培训班,会讲网页开发三剑客。

我这里讲的内容,希望带给大家的,就是该如何学习前端,实现自身成长。

关于成长,首先我得发一个免责声明,不是我对我讲的内容没有信心,而是成长是自己的事,英文有句话,在外企工作的人会经常听到,叫做:

You are the owner of your career.

你是你职业发展的责任人。这句话潜台词是,你(不是你老板,也不是你爸妈,也不是你女朋友)是你职业发展的责任人。

这句话我在我职业生涯的起点听说,一直指导我的职业发展,甚至在我带团队,培养团队的时候,也是中心的指导思想,之前我带的团队的同学,他们有不少人也在带团队,其实他们也在实践这句话,所以我这里,也把这句话、把这个道理分享给给大家。

我们讲前端成长,我认为,主要在两个方面,一部分是“能力”,一部分是“知识”。我个人的观点,能力占百分之八十,知识占百分之二十。

从这个图上,大家可以看到,其实我们认为变化快的东西,最新出来的 Angular、React、ES2015,其实都在知识里面,知识又分成两部分,一部分我把它叫做标准,它是相对而言比较稳定的,很少会出现一个标准被推翻的事情。另一部分则是技术,像是 jQ、React 这些框架啦,像是 MVC、Flux 这些架构的东西,这些东西是由各个公司主导的,变化就非常快,你看
Grunt 发展了没多久,Gulp 就来挑战他了,然后又有 browserify、webpack 这些东西。

而我认为占重点的能力,则是非常稳定的,我认为能力是三大块:编程能力、架构能力、工程能力。

编程能力,就是用代码解决问题的能力,你编程能力越强,就能解决越复杂的问题,细分又有调试、算法、数据结构、OS 原理等这些的支撑,你才能解决各种麻烦的问题。

架构能力,则是解决代码规模的问题,当一个系统足够复杂,你会写每一块,能解决每一个问题,不等于你能搞定整个系统,这就需要架构能力,架构能力包含了一些意识,比如解耦、接口隔离,也包含认识业务建立抽象模型,也有一些常见的模式,比如经典的 MVC,还有设计层面,面向对象、设计模式等等。

最后工程能力,则是解决协作的问题,当系统规模更大,光靠一个人,是没办法完成的,如何保证几个高手互相能够配合好?如何保证项目里面水平最差的人不拖后腿?这个工程化建设,往往会跨越多个业务,以汇报关系上的团队为单位来做。包括前后端解耦,模块化,质量保证,代码风格,等等。

其实不难看出来,这三项,其实是有顺序的,低等级、小团队,编程能力一项就能应付,越资深的前端,越大的公司和团队,越是需要后面的技能,但是这里我要强调一点,其实资深前端,大团队,对能力的需求,是既要还要——不是说资深的前端,编程能力就可以变差。

社区总会有一些声音,对工程能力,对架构能力持有一种抵触的态度,觉得比较虚,觉得不需要。实际上以某些人所在的岗位来说,也没错,毕竟公司、团队的状态确实可能用不到,但是以个人成长的角度来看,就是大错特错。

下面我们来具体讲讲,关于知识的学习。

对知识,我一直有个观点,叫做宁缺毋滥,这个图片上写了一句好前端才分对错,是的,其实很多人,他学习东西的时候就喜欢挑,挑简单的学,书选择最”深入浅出”的,在这种心态下,没有任何一丝学好的可能性,

所以我对知识学习的目标,理解为亮点,一曰准确,二曰全面。当年学习一部分知识,如果你能做到这两点,那你将来在业务上做技术决策的时候,你面对面试官技术问题的时候,信心跟你只看过皮毛是完全不一样的。

怎么做到这两点呢?我想路子肯定有很多,而我的答案,我这里要分享的,是“建立自己的知识体系”。

如何建立自己的知识体系呢?我个人总结的经验,是下面几个步骤:

第一步,寻找线索。

你要了解一个知识,比如我想学 Web 平台的 API 了,当然可以先找一本书,看看别人都写了什么,但是我不喜欢这么干。

我大学里,学前端的东西,为了找个 id 和 name 的区别,曾经要借十几本书来,对比着看,那个时候,是真的没人告诉我,什么书比较好。所以我对别人总结好的知识,第一反应是质疑,不信。

所以我比较推荐,找一些比较准确的,你可以确定它真的足够全面的资料当作线索。对 Web 平台的 API,我就用反射:

浏览器里给出来的这个属性列表是不会骗人的,用这个东西作为线索,我就很有信心。

同样可能比较适合做的资料,还有一些标准文档的附录,和源代码里的结构定义。

第二步,是建立联系。

比如说,看下面几个 DOM 属性:

这里,左边一列是操作 Node 的,右边一列是操作 Element 的,它就存在一定的对应关系。

一般来说,我们找对应关系的方式有以下几个依据:

  • 美感
  • 完备性
  • 操作同一组数据

特别提一下,操作同一组数据,正是面向对象的核心概念,对前端而言,有点不一样的是,所有的 API,根都是 window,所以,其实大部分的 API,可以依据面向对象的数据和操作的观点进行划分。

第三步,是分类。

这里我给出一个实际一些的例子,下图是我对 zepto(移动简化版jQuery),的 API 分类

建立联系以后,我们依据知识之间的联系,进行分类,就可以得到一张图谱,在这个图里面,你就可以非常清楚地知道,哪些知识,是非常重要的,哪些,其实是可以互相替代的。

而一旦有你之前没见过的东西,你又能通过把它放到图谱里,来快速理解它,或者找出一些很好的替代方案。

比如说面试的时候,如果面试官问你 bind 和 unbind 怎么用,你还不会,这时候,如果你心里有这张图,你就不至于一脸懵了,你可以说,虽然我不知道 bind 和 unbind,但是我知道 live 和 die 啊,我又知道 on 和 off 啊。

这张图里我们就可以看出,collection 里面的东西,多半没什么用,而节点操作里,肯定就都很有用。

第四步,是追本溯源。

当我对一个知识体系的全貌有了概念以后,占了全面两个字,接下来需要确认它的准确性。很多知识,在社区,会有很多的争议,该相信谁呢,这是个问题。而我的答案,就是追本溯源,去找它最初的讨论和定义。

有一个真实的案例,就是闭包这个概念,曾经我们很多人的理解都是错的,把闭包和 scope 的概念给混淆起来,认为闭包是函数的执行环境上下文,但是有一个叫做
hax 的(很多人应该都认识他,哈哈),他就对此提出了质疑,认为闭包就是函数。于是我就去查证闭包的概念。

大家都知道,wiki 其实是不准确的,但是其中有一段,基本不会太有问题,就是历史。下图是 closure 这个词条的历史部分:

从这段历史里,我找到了一个名字, Peter J Landin,他是提出者,那么,我就去看看他到底是怎么说的,于是我去 google 学术搜索,找他的文章

果然找到了,于是我们看看原始的文件

这个定义,对应到我们今天 JS 里的闭包,是稍微有点区别的,但是它毫无疑问,是包含了两个部分环境部分和控制(代码)部分,所以其实,闭包就是对应着 JS 的函数,而之前,普遍的观点是认为闭包只包含环境。

所以这个追溯的过程,能够帮我们真正搞清楚对错。

除了 wiki-google 学术搜索的组合,还有一些邮件列表和 github 提交历史,也是非常适合去查证一些概念和技术的历史的。

最后说,我讲的这个建立知识体系的过程,是不断接受新知识,挑战、质疑原有的体系,推翻再重建,每一次循环,你的知识体系都变得更加坚固,更加强大。

下面分享的一部分,是关于能力培养。

能力培养其实重要性很高,但是其实说起来,内容却很少。只有两点: 教材、训练。

对知识学习,我是主张建立自己的体系,不要去相信书,但是对能力培养,我的观点就刚好相反,我觉得能力的体系,恰恰是难以自己建立的,需要教材去指导。这是由两者的复杂程度和变化速度决定的。

想培养能力,就要找经典的教材来学习,像算法导论,The C++ Programming Language这些经典,几十年都没有过时。

注意这里我用了教材,而不是书。

教材和书最大的区别,就是有没有习题。

在我看来,内容再难的书可以一星期读两本,但是教材一定不行,教材一定得花几个月的时间,一边读一边做习题。

于是谈到训练。

其实有个事实是,工作以后,只有极少数人仍然能够做到训练,比如我自己的编程能力,我自觉工作 7、8 年,几乎没有过进步。

训练应该是系统的(需要教材)、主动的,这两个特点不可或缺,有人会觉得,我真的工作很辛苦,每天都要加班,但是其实,任何被动的痛苦,都没法给人带来进步,你的痛苦倒是可能给老板带来更多收入。

如果面临困境,可以选择系统训练来提升自己,但是对大部分人来说,可能更乐于选择一个一个变通的办法: 养成习惯,让工作变得更有挑战。

这个事情其实有不少理论,比较有名的是 Noel Tichy 提出的心理舒适区、学习区和恐慌区。选择一份对自己来说具有挑战性的工作,正面解决问题。

技术圈里流行一个笑话,说的是一个人,工作了三年,却只有一年的经验,因为后面两年都在重复第一年的工作。

所以我们要做的事,就是永远不重复劳动,当你觉得现在的工作,越来越舒适,越来越缺少风险的时候,就应该引起警惕了。

而虽然训练是个很困难的事情,其实大家也不必过于担忧,虽然到处都是“一万小时训练”的言论,现在各大公司的招聘门槛,在我看来应该都卡在几百小时训练的程度。所以我想说,一万小时太久,只争朝夕。希望看到大家成为更好的前端,做更好的自己。

时间: 2024-10-22 22:26:55

一个前端开发者的自我修养的相关文章

论一个程序员的自我修养

在<喜剧之王>中,周星驰扮演的尹天仇,一直梦想成为一名演员,而他不管是在扮演跑龙套,或者在街坊中开设演员训练班,亦或成为主角时,他对待演员的态度,始终是认真,热爱而又投入的.而那一本他随身携带的书--<演员的自我修养>,尽管不知道里面具体写的是什么,但我猜,他对待演员的态度和行为,就是书中内容显示的. 于是,不禁问了问自己,作为一名程序员,一个“程序员的自我修养”是什么? 尽管我们不一定要像尹天仇那么的认真对待自己的事业,但,一些基本的修养,作为一名新时代的码农,总应该是要具备的吧

一个程序员的自我修养

在网上看到一篇程序员的自我修养,深以为然,不禁摘录一些,勉励自己 一个好的开发人员,应该能够全面.高效.严谨的去处理任何软件程序和业务问题,成为一个好的开发,是一个很有意思的话题,不过无论这个话题如何开展,基础两个字必不可少,虽然代码量是衡量开发能力的重要指标,但仅能够熟练的进行代码编写是不够的,更要能深刻的理解技术原理和业务逻辑,扎实的个人基础和技术基础往往会促进代码的编写,更游刃有余的解决问题. 下面说的一些基础,可能绝大部分开发人员都不会在意甚至忽略,但恰恰这些才是开发大厦的基石. 1.科

论一个“程序猿”的自我修养;

首先要谈的是,今天的话题所聊的程序员包含哪些人? 在中国,写程序,不仅仅是一种兴趣,更多的时候,还是一种普通职业和谋生工具 大公司有厉害的程序员,优秀的架构师,但大量的小公司也有很多普通的程序员.在我这些年的工作经历中,也越来越深刻的感受到普通程序员的影响和力量.对于高阶程序员,所谓八仙过海各有神通,各有各的成就,各有各的修养,但程序员在达成较高的水平之前,有一些"自我修养",是最基础的,是普世的. 所以今天的话题面向的程序员,就是所有的正在写代码或者曾经写过代码的程序员,也包括广义上

前端架构的自我修养

1,没有正确的构思往往导致项目前期快,后期慢的特点.甚至大概率会因为考虑不周全,出现中途重构.重写的意外. 2,无法做一个粒度合适的架构(当然不是指事无巨细甚至连样式也要考虑,有一句话叫“架构师不考虑样式”),其实也是winter所说的前端三大能力(代码能力.架构能力.工程能力)中“架构能力”的不足.或者说:只知道埋头苦干,低头走路,没法从全局来考虑事情. 3,架构需要考量很多软件开发规律:如开闭原则.依赖倒置原则.发布订阅模式等等.这些思想是软件的灵魂,也是前人踩了无数坑总结出来的,为无数开发

一个前端开发者换电脑的过程(node篇)

当然,在我们安装了git和vscode之后,我们这个项目,在本地仍然是跑不起来的对吗?这句"npm run dev"就提示着我们需要有一个npm,npm是一个很强大的包管理工具,就像是安卓的应用商店,苹果的app store一样.作为开发者,需要高频率地使用它来安装各种东西. 在很早很早以前,node就已经把npm并入自身安装包的一部分,也就是说,下载了node,就等于拥有了npm.现在我们到node的官网下载它,注意下载msi版本,因为zip版本本人亲测是没有什么卵用的. 因为没有F

论一个职业讲师的自我修养

可能和很多人一样,对于一个对技术感兴趣的人来说,做一名讲师是最让自己放光发热的职业.还记得我还是学员的时候,每次把一些技术弄懂后,总是憧憬着能什么时候把我对一些技术的理解传递给他人,能为他们解惑.很幸运,我现在成为了一名讲师,渐渐的我才体会讲师二字的正真意义. 很多人觉得讲师,肯定是要会讲.其实我觉得如果偏重于会讲,那是销售.讲师除了要会讲,更多的要思考讲的东西是否让别人听懂.如果你说的东西,每个人都能听懂,那是成功者,如果你说的只有几个人明白,可能你是个天才,如果你说的,谁都听不懂,那么朋友,

前端开发者手册

这是任何人都可以用来学习前端的实践手册, 它概述并讨论了前端工程的实践: 该如何学习以及实践时该使用什么工具. 撰写该手册的目的有两个: 一是为潜在以及正在实践的前端开发人员提供一个包括学习资料和开发工具的专业资源; 二是该手册可以被管理者, CTO, 讲师和猎头用来作为洞察前端开发的实践. 该手册的内容支持Web技术(HTML, CSS, DOM, 和 JavaScript), 并且手册提供的解决方案都直接建立在这些开放的技术之上. 手册中所引用的素材和讨论都是最好的或者当前前端开发者们需要面

《程序员的自我修养》系列技术文章整理收藏

整理的一些程序员修炼方面的文章,与大家共勉,有些系列感觉还是很不错的,读来颇受益,一下就是收藏的文章,希望大家喜欢 1思维改变生活:不需要经历也能明白 2思维改变生活:亲身经历了就一定能明白吗? 3思维改变生活:很多事情亲身经历之后才会明白 4工作:不管你愿不愿意,你都要改变 5Doodle:让眼睛一直注视着你的鼠标 6抗干扰的秘诀:分类.整理与专注 7心智模式:认识你自己 8心智模式:如何面对逆境? 9心智模式:心智模式成熟的标志 10心智模式:什么是心智模式? 11心智模式:如何改善我们的心

《Web全栈工程师的自我修养》读书笔记(转载)

[声明] 欢迎转载,但请保留文章原始出处→_→ 生命壹号:http://www.cnblogs.com/smyhvae/ 文章来源:http://www.cnblogs.com/smyhvae/p/5243181.html [正文] 豆瓣链接:https://book.douban.com/subject/26598045/ [目录] 01 什么是全栈工程师 02 如何成为全栈工程师 03 从学生到工程师 04 野生程序员的故事 05 工程师事业指南 06 全栈工程师眼中的HTTP 07 高性能