[转]如何成为一名卓越的前端工程师

标签: | 发表时间:2015-08-12 03:28 | 作者:dxh_0829
出处:http://blog.csdn.net/dxh_0829

译自  Philip Walton 的博客

看过之后非常有感触,很多观点都是自己长期非常坚持和认同的,所以翻译出来分享给更多的前端同学!


最近我收到一封读者来信让我陷入了思考,信是这么写的:

Hi Philip,您是否介意我问您是如何成为一名卓越 (great) 的前端工程师的?对此您有什么建议吗?

我不得不承认,我很惊讶被问这样的问题,因为我从来不觉得自己是个很卓越的前端工程师。甚至我入行头几年时并不认为自己可以做好这一行。我只确定自己比自己想象中还才疏学浅,而且大家面试我的时候都不知道从何问起

话虽这么说,我到现在做得还算不错,而且成为了团队中有价值的一员。但我最终离开 (去寻求新的挑战——即我还不能够胜任的工作) 的时候,我经常会被要求招聘我的继任者。现在回看这些面试,我不禁感叹当我刚开始的时候自己在这方面的知识是多么的匮乏。我现在或许不会按照我自己的模型进行招聘,即便我个人的这种经历也有可能成功。

我在 web 领域工作越长时间,我就越意识到区分人才和顶尖人才的并不是他们的知识——而是他们思考问题的方式。很显然,知识在很多情况下是非常重要而且关键的——但是在一个快速发展的领域,你前进和获取知识的方式 (至少在相当长的一段时间里) 会比你已经掌握的知识显得更加重要。更重要的是:你是如何运用这些知识解决每天的问题的。

这里有许许多多的文章谈论你工作中需要的语言、框架、工具等等。我希望给一些不一样的建议。在这篇文章里,我想谈一谈一个前端工程师的心态,希望可以帮助大家找到通往卓越的道路。

别光解决问题,想想究竟发生是什么

很多人埋头写 CSS 和 JavaScript 直到程序工作起来了,然后就去做别的事情了。我通过 code review 发现这种事经常发生。

我总会问大家:“为什么你会在这里添加  float: left?”或者“这里的  overflow: hidden 是必要的吗?”,他们往往答道:“我也不知道,可是我一删掉它们,页面就乱套了。”

JavaScript 也是一样,我总会在一个条件竞争的地方看到一个  setTimeout,或者有些人无意中阻止了事件传播,却不知道它会 影响到页面中其它的事件处理。

我发现很多情况下,当你遇到问题的时候,你只是解决当下的问题罢了。但是如果你永远不花时间理解问题的本源,你将一次又一次的面对相同的问题。

花一些时间找出为什么,这看上去费时费力,但是我保证它会节省你未来的时间。在完全理解整个系统之后,你就不需要总去猜测和论证了。

学会预见未来的浏览器发展趋势

前后端开发的一个主要区别在于后端代码通常都运行在完全由你掌控的环境下。前端相对来说不那么在你的掌控之中。不同用户的平台或设备是前端永恒的话题,你的代码需要优雅掌控这一切。

我记得自己 2011 年之前曾经阅读某主流 JavaScript 框架的时候看到过下面这样的代码 (简化过的):

  var isIE6 = !isIE7 && !isIE8 && !isIE9;

在这个例子中变量 IE6 为了判断 IE 浏览器版本是否是 6 或更低的版本。那么在 IE10 发布时,我们的程序判断还是会出问题。

我理解在真实世界特性检测并不 100% 工作,而且有的时候你不得不依赖有 bug 的特性或根据浏览器特性检测的错误设计白名单。但你为此做的每一件事都非常关键,因为你预见到了不再有 bug 的未来。

对于我们当中的很多人来说,我们今天写的代码都会比我们的工作周期要长。有些我写的代码已经过去 8 年多了还在产品线上运行。这让人很满足又很不安。

阅读规范文档

浏览器有 bug 是很难免的事,但是当同一份代码在两个浏览器渲染出来的效果不一样,人们总会不假思索的推测,那个“广受好评”的浏览器是对的,而“不起眼”的浏览器是错的。但事实并不一定如此,当你的假设出现错误时,你选取的变通办法都会在未来遭遇问题。

一个就近的例子是 flex 元素的默认最小尺寸问题。根据 规范的描述,flex 元素初始化的  min-width 和  min-height 的值是  auto (而不是 0),也就是说它们默认应该收缩到自己内容的最小尺寸。但是在过去长达 8 个月的时间里,只有 Firefox 的实现是准确的。[1]

如果你遇到了这个浏览器兼容性的问题并且发现 Chrome、IE、Opera、Safari 的效果相同而 Firefox 和它们不同时,你很可能会认为是 Firefox 搞错了。事实上这种情况我见多了。很多我在自己  Flexbugs 项目上报的问题都是这样的。而且这些解决方案的问题会在两周之后 Chrome 44 修复之后被体现出来。和遵循标准的解决方案相比,这些方案都伤害到了正确的规范行为。[2]

当同一份代码在两个或更多浏览器的渲染结果不同时,你应该花些时间确定哪个效果是正确的,并且以此为标准写代码。你的解决方案应该是对未来友好的。

额外的,所谓“卓越”的前端工程师是时刻感受变化,在某项技术成为主流之前就去适应它的,甚至在为这样的技术做着贡献。如果你锻炼自己看到规范就能在浏览器支持它之前想象出它如何工作的,那么你将成为谈论并影响其规范开发的那群人。

阅读别人的代码

出于乐趣阅读别人的代码可能并不是你每周六晚上会想到的娱乐项目,但是这毫无疑问是你成为优秀工程师的最佳途径。

自己独立解决问题绝对是个不错的方式,但是这不应该是你唯一的方式,因为它很快就会让你稳定在某个层次。阅读别人的代码会让你开阔思维,并且阅读和理解别人写的代码也是团队协作或开源贡献必须具备的能力。

我着实认为很多公司在招聘新员工的时候犯的最大错误是他们只评估应聘者从轮廓开始写新代码的能力。我几乎没有见过一场面试会要求应聘者阅读现有的代码,找出其中的问题,并修复它们。缺少这样的面试流程真的非常不好,因为你作为工程师的很多时间都花费在了在现有的代码的基础上增加或改变上门,而不是搭建新的东西。

与比你聪明的人一起工作

我印象中的很多前端开发者 (相比于全职工作来说) 都是自由职业者,有同类想法的后端开发者并没有那么多。可能是因为很多前端都是自学成才的而后端则多是学校里学出来的。

不论是自我学习还是自我工作,我们都面对一个问题:你并没有机会从比你聪明的家伙那里学到什么。没有人帮你 review 代码,也没有人与你碰撞灵感。

我强烈建议,最起码在你职业发展的前期,你要在一个团队里工作,尤其是一个普遍比你聪明而且有经验的团队里工作。

如果你最终会在你职业发展的某个阶段选择独立工作,一定要让自己投身在开源社区当中。保持对开源项目的活跃贡献,这会给你团队工作相同甚至更多的益处。

“造轮子”

造轮子在商业上是非常糟糕的,但是从学习的角度是非常好的。你可能很想把那些库和小工具直接从 npm 里拿下来用,但也可以想象一下你独立建造它们能够学到多少东西。

我知道有些人读到这里是特别不赞成的。别误会,我并没有说你不应该使用第三方代码。那些经过充分测试的库具有多年的测试用例积累和已知问题积累,使用它们绝对是非常明智的选择。

但在这里我想说的是如何从优秀到卓越。我觉得这个领域很多卓越的人都是我每天在用的非常流行的库的作者或维护者。

你可能不曾打造过自己的 JavaScript 库也拥有一个成功的职业发展,但是你从不把自己手弄脏是几乎不可能淘到金子的。

在这一行大家普遍会问的一个问题是:我接下来应该做点什么?如果你没有试着学一个新的工具创建一个新的应用,那不妨试着重新造一个你喜欢的 JavaScript 库或 CSS 框架。这样做的一个好消息是,在你遇到困难的时候,所有现成的库的源代码都会为你提供帮助。

把你学到的东西都记录下来

最后,但丝毫不逊色的是,你应该把你学到的东西记录下来。这样做有很多原因,但也许最重要的原因是它强迫你更好的理解这件事。如果你无法讲清楚它的工作原理,在整个过程中它会推动你自己把并不真正理解的东西弄清楚。很多情况下你根本意识不到自己还不理解它们——直到自己动手写的时候。

根据我的经验,写作、演讲、做 demo 是强迫自己完全深入理解一件事的最佳方式。就算你写的东西没有人看,整个过程也会让你受益匪浅。

作者:dxh_0829 发表于2015/8/11 19:28:01 原文链接
阅读:3 评论:0 查看评论

相关 [卓越 前端 工程师] 推荐:

[转]如何成为一名卓越的前端工程师

- - dxh_0829的专栏
译自  Philip Walton 的博客. 看过之后非常有感触,很多观点都是自己长期非常坚持和认同的,所以翻译出来分享给更多的前端同学. 最近我收到一封读者来信让我陷入了思考,信是这么写的:. Hi Philip,您是否介意我问您是如何成为一名卓越 (great) 的前端工程师的. 我不得不承认,我很惊讶被问这样的问题,因为我从来不觉得自己是个很卓越的前端工程师.

前端工程师技能汇总

- - 博客园_新闻
还记得@jayli 的这幅前端知识结构图么. 缺失源图的我们,无法为此图贡献些什么,随着时间的迁移,或许有些技术点会发生改变,所以有了这个 github 项目. 我们可以通过协作的方式来共同维护这个项目. Git 的历史记录也可以见证前端行业的一些变迁. 尽管会变成文字的方式来维护这些内容,但是我承诺写一个小工具帮大家生成更好玩的图形(基于 DataV 项目).

【xxx】前端技能汇总(Jackson Tian) 前端工程师们,珍重!

- - 王跸西的生命体验blog-WangBiXi.com
Frontend Knowledge Structure 项目起源. 还记得@jayli 的这幅前端知识结构图么. 缺失源图的我们,无法为此图贡献些什么,随着时间的迁移,或许有些技术点会发生改变,所以有了这个github项目. 我们可以通过协作的方式来共同维护这个项目. Git的历史记录也可以见证前端行业的一些变迁.

前端工程师的编码遭遇战

- Zacky - Taobao UED Team
导语:由于历史原因,淘宝网的页面编码一直都是gbk,F2E手册中也有明确规范,刚开始的一段时间,F2E们并未遭遇太麻烦的乱码问题,大家相安无事,但随着淘宝的合作方越来越多,合作方的API接口编码可谓五花八门,淘宝的系统和第三方的数据对接之后就暴露出各式各样的乱码问题. 我想,可能是在做第一个淘宝网的页面时,工程师只顾写代码,而忘了看一看编辑器的默认编码设置,再后来就将错就错直到今天,如果稍微留神,可能就不会犯下这么一个低级错误.

黄锦诚:前端工程师新手必读

- - 博客 - 伯乐在线
公司招了几个刚毕业的学生,作为 重构的新手让我来带. 首先感谢感谢党、感谢国家、感谢公司给了我这样的一个机会,对我工作的肯定和认可,让我带这样的一个重构团队,同时我也明白任务的艰巨,但我一定会将工作做好,不负公司对我的期望. (哈哈,好像从小到大,老师都是教育我们要这样先说的. 在网站的发展史上,初期的网站建设根本不需要网页重构这个职位,WEB1.0时代的网页,只需要 程序员,一堆堆的表格嵌套就完成,或者美工进行配合完成,先由美工负责设计好,再用一些自动化的软件拉伸几下,直接将设计好的图就可以通过软件输出表格的布局了,根本不需要重构这个多余的职位.

支付宝、腾讯前端开发工程师谈实战HTML5

- - 脚本爱好者
如今大热的 HTML5 到底美在哪里. HTML5到底能为实际的移动开发带来哪些改变. 来自支付宝和腾讯的前端开发工程师们有他们自己的看法.   上周,在一场名为“技术风云会”的定期讨论活动中,HTML5小组杭州联盟的同学、阿里巴巴集团 HTML5 爱好者,以及支付宝浙大校友会的会员集中讨论了 HTML5 对前端开发带来的直接改变.

前端工程师的编码遭遇战

- - 博客 - 伯乐在线
导语:由于历史原因,淘宝网的页面编码一直都是gbk,F2E手册中也有明确规范,刚开始的一段时间,F2E们并未遭遇太麻烦的乱码问题,大家相安无事,但随着淘宝的合作方越来越多,合作方的API接口编码可谓五花八门,淘宝的系统和第三方的数据对接之后就暴露出各式各样的乱码问题. 我想,可能是在做第一个淘宝网的页面时,工程师只顾写代码,而忘了看一看编辑器的默认编码设置,再后来就将错就错直到今天,如果稍微留神,可能就不会犯下这么一个低级错误.

前端工程师面试问题列表

- - 博客 - 伯乐在线
前言:@ darcyclarke 在 GitHub 上分享了一个 repo,其中包括了不少前端面试问题,可用于检验潜在的候选人. 绝不推荐在单个候选人身上用上所用的问题(那样会花费好几个小时滴). 从这个列表选择一些,应该能从候选人身上,检测出你所需要的技能. 请记住,下面的很多问题都是开放式的,无标准答案,并能引发有趣的讨论.

前端工程师的价值体现在哪里?

- - 博客 - 伯乐在线
注:原问答贴来自 知乎,由 CSDN整理. 这是一个很老的话题“前端工程师的价值体现在哪里. 有人说:“前端工程师之于网站的价值犹如化妆师之于明星的价值. ”一位好的Web前端开发工程师在知识体系上既要有广度,又要有深度. 当然,Web前端工程师并不是设计师,每天接触最多的是代码,代码,还是代码.