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

原文出处： Philip Walton   译文出处：赵锦江（@勾三股四） 

译注：本文翻译自谷歌工程师 Philip Walton 的一篇博客。看过以后很是有感触，不少观点都是本身长期很是坚持和认同的，因此翻译出来分享给更多的前端同窗！

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

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

　　不得不认可，被问这样的问题，我很惊讶，由于我历来不以为本身是个很卓越的前端工程师。甚至我入行的头几年时并不认为本身能够作好这一行。我只肯定本身比本身想象中还才疏学浅，并且你们面试个人时候都不知道从何问起。
　　话虽这么说，我到如今作得还算不错，并且成为了团队中有价值的一员。但我最终离开 (去寻求新的挑战——即我还不可以胜任的工做) 的时候，我常常会被要求招聘个人继任者。如今回看这些面试，我不由感叹当我刚开始的时候本身在这方面的知识是多么的匮乏。我如今或许不会按照我本身的模型进行招聘，即使我我的的这种经历也有可能成功。
　　我在 web 领域工做越长时间，我就越意识到区分人才和顶尖人才的并非他们的知识——而是他们思考问题的方式。很显然，知识在不少状况下是很是重要并且关键的——可是在一个快速发展的领域，你前进和获取知识的方式 (至少在至关长的一段时间里) 会比你已经掌握的知识显得更加剧要。更重要的是：你是如何运用这些知识解决天天的问题的。

　　这里有许许多多的文章谈论你工做中须要的语言、框架、工具等等。我但愿给一些不同的建议。在这篇文章里，我想谈一谈一个前端工程师的心态，但愿能够帮助你们找到通往卓越的道路。

别光解决问题，想一想究竟发生了什么？

　　不少人埋头写 CSS 和 JavaScript 直到程序工做起来了，而后就去作别的事情了。我经过 code review 发现这种事常常发生。
　　我总会问你们：“为何你会在这里添加 float: left？”或者“这里的 overflow: hidden 是必要的吗？”，他们每每答道：“我也不知道，但是我一删掉它们，页面就乱套了。”
　　JavaScript 也是同样，我总会在一个条件竞争的地方看到一个 setTimeout，或者有些人无心中阻止了事件传播，殊不知道它会影响到页面中其它的事件处理。
　　我发现不少状况下，当你遇到问题的时候，你只是解决当下的问题罢了。可是若是你永远不花时间理解问题的本源，你将一次又一次的面对相同的问题。
　　花一些时间找出为何，这看上去费时费力，可是我保证它会节省你将来的时间。在彻底理解整个系统以后，你就不须要总去猜想和论证了。

 

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

　　先后端开发的一个主要区别在于后端代码一般都运行在彻底由你掌控的环境下。前端相对来讲不那么在你的掌控之中。不一样用户的平台或设备是前端永恒的话题，你的代码须要优雅掌控这一切。
　　我记得本身 2011 年以前曾经阅读某主流 JavaScript 框架的时候看到过下面这样的代码 (简化过的)：

　　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 的实现是准确的。
　　若是你遇到了这个浏览器兼容性的问题而且发现 Chrome、IE、Opera、Safari 的效果相同而 Firefox 和它们不一样时，你极可能会认为是 Firefox 搞错了。事实上这种状况我见多了。不少我在本身 Flexbugs 项目上报的问题都是这样的。并且这些解决方案的问题会在两周以后 Chrome 44 修复以后被体现出来。和遵循标准的解决方案相比，这些方案都伤害到了正确的规范行为。
　　当同一份代码在两个或更多浏览器的渲染结果不一样时，你应该花些时间肯定哪一个效果是正确的，而且以此为标准写代码。你的解决方案应该是对将来友好的。
　　额外的，所谓“卓越”的前端工程师是时刻感觉变化，在某项技术成为主流以前就去适应它的，甚至在为这样的技术作着贡献。若是你锻炼本身看到规范就能在浏览器支持它以前想象出它如何工做的，那么你将成为谈论并影响其规范开发的那群人。

 

阅读别人的代码

　　出于乐趣阅读别人的代码可能并非你每周六晚上会想到的娱乐项目，可是这毫无疑问是你成为优秀工程师的最佳途径。
　　本身独立解决问题绝对是个不错的方式，可是这不该该是你惟一的方式，由于它很快就会让你稳定在某个层次。阅读别人的代码会让你开阔思惟，而且阅读和理解别人写的代码也是团队协做或开源贡献必须具有的能力。
　　我着实认为不少公司在招聘新员工的时候犯的最大错误是他们只评估应聘者从轮廓开始写新代码的能力。我几乎没有见过一场面试会要求应聘者阅读现有的代码，找出其中的问题，并修复它们。缺乏这样的面试流程真的很是很差，由于你做为工程师的不少时间都花费在了在现有的代码的基础上增长或改变上门，而不是搭建新的东西。

与比你聪明的人一块儿工做

　　我印象中的不少前端开发者 (相比于全职工做来讲) 都是自由职业者，有同类想法的后端开发者并无那么多。多是由于不少前端都是自学成才的然后端则可能是学校里学出来的。
　　不管是自我学习仍是自我工做，咱们都面对一个问题：你并无机会从比你聪明的家伙那里学到什么。没有人帮你 review 代码，也没有人与你碰撞灵感。
　　我强烈建议，最起码在你职业发展的前期，你要在一个团队里工做，尤为是一个广泛比你聪明并且有经验的团队里工做。
　　若是你最终会在你职业发展的某个阶段选择独立工做，必定要让本身投身在开源社区当中。保持对开源项目的活跃贡献，这会给你团队工做相同甚至更多的益处。

 

“造轮子”

　　造轮子在商业上是很是糟糕的，可是从学习的角度是很是好的。你可能很想把那些库和小工具直接从 npm 里拿下来用，但也能够想象一下你独立建造它们可以学到多少东西。
　　我知道有些人读到这里是特别不同意的。别误会，我并无说你不该该使用第三方代码。那些通过充分测试的库具备多年的测试用例积累和已知问题积累，使用它们绝对是很是明智的选择。
　　但在这里我想说的是如何从优秀到卓越。我以为这个领域不少卓越的人都是我天天在用的很是流行的库的做者或维护者。
　　你可能未曾打造过本身的 JavaScript 库也拥有一个成功的职业发展，可是你从不把本身手弄脏是几乎不可能淘到金子的。
　　在这一行你们广泛会问的一个问题是：我接下来应该作点什么？若是你没有试着学一个新的工具建立一个新的应用，那不妨试着从新造一个你喜欢的 JavaScript 库或 CSS 框架。这样作的一个好消息是，在你遇到困难的时候，全部现成的库的源代码都会为你提供帮助。

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

　　最后，但丝绝不逊色的是，你应该把你学到的东西记录下来。这样作有不少缘由，但也许最重要的缘由是它强迫你更好的理解这件事。若是你没法讲清楚它的工做原理，在整个过程当中它会推进你本身把并不真正理解的东西弄清楚。不少状况下你根本意识不到本身还不理解它们——直到本身动手写的时候。
　　根据个人经验，写做、演讲、作 demo 是强迫本身彻底深刻理解一件事的最佳方式。就算你写的东西没有人看，整个过程也会让你受益不浅。

 

Footnotes:

　　Firefox implemented the spec change in version 34 on December 1, 2014. Chrome implemented it in version 44 on July 21, 2015, which means Opera will get it shortly. Edge shipped with this implemented on July 29, 2015. A Safari implementation appears to be in progress.　　You can refer to Flexbug #1 for a future-friendly, cross-browser workaround to this issue.