最近，我的一个博客读者给我发了一封电子邮件。内容是：

你好，请问如何才能成为一个伟大的前端工程师？
你有什么好的建议吗？

这让我不由得陷入思考中。我不得不承认看到这个问题的时候我很惊讶，因为我从未真正觉得自己是一个“伟大”的前端工程师。事实上，在这个行业开头几年时间里，对于我的每一份工作，我甚至可以说我都是不合格的。我申请了这些职位——我没有意识到自己懂得其实并不多，然后又因为面试官不知道该问什么问题，又让我通过了面试得到了工作。

话虽这么说，但最后每一份工作我都完成得很好，并成为了团队中的重要成员。甚至于当我要辞职的时候（奔赴下一个工作挑战），我通常还会被要求负责找到合适的人来顶替。回想我当初的面试——只将重点放在知识点上——我简直要被自己蠢哭了。现在的我根本不会聘请以前的自己来担任这个职位，即使从我个人的经验来看——我依然胜任了这个职位。

在网络上工作的时间越长，我就越发意识到，能将优秀人才和真正优秀人才区分出来的不是他们知道什么，而是他们是如何思考的。显然，知识很重要——在有些情况下甚至是关键的——但在一个变化迅速的领域，如何去获取知识更重要（至少从长远来看）。也许最重要的是：你如何利用这些知识来解决日常问题。

现在有很多的文章大谈特谈找工作需要什么语言、什么框架和什么工具。我不愿意走这条已经走烂了的道路。所以在这篇文章中，我会谈谈前端工程师的思维模式，希望能够解决一个永恒的问题：如何成为一个伟大的前端工程师？

不要只解决问题，要弄清楚到底发生了什么

很多用CSS和JavaScript的程序员碰到问题时，会一头扎进去，但一旦发现某种解决方法有效，就立刻马不停蹄地进入下一个环节。这在代码审查环节已经是司空见惯的情景。

我经常会问：“你为什么要在这里添加float: left？”或者“此处的overflow: hidden真的有必要吗？”，对方回答：“我不知道，但如果我删掉的话，它就不工作了。”

JavaScript中的情况也是如此。我们可以看到setTimeout被用来防止多线程之间的资源竞争，或者阻止传播那些不考虑对页面上其他事件处理程序产生影响的事件。

我意识到，当你需要完成某一个工作的时候，现在就解决出现的问题当然是ok的。但如果你不花时间去了解这个问题的根源，那么你会发现自己将一次又一次地陷入同样的问题中。

抽出点时间来弄清楚你的解决方案奏效的原因，这看似费时费力，但我保证将来它能节省你很多时间。更全面地理解你正在工作的系统，将意味着前进道路上更少的猜测和检查工作。

学会预测未来浏览器的变化

前端和后端代码之间的主要区别就是后端代码通常运行在一个受控制的环境中。相反的，前端则完全在控制之外。用户使用的平台和设备随时可能彻底改变，所以你的代码得能够优雅地处理这样的情况。

我还记得2011年的时候我在一个流行的JavaScript框架的源代码中，看到以下代码行（为了简便起见已作修改）：

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

在当时的情况下，IE6的确涵盖了所有的IE浏览器版本，能够处理所有高于IE6的版本，但一旦IE10出来，应用程序大部分地方就会彻底不行。

我知道在现实世界中特征检测并不会100％时间工作，有时你不得不依靠bug行为或进入白名单的浏览器，让它们来帮助检测错误，但是你这么做的时候，你得能预测到未来某个时候这些bug将不复存在，这个是绝对的关键。

对于许多人来说，今天写的代码的存活时间会比我们就职于当前工作的时间要更久。我8年前一些代码，今天依然在一些大型的生产网站运行，固步自封的思想，既令人满足，又让人害怕。

阅读规格说明

浏览器bug是不可避免的，但是当两个浏览器对相同的代码有着不同呈现的时候，人们往往不检查自己，就直接认为，那个所谓“好”的浏览器是正确的，“坏”的浏览器是错误的。但是，事实并不总是如此，当你被这个假设所误导的时候，无论你选择了什么解决方案，将来几乎都会肯定崩溃。

这方面的一个例子就是flex项目的默认最小尺寸。根据规格说明，flex项目的初始min-width和min-height为auto（不是0），这意味着在默认情况下，不能将其内容收缩到比最小尺寸更小。在过去8个月时间里，Firefox是唯一正确实现这一目标的浏览器。[1]

如果你遇到跨浏览器不兼容，发现你的网站呈现在Chrome、IE、Opera和Safari浏览器是相同的，但在Firefox上不一样，你可能会认为火狐搞错了。事实上，我亲眼目睹过很多次这样的情况。报告的许多Flexbug项目问题，实际上就是由于这种不兼容性引起的，而提出的解决方法，如果实施的话，会在两周前Chrome 44出来的时候失败。不遵从规格说明的解决方法会在不知不觉中损害正确的行为。[2]

当两个或多个浏览器对相同的代码却有不同的呈现时，你应该花时间找出哪一个是正确的，然后谨记这一点来写代码。这样你的解决方法才不会在不久的将来成为过时的技术。

此外，所谓的“伟大”的前端工程师往往是那些敢于在主流之前先使用新技术，甚至促进新技术发展的人。如果你能培养自己阅读规格说明和展望技术前景的能力，那么你就会成为并影响规格说明发展的一份子。

阅读他人的代码

阅读他人的代码，可能并不有趣，但这毫无疑问是进阶为一个更优秀的开发人员的最佳途径之一。

依靠自己的本事来解决问题，是一个学习的好方法，但如果你只这么做，那你很快就会到达你的瓶颈。阅读他人的代码可以帮助你发现做事的新方法。阅读和理解代码是团队工作和合作开源项目时必不可少的能力。

其实，我觉得很多公司在聘用新的工程师时犯的最大的错误就是，只要求他们写代码——从头开始写新的代码。我从未在任何一场面试中说要求我阅读一些现有的代码，去找这些代码中的问题，然后解决这些问题。这真是太糟糕了，因为作为一个工程师你的大部分时间是花在增加或更改现有的代码库上的。很少需要你从头开始构建新的东西。

和比你聪明的人一起工作

前端开发人员比后端开发人员更想成为自由职业者。也有可能是因为前端人往往是自学成才的，而后端人往往来自于正规学校。

但是自学成才和为自己工作也是有缺陷的，那就是你通常不会明白从比你聪明的人那儿学习的好处。不会有人给你建议，也没有人为你检查代码。

我强烈建议至少在职业生涯的开始阶段，一定要进入一个团队工作，最好团队人员比你聪明比你有经验。

如果你在你职业生涯某个时间点，不想只为自己工作了，那么不妨参与到开源项目中。积极推动开源项目能为你提供很多与团队工作相同的好处，有的时候甚至好处更多。

重新发明轮子

“重新发明轮子”对企业是不利的，但却是伟大的学习方式。比如说你想掌握来自于npm的预输入控件或事件委托类库，那么不妨试想一下如果你自己来构建这些东西，能帮助你学到多少。

我敢肯定看到这里一定有人想臭骂我一顿。别误解我的意思。我不是说你不应该使用第三方代码。使用经过充分测试的库——坐享多年测试案例和bug报告总是明智的行为。

但在这篇文章中，我要说的是如何从优秀进步到伟大。在这个行业中大多数我认为伟大的人，都是我们无时无刻不在使用的超级流行的库的创造者或维护者。

可能你也有一个成功的职业生涯——但却不曾构建自己的JavaScript库，那么你可能从未真正接近过它的本质。

很多人会问的有关于这个行业的一个常见问题是：接下来我该构建什么？如果你问这个问题，是因为不想去学习新的工具或创造新的app，那么给你个建议：为什么不尝试重建自己喜欢的JavaScript库或CSS框架呢。这样做的好处是，碰到问题的话，现有的库的源代码会明晃晃地告诉你所有的答案。

把你学到的东西写下来

最后但并非最不重要的一点是，你应该把你学到的东西写下来。这么做的理由有很多，但最好的理由或许是这能迫使你更好地理解主题。如果你无法解释它是如何工作的，那么很有可能其实你还没有真正地理解。通常只有当你尝试将内容写下来的时候，才能发现自己其实还没搞明白。

根据我的经验，写作、发表演讲、以及创建演示都是强迫自己从外到内挖掘和充分理解事物的最佳方式之一。即使不会有人来阅读你写的东西，但是写的这个过程绝对物超所值。

脚注：

[1].2014年12月1日Firefox在版本34中实现了规格说明变化，Chrome于2015年7月21日添加到日历在版本44中实施，这意味着Opera很快也会这么做。Edge于2015年7月29号发布实施，而Safari似乎正在实施酝酿中。

[2].对于这个问题可以参考Flexbug＃1作为适用于未来的跨浏览器解决方案。