不久前我收到一封来自我博客读者发来的电子邮件。邮件的内容是这样的。
你好，Philip, 请问您是如何成为一名优秀的前端工程师？您能给我一些建议吗？
我有点惊讶被问到这样的问题，因为我从不认为自己是很“优秀”的前端工程师。事实上，我前几年刚进入这个行业的时候，不认为自己有资格胜任所从事的工作岗位。我只申请这些岗位仅仅因为我当时根本没有意识到自己对这个行业知之甚少，最后得到这个工作机会，也仅仅是因为面试我的人不知道要问我什么问题。
尽管如此，我最终还是在这些工作角色中表现非常好，并成为了团队中重要的一员。当我离开团队时，我通常被分配去招聘我这个岗位的替补。现在回想当时所经手的这些面试时，令我感到惊讶的是，我非常强调知识的重要性，尽管我刚来的时候很缺乏知识。现在的自己可能不会雇佣以前的自己，即使从个人经验上来说，我是有希望成功面试上的。
随着做 Web 的开发时间越长，我越深刻认识到区分“好（good）”和“优秀（really good）”，不在于你知道的多少，而在于你如何思考。显然知识在某些情况下是至关重要的 - 但是在一个变化如此之快的领域，你如何获得知识总是比（至少从长远来看）你所知道来得更重要。最重要的是：你如何利用这些知识来解决日常问题。
网络上有很多文章都在说你需要学习更多的语言、框架、工具才能获得工作。我想换一种不同的方式来谈谈。在这篇文章里，我将谈谈一个前端工程师应有的思维模式，并希望能够对这个问题给出一个更持久的答案：如何变得更优秀？
不仅要解决问题，更要知道问题的本质及其产生的原因
许多人在写 css 和 javascript 程序时，只要程序运行没问题，他们就认为完成了。我知道有这种情况，是因为我常常在做代码审查时看到。
我会问他们：“为什么这里你要加上 float:left ?”，“代码里 overflow: hidden 真的必须用到吗？”，他们会这样回答我：“我不知道，如果我移除这些代码，程序就无法正常工作了”，JavaScript 也是如此。我会看到 setTimeout 被用来阻止竞争条件，又或者有人停止了事件冒泡而不考虑它会如何影响页面上的其他的事件处理程序。
我理解有时候任务紧急，你需要马上实现某些功能。但如果你从不花时间去理解问题的本质根源，你会发现自己一遍又一遍地被同样的问题困住。
花时间弄清楚程序背后的原理似乎很费力，但我保证以后会节省你的时间。更全面的了解你所使用的系统将意味着未来更少的猜测和检查工作。
学习预测浏览器的变化
前端和后端最主要的区别之一是后端代码通常在你控制的环境中运行。前端恰恰相反，完全超出了你的控制。用户使用的平台或设备可能随时完全的改变，你的代码需要能够优雅地处理这些兼容问题。
我记得在 2011 年阅读了一个流行的 JavaScript 框架的源代码，看到了以下行（已简化代码）：
var isIE6 = !isIE7 && !isIE8 && !isIE9;
这个例子中，可能是为了处理早于 6 的 IE 版本。但只要 IE10 出现，我们的应用程序的大部分就完全崩溃了。
我知道功能检测并不总是 100％覆盖到。因此，有时你必须依赖于特定浏览器的错误特征检测或错误行为。 但在这种情况下，学习预测未来浏览器的变化也至关重要。
对于我们许多人来说，我们今天编写的代码将比我们目前的工作任期更长，我 8 年多前写的一些代码仍然在大型生产环境下运行，我感到很满意但也很害怕。
阅读规范
总是会存在浏览器 bug，当两个浏览器渲染同一套代码而产生不同结果时，人们通常会假定：所谓的“好”浏览器是正确的，而“坏”浏览器是错误的。但情况并非总是如此，当你作出了错误的判断，不管你选择什么样的方法，都很可能在未来产生错误。
一个例子就是 flex 元素的默认大小。根据规范，flex 的初始最小宽度和最小高度值是 auto（而不是``），这意味着默认情况下它们不应缩小到比它的内容的最小大小还小。在过去的 8 个月中，Firefox 是唯一能够正确实现此功能的浏览器。
如果你遇到这种跨浏览器不兼容性的问题，并注意到你的网站在 Chrome，IE，Opera 和 Safari 渲染一致，但在 Firefox 中渲染却不同，你可能会认为 Firefox 错了。事实上，我经常遇到像这样的情况。在我的 Flexbugs 项目中提交的许多 Issues 实际上是由于这种不兼容性，并且如果实现了所提议的解决方案，那么在两周前 Chrome 44 发布时，这些解决方案就会失败。
当两个或多个浏览器以不同方式渲染相同的代码时，你应该花时间弄清楚哪一个是正确的，并记住这一点来编写后续代码。这样，你的解决方法将更加面向未来。
此外，所谓“优秀”的前端工程师，他们都是这样的一群人：处于变革前沿的人，在新技术成为主流之前采用新技术，甚至为这些技术的发展做出贡献的人。如果你培养了阅读规范文档，和想象一项技术在浏览器中使用之前是如何工作的能力，那么你将成为开发精英组的一员。
阅读他人代码
仅仅因为有趣，而占用你好玩的周六时光去阅读其他人的代码，这可能不是一个好主意，但毫无疑问这是成为优秀开发者的最好方法之一。
自己独立解决问题是一种很好的学习方法，但如果你一直这样做，那么你很快就到达瓶颈。而阅读他人的代码将会打开你全新的思维方式。此外，阅读和理解他人代码的能力，对于团队协作和开源项目贡献也是至关重要的。
我认为，一个公司在招聘工程师时，最大的一个错误就是让他们从 0 开始写代码。我从未遇到过这样的面试：要求阅读现有的代码，找出其中的问题，然后修复这些问题。这真的太糟糕了，因为工程师的大部分时间都花在了添加代码或更改现有代码库上，很少从 0 开始构建新程序。
和比你聪明的人一起共事
我的印象中，以自由职业者为目标的前端工程师比后端工程师要多，这也许是因为前端开发人员更倾向于自学，而后端开发人员更多是来自正规大学毕业。
自学和为自己工作会带来一些问题，你无法从比你更聪明的人那里获得益处。你没有任何人可以探讨想法或审核你的代码。
我强烈建议，至少在你职业生涯的开始阶段，你要在一个成员比你更聪明，拥有更多开发经验的团队中工作。
如果你最终在你职业生涯的某个阶段选择独自工作，那你最好得重视参与开源项目。积极地为开源项目做贡献可以为你带来许多好处。
重复造轮子
重新造轮子无益于商业，但对于学习却很有帮助。你可能都会从 NPM 下载需要的第三方工具库，但是想象一下，如果自己来写这些库，你将会学到多少知识。
我相信读这篇文章的人会反对我的观点。请别误解我的意思，我不是说永远不要使用第三方代码，而是使用经过测试良好的三方库，是明智的做法。
但这篇文章谈论的是如何从“好”到“优秀”。我认为这个行业中最优秀的大多数人，都是我经常使用的开源项目的创建者或维护者。
在没有创建过自己的 JavaScript 库的情况下，你可能也会有一个成功的职业生涯，but you’ll probably also never work close enough to the metal to really get your hands dirty.
这个行业里的人们经常问这样一个问题：下一步我应该构建什么？如果你也问了这个问题，而不是尝试去学习一个新的工具或创建一些新的应用程序（app），为什么不尝试重新创建一个你最喜欢的 JavaScript 库或 CSS 框架呢。这样做的好处是，如果你遇到困难了，已有库的源代码将为你提供所有的答案。
记录下你所学的
最后，同样重要的是，你应该记录下你学到的东西（写日志、写博客等等方式）。这样做有很多好处，但也许最好的一点是它会强迫你更好地理解你学的这个主题。如果你无法解释某些程序（代码）是如何工作的，那么你自己并不算真正理解它。
从我的经验来看，写作、演讲、做展示一直是驱动我深入理解某些东西最好的方法之一，无论是从内到外。即使没有人读过你所写的东西，但做这件事的过程也是很有价值的。