最近我收到一封来自我的博客读者的电子邮件，里面的一些问题不禁让我陷入沉思，它是这样问的：
你好菲利普，能否告诉我你是如何成长为一个优秀的前端工程师的？
有什么好的建议吗？
我不得不承认看到这个问题的时候我很惊讶，因为我从来就没有把自己看作是一位“优秀的”前端工程师。事实上在这个行业工作的头几年，我一直认为我是不能胜任我所拥有的工作。我申请这些职位是因为我没有意识到我知道的太少了，而能顺利拿下这份工作则是因为面试官不知道该问什么。
话虽这么说，可最后每一份工作我都完成得很好，并成为了团队中的重要成员。当我要辞职离开的时候（接受下一个挑战）,还常常被要求找到一个合适的人来顶替我。回顾我当初面试的时候，只将重点内容放在知识上给了我很深刻的印象。现在的我应该不会聘用之前的我，尽管从我的个人经验来看，胜任还是有可能的。
从事WEB工作的时间越长，我越发意识到能将优秀的人和真正优秀的人区分开的不是他们所掌握的知识，而是他们思考问题的方式。尽管在某些情况下知识很重要，但是在一个快速变化的领域，如何获取知识比你目前已经掌握的知识更重要（至少从长远来看）。也许最重要的是：你如何利用这些知识来解决日常工作中的问题。
现在有很多文章在谈论找工作的时候需要什么语言，什么框架，什么工具。我想换一种方式来谈论，在这篇文章中我将谈论有关前端工程师的思维模式，希望能给这个问题一个永久的答案：如何成为一个优秀的前端工程师？
不要仅仅为了解决问题，弄要清楚问题的根本
很多写CSS和JavaScript的程序员在修改bug的时候，总是一旦修改好立马离开。这在代码审查阶段很常见的。
我会经常问别人：“你为什么要在这里加入float:left;？”或“这里的overflow:hidden;真的有必要吗？”，他们会回答：“我不知道，但如果我删除它，它就不工作了”。
JavaScript中的情况也是如此。我会看到setTimeout被用来防止多线程之间的资源竞争，或者阻止传播那些不考虑对页面上其他事件处理程序产生影响的事件。
我意识到，当你需要完成某一个工作的时候，现在就解决出现的问题当然是好的。但如果你不花时间去了解这个问题的根源，那么你会发现自己将一次又一次地陷入同样的问题中。
花时间去弄明白为什么你的解决方案奏效看似很费时费力，但我保证将来它能节省你很多时间。
对你工作的内容又个一个深入全面的了解，这将意味着在以后工作的道路上能减少很多疑惑和检查工作。
学会预测未来浏览器的变化
一个前端和后端代码的主要区别是后端代码通常运行在一个受你控制的环境之下。相反，而前端则完全在你的控制之外。用户使用的平台和设备随时可能改变，所以你的代码得能够优雅地处理这样的情况。
我记得在2011年的时候看过一个流行的JavaScript框架的源代码，看到以下代码（为了简便起见已作修改）：
var isIE6 = !isIE7 && !isIE8 && !isIE9;
在当时的情况下，IE6的确涵盖了所有的IE浏览器版本，能够处理所有高于IE6的版本
但当IE10出来了之后，程序大部分地方就会功能丧失。
这让我明白，在实际开发中浏览器特征检测并不会100%的准确，有时你不得不依赖的bug行为或使用那些特征检测错误返回误报的白名单浏览器，但一旦你这样做，你就必须得能预测到未来某个时候这些bug将不复存在，这是非常关键的。
对我们大多数人来说，今天写的代码的存活时间会比我们就职于当前工作的时间更久。我8年前写的一些代码，今天依然在一些大型的生产网站运行，固步自封的思想，既令人满足，又让人害怕。
阅读规范
浏览器的bug是不可避免的，但当两个浏览器对相同的代码有着不同呈现的时候，人们往往不去检查自己的代码，就直接认为，那所谓的“好”的浏览器是正确的，“坏”的浏览器是错误的。但事实并非总是如此，当你被这个假设所误导的时候，无论你选择了什么解决方案，将来几乎都会失效。
这方面的一个例子就是flex items的默认最小尺寸问题。根据规范 flex items的min-width和min-height的初始值为auto（而不是0），这意味着默认他们不能缩小到小于其内容的最小尺寸。在过去8个月时间里，Firefox是唯一正确实现这一目标的浏览器。[1]
如果你遇到跨浏览器不兼容并且注意到你的网站在Chrome、IE、Opera和Safari浏览器上呈现是相同的，但在Firefox上却不一样，你可能会认为火狐搞错了。事实上，这样的情况我亲眼见过很多次。在我的Firebugs项目上的许多问题报告就是由于这种不兼容引起的，而提出的解决方法，如果实施的话，会在两周前Chrome44出来的时候失败。不遵从规格说明的解决方法会在不知不觉中损害正确的行为。[2]
当两个或多个浏览器对相同的代码却有不同的呈现结果时，你应该花时间去弄明白哪一个是正确的，然后谨记这一点来写代码。这样你的解决方法才不会在不久的将来成为过时的技术。
此外，所谓的“优秀”的前端工程师往往是那些站在科技前沿，敢于在主流之前先使用新技术，甚至促进新技术发展的人。如果你能培养自己阅读规范和展望技术前景的能力，那么你就会成为影响规范发展的一份子。
读别人的代码
为了乐趣而阅读别人的代码，很可能不是你的星期六晚上的一个好的主意，但它无疑是一个成为一个更好的开发者的最佳途径。
依靠自己的本事来解决问题，是一个学习的好方法，但如果你只这么做，那你很快就会到达你的瓶颈。阅读他人的代码可以帮助你发现解决问题的新方法。阅读和理解代码是团队工作和合作开源项目时必不可少的能力。
其实我认为很多公司犯的最大的错误就是他们在聘请新的工程师时只要求他们写代码——从头开始写新的代码。我从未在任何一场面试中被要求阅读一些现有的代码，去找这些代码中的问题，然后解决这些问题。这真是太糟糕了，因为作为一个工程师你的大部分时间是花在增加或更改现有的代码库上的。很少需要你从头开始构建新的东西。
和比你聪明的人工作
在我的印象中前端开发人员比后端开发人员更想成为自由职业者。也许是因为前端开发人员往往都是靠自学成才的而后端开发人员往往来自正规院校。
但是自学成才和为自己工作也是有缺陷的，那就是你通常不会明白从比你聪明的人那儿学习的好处。不会有人给你建议，也没有人为你检查代码。
我强烈建议至少在职业生涯的开始阶段，一定要进入一个团队工作，尤其是团队中的其他成员比你聪明比你有经验。
如果你在你职业生涯某个时间点，不想只为自己工作了，不妨可以参与到开源项目中。积极参与开源项目能为你提供很多与团队工作相同的好处，有的时候甚至好处更多。
重新造轮子
“重新造轮子”对企业是不利的，但却是最好的学习方式。比如说你想掌握来自于npm的预输入控件或事件委托类库，那么不妨设想一下如果你自己来构建这些东西，你能学到多少。
我敢肯定看到这里一定有人想臭骂我一顿。别误解我的意思。我不是说你不应该使用第三方代码库。使用经过充分测试的库——坐享多年测试案例和bug报告总是明智的行为。
但在这篇文章中，我要说的是如何从良好进步到优秀。在这个行业中大多数我认为优秀的人，都是我们无时无刻不在使用的超级流行的库的创造者或维护者。
可能你也有一个成功的职业生涯———但却不曾构建自己的JavaScript库，那么你可能从未真正接近过它的本质。
很多人会问的有关于这个行业的一个常见问题是：接下来我该构建什么？如果你也问这个问题，那么给你个建议：与其去学习新的工具或开发新的app，为什么不去尝试重建自己喜欢的JavaScript库或CSS框架呢。这样做的好处是，如果碰到问题的话，现有的库的源代码会很直白的告诉你答案。
记录下你所学到的东西
最后但同样重要的是，你应该把你学到的东西写下来。这么做的理由有很多，但最好的理由或许是这能迫使你更好地理解主题。如果你无法解释它是如何工作的，那么很有可能其实你还没有真正地理解。通常只有当你尝试将内容写下来的时候，才意识到自己原来还是没弄明白。
根据我的经验，写作、发表演讲、以及创建演示都是强迫自己从外到内挖掘和充分理解事物的最佳方式之一。即使不会有人来阅读你写的东西，但是写的这个过程绝对物超所值。
脚注：
- 2014年12月1日Firefox在版本34中实现了规格说明变化，Chrome于2015年7月21日添加到日历在版本44中实施，这意味着Opera很快也会这么做。Edge于2015年7月29号发布实施，而Safari似乎正在实施酝酿中。
- 对于这个问题可以参考Flexbug＃1作为适用于未来的跨浏览器解决方案
译文链接：如何成为一个优秀的前端工程师
英文原文：How to Become a Great Front-End Engineer
翻译作者：Jesse
[ 转载必须保留原文链接、译文链接和翻译作者等信息。]
原文链接: https://jesse121.github.io/blog/articles/2017/04/28.html
版权声明: 转载请注明出处.