但事实并不一定如此，当你的假设出现错误时，你选取的变通办法都会在未来遭遇问题。
一个就近的例子是 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 是强迫自己完全深入理解一件事的最佳方式。就算你写的东西没有人看，整个过程也会让你受益匪浅。
说个题外话，我平时一直有整理面试题的习惯，有随时跳出舒适圈的准备，不知不觉整理了229页了，在这里分享给大家，有需要的点击这里免费领取题目+解析PDF
最后
为了帮助大家更好的了解前端，特别整理了《前端工程师面试手册》电子稿文件。
930
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
