[译] 如何成为前端大牛

翻译自谷歌工程师PHILIP WALTON的一篇旧文,原文地址:How to Become a Great Front-End Engineer

我最近收到一封来自我博客读者的Email,不管是什么原因,这封邮件让我思考。这是邮件的上写的:

Hi, Philip, 我可否问一下,你是怎么成为前端大牛的?
对此,你能给我一些建议吗?

我有点惊讶,因为我从没觉得自己是前端「大牛」,事实上,在我进入这个行业的前几年,我一点都不认为我能够胜任我所在的工作岗位。我申请到这份工作,第一是因为我无知无畏,第二是因为面试我的人不知道问我什么问题。

尽管如此,我最终凭借出色的表现而成为团队中有价值的一员。当我离开团队时(为了下一个挑战,虽然我还不具备能力)我经常被分配去招聘替补。当我回顾我如何完成这些面试时,令我感到惊讶的是,我非常强调知识——尽管我刚来的时候很缺乏知识。我目前的自己可能不会雇佣我以前的自己,即使从个人经验上来说,我是有希望的。

随着我做web开发的时间越长,我越觉得区分「好」与「优秀」,不在于你知道多少,而是在于你怎么去思考。显然,知识是重要的——在某些情况下非常重要——但是,在一个变化如此快速的领域,在任何时候,你如何获得知识总是比(至少从长远来看)你所知来得重要。总之,最重要的就是:你运用所学知识解决日常的问题的能力。

关于获得工作需要知道的语言、框架、工具之类的文章已经多不胜数了,我想另辟蹊径,从另一个角度来谈谈。在这篇文章,我将会讨论一个前端工程师应有的思维模式,并希望给出更多经得起时间考验的答案,来回答:如何成为大牛?

知其然,更要知其所以然

很多人写CSS和JavaScripit补丁,仅仅止于,程序运行起来没问题就好了。我知道有这回事,因为我经常在代码审查的时候看到。

我经常问一些人,「你为什么在这里加 float:left 呢?」,又或者问:「这个 overflow: hidden 是必要的吗?」他们会回答:「我也不知道,但我把它去掉,程序就不能正常工作了。」

JavaScript的情况也是一样。我会看到 setTimeout 被用来阻止一个竞争条件,又或者有人停止了事件冒泡,全然不顾它会对另一个页面的事件处理产生影响。

我知道有时任务紧迫,你需要马上实现某些功能,你没时间深入理解其中的原理。但是,如果你从不花时间来理解问题的本质,你会发现,你一次又一次地被同样的问题缠住。

花时间来想明白程序背后的原理似乎很费力,但我保证你以后会节省时间的。全面理解你所使用的系统,这样就不用花很多时间在猜测和验证上了。

考虑浏览器的向前兼容

前端和后端一个主要的不同是,后端代码运行在一个可控的环境,而前端却恰恰相反,完全超出你的控制。用户的平台或者设备在任何时候都可能完全改变,你的代码需要完美地处理这些问题。

我记得在2011年的时候,我阅读一个流行的JavaScript框架源代码,我看到以下代码(代码已简化):

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

在这个例子中,IE6是所有版本的一个全部捕获(译注:非IE7且非IE8且非IE9时,isIE6==true),大概能处理比IE6更老的版本。但只要IE10出来,我们程序的大部分都要坏掉。

我理解,在现实情况中,我们不可能一直涵盖所有情况,有时你可以依赖错误处理机制或者白名单中的浏览器,但任何时候考虑向前兼容都是至关重要的。

对于大多数我们来说,我们今天写的代码会比我们保有当前工作的时间还长。我 8 年前写的一些代码仍然在大型生产环境下运行着呢!

阅读文档

经常会有浏览器的bug,当相同的代码在两种浏览器渲染出不同效果时,人们经常不假思索地断定,「好」浏览器是正确的,「坏」浏览器是错误的。但真实情况却常常相反,当你作出了错误的判断,不管你选择什么解决方案,都很可能在未来产生错误。

一个现成的例子是flex元素的默认大小,根据文档,flex元素的初始最小宽度和最小高度是auto而不是0,这意味着默地,它会缩得比它的内容的最小大小还小。在过去的8个月,Firefox是唯一正确实现该特性的浏览器。

如果你遇到了这个跨浏览器的兼容问题,并且注意到你的网站在 Chrome,IE,,Opera 和 Safari渲染正常,但在Firefox却不一样,你很可能会想:Firefox错了。事实上,我经常遇到像这样的情况。
有很多关于这个不兼容的问题报告提交在这个项目上,并提出了解决方案。如果这些方案在两周前Chrome 44 出来时实现了,这些问题就不能再重现了。
因为这些方案依照文档。

当有两个或两个以上浏览器以不同的方式渲染同样的代码,你得想明白哪个是正确的,并且想出你的解决方。

此外,所谓的前端大牛,是这样一些人,他们在新技术成为主流之前拥抱新技术,甚至参与改进这些技术。如果你培养你看文档和想像一个技术是如何实现的能力,你可能会成为精英团队的一员,并且能够讨论和改进文档开发。

阅读他人的代码

阅读他人的代码,仅仅因为有趣,可能不是度过趣味星期六夜晚的好主意,但毫无疑问是成为优秀开发者的最好方法。

自己独立解决问题是很好的学习方法,但如果你一直这样做,你会很快达到你的瓶颈。阅读他人的代码让你开拓思维。另外,阅读和理解他人的代码对于团队协作和开源贡献也是非常重要的。

我想一个公司招聘一个工程师时,所做的最大的错误是只让工程师们从零开始写代码。面试时,我从没有遇到过这样的情况:让我阅读已有的代码,发现代码中的问题,然后将其修复。这真的很糟糕,因为你的程序员生涯中,很多时间只是在添加代码或者修改已添加的代码而已。你罕有时间是从一份已有的代码构建新的程序。

与比你聪明的人共事

在我的印象中,前端开发者比后端开发者更喜欢自由职业。这也许是因为前端开发者更倾向于自学,而后端开发者大多是科班出身。

自学和独自工作都无益于从比你聪明的人那里学习。你没有人可以探讨你的想法,没有人检查你的代码。

我强烈建议,至少在你的职业生涯的开始阶段,你跟一个团队一起工作,特别是成员比你更聪明,更有经验的团队。

如果你最终在你职业生涯的某个阶段选择独自工作,你得重视参与开源项目。积极为开源项目做贡献和与团队协作一样有益于你的成长,甚至更佳。

重新造轮子

重新造轮子无益于商业运作,但对于学习却大有用处。我确信有些人可能会反对我的这个观点。不要误解我的意思。我不是说我们永远不要用第三方代码。使用经过良好测试的第三方库通常都是明智之举。

但这篇文章谈论的是如何从「好」到 「优秀」。很多我认为在这个行业优秀的人,通常是我经常使用的开源项目的创建者或者维护者。

你很可能没有创建过自己的JavaScript库也能有成功的职业生涯,但你永远只是隔岸观火。

从业者经常提的一个问题是:我下一步该构建什么?如果你提了这个问题,而不是尝试去学新的工具或者创建新的app,为什么不重新创造你所喜欢的JavaScript库或者CSS框架呢。这样做有一大好处就是你不会被难题所困住,因为所有的答案都在现有的库里面。

记录你所学

不是最后的最后一点,你必须把你所学的写下来。这样做有很多好的理由,但可能最好的理由是它强迫你更好地理解你所学的主题。对于一些问题,你百思不得其解,但经常你把它写下来,你就理解了。

从我的经验来看,写作、演讲、做展示一直是驱使我深入理解某些原理的最好方法。即使从没有人阅读你所写的,但写的本身就是有价值的。

Was mich nicht umbringt, macht mich stärker

讨论数量: 0
(= ̄ω ̄=)··· 暂无内容!

请勿发布不友善或者负能量的内容。与人为善,比聪明更重要!