xml地图|网站地图|网站标签 [设为首页] [加入收藏]
如何成为一名卓越的前端工程师,前端图片引入
分类:web前端

对在校学生,我们看重哪方面能力?

有同学问,360前端是否一定要求实际经验的学生,在这里我可以回答:否。

对于学生,我们比较关心的是:

  • 基础:包括数学、算法、数据结构、计算机相关基础的掌握。
  • 学习能力和学习方法:如何学的前端,学了多久,学到什么程度,遇到过什么问题,是如何尝试解决这些问题。
  • 兴趣:对前端的兴趣如何,这一点可以体现在很多细节上。有一个反面的例子比较常见,一般来说我会问学生最近在关注什么前端新知识,有的学生会说我关注某某某,但当我再问他究竟关注到什么程度,会发现他实际上根本没有在这项新知识上花费多少时间。如果你对感兴趣的问题都不花费时间,如何证明你自己对前端的“兴趣”呢。
  • 解决问题的能力:遇到难题如何解决的,遇到没接触过的问题是如何思考和最终解决的。从这里可以判断出同学有没有前端思维,这些问题没有标准答案,我们不追求某些“官方思路”,看重过程而不是结果。

关于简历,有同学提到说现在似乎很多公司都希望学生会点 Node.js,会点 React,我自己不会该怎么办。

我想说的是,我们并不要求学生必须会这些。相反,我个人更鼓励学生利用时间打好基础。简历上写自己真正擅长的内容即可,我们不会因为在你的简历上看不到 Node.js 或者 React 就忽略你。只要你真心热爱前端并用心学了,你应该明白如何用前端基础来打动我。有的学生喜欢在简历上堆砌词汇,实际上这一点不见得好,因为如果你写了一个你自己一知半解的东西,最后在面试中被面到了,一定会得负分的。

技术本身是有深度的,A 同学说“我知道React但没用它做过东西”, B 同学说“我用AngularJS写过一些个人的小项目”, C 同学说“我上个月使用弹性布局的思路来写我的博客,结果在Android系统4.1版本的Webkit浏览器下出现了一个显示bug,最后我是这样这样解决的”。你们说 A、B、C 三个同学我们会选择哪个同学?

面试是一个彼此交流的过程,我们希望看到大家在前端领域的能力和潜力,“知道”一件事,并不是一种有价值的能力,尤其是在知识廉价的互联网时代。我们的同学千万不要像背书一样去死记硬背一样东西,而应该真正用心去学。我们的高等学校不仅仅教授大家知识,还有如何真正学习和做研究,不是吗?

如果你对前端真的感兴趣并有潜力,花点小心思,你该知道如何学习它。

最后,祝愿大家都能成为优秀的前端工程师。

2 赞 11 收藏 2 评论

图片 1

如何成为一名卓越的前端工程师

2015/08/19 · JavaScript · 6 评论 · 前端工程师, 职场

原文出处: Philip Walton   译文出处:赵锦江(@勾三股四)   

译注:本文翻译自谷歌工程师 Philip Walton 的一篇博客。看过之后非常有感触,很多观点都是自己长期非常坚持和认同的,所以翻译出来分享给更多的前端同学!


最近我收到一封读者来信让我陷入了思考,信是这么写的:

Hi Philip,您是否介意我问,您是如何成为一名卓越 (great) 的前端工程师的?对此您有什么建议吗?

不得不承认,被问这样的问题,我很惊讶,因为我从来不觉得自己是个很卓越的前端工程师。甚至我入行的头几年时并不认为自己可以做好这一行。我只确定自己比自己想象中还才疏学浅,而且大家面试我的时候都不知道从何问起

话虽这么说,我到现在做得还算不错,而且成为了团队中有价值的一员。但我最终离开 (去寻求新的挑战——即我还不能够胜任的工作) 的时候,我经常会被要求招聘我的继任者。现在回看这些面试,我不禁感叹当我刚开始的时候自己在这方面的知识是多么的匮乏。我现在或许不会按照我自己的模型进行招聘,即便我个人的这种经历也有可能成功。

我在 web 领域工作越长时间,我就越意识到区分人才和顶尖人才的并不是他们的知识——而是他们思考问题的方式。很显然,知识在很多情况下是非常重要而且关键的——但是在一个快速发展的领域,你前进和获取知识的方式 (至少在相当长的一段时间里) 会比你已经掌握的知识显得更加重要。更重要的是:你是如何运用这些知识解决每天的问题的。

这里有许许多多的文章谈论你工作中需要的语言、框架、工具等等。我希望给一些不一样的建议。在这篇文章里,我想谈一谈一个前端工程师的心态,希望可以帮助大家找到通往卓越的道路。

前端图片引入方式神演算

2017/01/11 · 基础技术 · 图片

原文出处: 沐洒(@Musa沐洒)   

图片 2

| 导语 本文只提供推理方式和分析方法,不保证样本及计算的精准性,慎读!!!

先阐述一下背景:

我们团队对于图片的使用方式有一个明文规定如下:

  1. 凡是需要合并雪碧图,或是编码base64的图片,均放入slice目录下对应模块目录里,gulp-postcss会统一编译处理。
  2. 直接以单图形式引入页面的图片,放在page/aaa/bbb/img目录下(aaa表示业务单元,bbb表示具体页面),使用相对路径./xxx.png直接引用。
  3. 全局复用的单图,放入common/img目录下。

目录结构大概是这个样子:

图片 3

这就是我们今天的议题。

众所周知,页面内图片的引入方式一般有这3种:雪碧图,base64内联,普通单图。(canvas,svg等非常规方式不在此次议题里),先简单分析一下三种方式的优劣势:

图片 4

嗯,大概的情况是这样的,然后我来稍微扩展解释一下:

1. base64图本身确实无法缓存,但是base64图一般是存在于css里的,那么就可以随着css被缓存而实现间接缓存,所以它的缓存属性不是“无”。说它“差”是因为并不是直接被当做图片缓存。当然如果是直接写在html里的,那就没法缓存了,这个要注意。

2. base64额外增加html/css大小并不是主要问题,问题是,因此造成的渲染堵塞有时候是致命的!而作为图片文件加载则不存在这个问题,因为图片是不会堵塞到html和css加载的,因此也不会影响首屏渲染。(当然了,你非要把img标签写在style前面那我只能说,哥,我服~~~~)

了解了三种方式的优劣势之后,对于使用场景简单归纳一下:

  1. 页面自身独有的图片,全部合并成一张雪碧图。

2. 公共模块或者公共组件,如果包含多张图片,则各自为阵合并各自的雪碧图;如果只有一两个图片,或者包含有可以被其他模块、组件、页面复用的图片,则使用灵活性好的单图模式或base64模式。

不过这种说法遗留了一个问题:例如所有页面都有的吊顶区域,假如那里有一个小图,注意,是一个喔(如果是很多的话就合并啦),这种时候是直接单图引入呢?还是base64内嵌到吊顶的css里?

好像二者都可以是吧,用单图的好处就是我在首页缓存后,逛其他页面时候就不用再加载了,当然了首页就会多一个请求;而用base64模式,会少一个图片请求,但会增加吊顶css的文件大小,从而间接增加了首页的渲染堵塞时间。好吧,又TMD陷入了纠结。。。

别急!

下面我们再对base64模式做一个简单的分析:

先明确我们对于base64图片劣势的控诉点在于,1:丫会增大原始图片文件;2:植入css之后会增大css文件大小。

做一个简单的实验,我把几个全局经常出现的小图标,用base64编码,结果:

平均增大35%

图片 5

但是!

gzip压缩后 —— 4%~40%,平均增大22%

图片 6

当然样本少是一个问题,但大概的我们还是能看出来一些端倪:base64确实会增大文件,而且即使做了gzip后增幅还是居高不下。这也是为什么我们一般不会对大图片进行base64编码的原因,假如对一张100KB的图片编码,将会增加20-30KB!这是蛮恐怖的了。但我们现在说的是小图片呀,一个小图片1KB左右,即使增大30%也就增加三百多字节而已。

我们思考的更进一步,究竟怎么样的文件大小增幅,是我们可以接受的?

一个常识,普通人的肉眼可识别的视觉暂留是50ms。而根据多年前端实战经验,对于网页渲染速度,肉眼可敏感识别的渲染时长间隔是500ms,所以一般一个css3过渡效果,transition-duration 为0.3s和0.8s才会有显著区别,而0.3s和0.5s的区别,除了号称“像素眼”的重构同学和有细节控的设计师能感知外,一般人很难明显感知。

那么因此我们是不是粗略的得出一个结论:对于首屏渲染时间的减少或增加,用户可明显感知的变化范围是50ms-500ms之间,也就是说,即便你优化做得再好,小于50ms的变化,是不会被感知的,另一方面,如果你因为某个原因增加了首屏渲染时间500ms,就会产生一个很大的感官变化。

好了,这么说来,我们能接受的文件大小增幅,所导致的首屏渲染时间增加,应该控制在500ms内。对于身处公司内网的我们而言,M/s的速度显然不用在意这些细节,500ms可以轻轻松松加载几MB的资源,就算是普通用户,现在宽带整体速度都6得飞起,500ms加载几百KB应该不成问题吧。

但是!我们不能这么想啊,做产品的会把用户当做小白,我们做开发优化是不是也应该假设用户还停留在拨号上网时代?哈哈哈,开玩笑了,这倒不至于,但我们确实可以假设用户网速很一般,100kb/s的网页加载速度,对自己够狠了吧我。

基于网速100kb/s的假设,500ms可以加载50kb的资源。。。。等等!总感觉哪里不对!

一个文件的加载,应该包含了这些个过程:

图片 7

所以我们理论上“500ms可以加载50kb的资源”,指的是download这里的速度而已,但是一个小图片从请求到渲染,需要经过请求排队,请求堵塞,等待响应,下载等众多环节。。。那么500ms我们到底能加载多大的文件呢?这个问题我真的回答不了,因为这涉及到的环境变量太多了,请求堵塞,网速抖动,浏览器版本,服务器速度,dns解析等等都有可能影响到这个结果。这。。。文章写不下去了怎么办。。。不能放弃治疗啊!那么我们干脆就更加大概一点估算好了,就假设这500ms中,只有250ms是给我们用来下载资源的,那么100kb/s的速度我们可以下载25kb的资源,嗯。。。。看起来还蛮是合理的呢。。。。

我们多找几张小图看一下timing的分布:(10kb以内)

图片 8

有没有发现一个规律?对于10kb以下的小图而言,下载时间其实几乎可以忽略不计(1%左右),而真正占用贷款的是这一次次请求经历的漫长的流程(请求排队,请求堵塞,等待响应….)

补充验证:当图片大小增加到100kb以上时,下载耗时平均是总耗时的50%不到。

经过上面一大推的推演和样本测试后,我们得到了一些相对合理的参数值,接下来要抛大招(计算公式)了!

图片 9

终于!我们拿到了我们想要的计算结果!2.6倍base64图片总大小的下载时间,是我们增加的首屏负荷。之前我们已经说了,在不影响用户感官明显变化的情况下,我们仁慈的允许多500ms的下载时间,在100kb/s的弱网条件下,最终计算出,允许内嵌的base64图片大小是20kb!20kb!20kb!这和我们刚刚大概估算的25kb很接近啊!看来有些时候计算无力的情况下估算还点靠谱的。。。

机智的我经过一系列估算后,得出了一个拙劣但相当有意义的答案!意义在于,我终于知道什么大小的图片叫做小图片啦!!!不知道这个历史性难题难倒了多少重构GG!

图片 10

好吧,别打我,我知道我的计算有点暴力。。。。

Anyway!我在文章副标题里就说了,

本文只提供推理方式和分析方法,不保证样本及计算的精准性,慎读!!!

讲真,我的切入点和分析方法应该是没有问题的对吧各位?只是这其中需要计算的数值实在涉及到太多不确定性,我表示暂时受到那么一丢丢困扰,所以就先估算之,感兴趣的同学可以按照此方法重新计算哈。

做这些蛋疼的研究,终归还是要回归到业务上的,那么我们文章开始的疑问是不是已经解决了呢?经过我们一步步的推演和深入浅出,问题基本解决了。

下面简单归纳一下不同场景所应该使用的图片引入方式:(正经脸 -_- !!!)

  • 全局通用的,非特定页面或模块独有的图片,采用单图或base64方式引入,二者区别如下:
    • 若该图片在多处使用或图片本身较大(这类图总体积大于20kb),则使用单图模式
    • 若该图片只有少数地方使用且图片本身较小(这类图总体积小于20kb),则使用base64模式
  • 公共模块/组件里的图片(假设该模块名为mod-prd)
    • 模块内有N(N>=3)个图片,则全部放入**slice/mod/prd**里,使用雪碧图模式,否则参考全局通用图片处理方式
  • 页面自身独有的图片,全部合并成一张雪碧图

装逼结束,轻喷~

2 赞 3 收藏 评论

图片 11

前端工程师的发展之路和前景是怎么样的?

前端是一个相对比较新的行业,互联网发展早期(1995年~2005年)是没有专业的前端工程师的。随着互联网的发展,大约从2005年开始,正式的前端工程师角色被行业认可,到了2010年,互联网开始全面进入移动时代,前端工程师的地位越来越重要,前端领域的技术发展也越来越快,各种新的思想、设计模式、工具和平台都快速发展,对前端工程师的技能要求也越来越高。

有一些数据可以说明前端行业的发展迅速。

  • 在2010年之后最流行的新编程语言中有相当部分和前端有关,比如 Dart、Clojure、CoffeeScript 和 TypeScript。
  • 作为前端最重要的编程语言 JavaScript,在最近几年里不论是代码量还是关注数都稳居 Github 平台热门编程语言榜。
  • 行业对前端需求量持续增加,前端程序员薪水在行业里面处于较领先的位置。

图片 12

近年来最流行的编程语言很多都是JavaScript替代语言

图片 13

JavaScript在最热编程语言 TOP10

图片 14

近几年互联网公司前端团队每年扩张一倍

图片 15

JavaScript工程师平均薪水排名在程序语言工程师收入前10

与比你聪明的人一起工作

我印象中的很多前端开发者 (相比于全职工作来说) 都是自由职业者,有同类想法的后端开发者并没有那么多。可能是因为很多前端都是自学成才的而后端则多是学校里学出来的。

不论是自我学习还是自我工作,我们都面对一个问题:你并没有机会从比你聪明的家伙那里学到什么。没有人帮你 review 代码,也没有人与你碰撞灵感。

我强烈建议,最起码在你职业发展的前期,你要在一个团队里工作,尤其是一个普遍比你聪明而且有经验的团队里工作。

如果你最终会在你职业发展的某个阶段选择独立工作,一定要让自己投身在开源社区当中。保持对开源项目的活跃贡献,这会给你团队工作相同甚至更多的益处。

前端工程师需要什么样的知识和技能?

有人说前端工程师的技术栈是这样的:

图片 16

还有人说是这样的:

图片 17

实际上前端工程师最核心的技能还是:

图片 18

在一个典型的互联网公司的产品研发流程中,前端工程师和其他角色的关系大致上是这样的:

图片 19

前端是最接近产品和设计的工程师,起到衔接产品和技术的作用,前端为用户可以看到的部分负责,所以也是最接近用户的工程师。

在多终端的时代,如果一个产品同时支持PC、移动端,前端工程师还需要和更多的角色打交道:

图片 20

JavaScript 对于前端是最重要的技能,所以优秀的前端工程师要有扎实的JavaScript基本功。而JavaScript这门编程语言也是目前程序设计领域炙手可热的宠儿,如今的它不仅仅只是用来开发Web,还可以用在各个方面。

图片 21

JavaScript 可以用在“树莓派”这类智能硬件芯片开发

前端工程师也是软件工程师,所以软件工程师的基础知识也是非常重要的,这些基础知识包括:

  • 数学
  • 计算机体系
  • 操作系统
  • 数据结构和算法
  • 编译原理

HTML和CSS也是前端工程师非常重要的基本功,很多同学,尤其是喜欢写代码的同学容易忽视 Markup Language,实际上 ML 也是 UI 相关的领域里面很重要的内容,不应该被忽视。

  • HTML: The Living Standard
  • HTML & CSS

有同学问说:“前端工作需求很多,老是改来改去,实际的技术点并没有多少,产品决定业务逻辑,从事底层基础服务会不会更有挑战和职业未来?”

的确,越贴近业务和产品层面上的工作,需求差异性越大,可能改动越频繁。不仅仅是前端改来改去,PHP服务端做业务的同学也面临这样的问题,业务逻辑改来改去。越底层通用性越强,改动相对较少。

不过事情都是有两面性的,首先可以这么想想,是底层基础服务的市场大还是互联网业务和产品的市场大。其次,基础服务的通用性很容易达成,而产品层面上如何通用化,如何在业务驱动的产品研发中利用工程化和工具化提升开发效率,这其实是一个很难的问题。丰富的互联网产品已改变和正在改变着我们的生活,然而作为产品的创造者,工程师们怎样让自己过得更好,这个领域值得研究。

另外,不要觉得实际的技术点没有多少,举几个例子:实现曲线和曲面动画,计算地图的最短路径,让png静态图片类似于gif图一样做局部的运动,抽奖游戏,物理效果的HTML5游戏,3D图表,增强现实的WebGL视频流处理等等,这些都是在前端领域中遇到的实际问题。

就 JavaScript 来说,在实际项目中设计最合适的模型高效率解决现实问题本身就很有挑战。作为一种典型的新生代编程语言,JavaScript 特性丰富,使用灵活,性能优良。面向对象、函数式编程、各种设计模式、MVC 和 MVVM,这些本身就有足够的吸引力。

前端要解决界面和交互问题,实际上UI层面上的问题一直是软件工程方面的一个难题,因为UI不停地在变化。浏览器各个版本的兼容性、Web 标准、移动设备、多终端适配,给了前端工程师很大的挑战,对前端工程师的能力也有很高的要求。许多UI问题有不只一种解决方法,许多问题有非常巧妙的思路和精彩的解决办法,前端在工程师群体里是属于非常有创造力的一个群体,因为这个行业需要丰富的创造力和想象力。

前端工程师还是Web标准的制定者、实践者和推动者,而现在的W3C标准不仅仅局限于浏览器,还包括各种手持智能设备,车载设备、智能家居等等。在未来万物互联的时代,前端将不仅仅是网页上的工程师,而是所有人机交互领域的工程师。

“造轮子”

造轮子在商业上是非常糟糕的,但是从学习的角度是非常好的。你可能很想把那些库和小工具直接从 npm 里拿下来用,但也可以想象一下你独立建造它们能够学到多少东西。

我知道有些人读到这里是特别不赞成的。别误会,我并没有说你不应该使用第三方代码。那些经过充分测试的库具有多年的测试用例积累和已知问题积累,使用它们绝对是非常明智的选择。

但在这里我想说的是如何从优秀到卓越。我觉得这个领域很多卓越的人都是我每天在用的非常流行的库的作者或维护者。

你可能不曾打造过自己的 JavaScript 库也拥有一个成功的职业发展,但是你从不把自己手弄脏是几乎不可能淘到金子的。

在这一行大家普遍会问的一个问题是:我接下来应该做点什么?如果你没有试着学一个新的工具创建一个新的应用,那不妨试着重新造一个你喜欢的 JavaScript 库或 CSS 框架。这样做的一个好消息是,在你遇到困难的时候,所有现成的库的源代码都会为你提供帮助。

本文由澳门新葡亰手机版发布于web前端,转载请注明出处:如何成为一名卓越的前端工程师,前端图片引入

上一篇:编织璀璨星空图,前端性能优化方案索引 下一篇:没有了
猜你喜欢
热门排行
精彩图文