共计 2885 个字符，预计需要花费 8 分钟才能阅读完成。
我在 web 畛域工作越长时间，我就越意识到辨别人才和顶尖人才的并不是他们的常识——而是他们思考问题的形式。
很显然，常识在很多状况下是十分重要而且要害的——然而在一个疾速倒退的畛域，你后退和获取常识的形式 (至多在相当长的一段时间里) 会比你曾经把握的常识显得更加重要。更重要的是：你是如何使用这些常识解决每天的问题的。
我心愿给一些不一样的倡议。在这篇文章里，我想谈一谈一个前端工程师的心态，心愿能够帮忙大家找到通往卓越的路线。
别光解决问题，想想到底产生了什么
很多人埋头写 CSS 和 JavaScript 直到程序工作起来了，而后就去做别的事件了。
我通过 code review 发现这种事常常产生。我总会问大家：“为什么你会在这里增加 float: left？”或者“这里的 overflow: hidden 是必要的吗？”，他们往往答道：“我也不晓得，可是我一删掉它们，页面就乱套了。”
JavaScript 也是一样，我总会在一个条件竞争的中央看到一个 setTimeout，或者有些人无心中阻止了事件流传，却不晓得它会影响到页面中其它的事件处理。
我发现很多状况下，当你遇到问题的时候，你只是解决当下的问题罢了。然而如果你永远不花工夫了解问题的根源，你将一次又一次的面对雷同的问题。花一些工夫找出为什么，这看上去费时费力，然而我保障它会节俭你将来的工夫。
在齐全了解整个零碎之后，你就不须要总去猜想和论证了。
学会预感将来的浏览器发展趋势
前后端开发的一个次要区别在于后端代码通常都运行在齐全由你掌控的环境下。前端相对来说不那么在你的掌控之中。
不同用户的平台或设施是前端永恒的话题，你的代码须要优雅掌控这所有。
我记得本人 2011 年之前已经浏览某支流 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 是强制本人齐全深刻了解一件事的最佳形式。就算你写的货色没有人看，整个过程也会让你受益匪浅。
