成为一名年薪20k的前台工程师要做些什么?

作者 : 开心源码 本文共2922个字,预计阅读时间需要8分钟 发布时间: 2022-05-13 共168人阅读

我在 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 是强迫自己完全深入了解一件事的最佳方式。就算你写的东西没有人看,整个过程也会让你收获颇丰。

最后

说个题外话,我平常一直有整理面试题的习惯,有随时跳出舒适圈的准备,不知不觉整理了229页了,在这里分享给大家,有需要的点击这里免费领取题目+解析PDF

篇幅有限,仅展现部分内容篇幅有限,仅展现部分内容篇幅有限,仅展现部分内容

【点击我】无偿获取这份面试题+解析PDF。

说明
1. 本站所有资源来源于用户上传和网络,如有侵权请邮件联系站长!
2. 分享目的仅供大家学习和交流,您必须在下载后24小时内删除!
3. 不得使用于非法商业用途,不得违反国家法律。否则后果自负!
4. 本站提供的源码、模板、插件等等其他资源,都不包含技术服务请大家谅解!
5. 如有链接无法下载、失效或广告,请联系管理员处理!
6. 本站资源售价只是摆设,本站源码仅提供给会员学习使用!
7. 如遇到加密压缩包,请使用360解压,如遇到无法解压的请联系管理员
开心源码网 » 成为一名年薪20k的前台工程师要做些什么?

发表回复