Heim  >  Artikel  >  Web-Frontend  >  大公司或专业团队目前流行的前端工具有什么?

大公司或专业团队目前流行的前端工具有什么?

WBOY
WBOYOriginal
2016-06-07 08:42:031458Durchsuche

正在严格的学习前端知识,谢谢各路好汉的相告。

回复内容:

下面这些东西在大公司可能不流行(你懂的,大公司喜欢自己造轮子),但绝对是专业前端需要了解的:

  • Node.js:现代工业化前端的基础;
  • RequireJS:AMD规范,即将过时的 JavaScript 模块化方案;
  • Bower:前端模块源;
  • npm;前端工具源,另一个潜在的前端模块源;
  • Browserify:即将过时的基于 CommonJS 的前端模块化方案;
  • Less:等 CSS 增强工具;
  • Gulp:前端构建工具,如果你在前端开发中不需要使用类似工具的话,我只能呵呵;

未来的 JavaScript:ES6、ES7,兼容未来 JavaScript 模块化方案类库、代码转化类库等等。 从来没有发过言,在这里破处。。。

就具体的工作、开发框架或库,上面的都列举得差不多了,就不重复大家的,咱来一个前端开发方面理论层面的东西,从理论层面来反推,前端都要学习些什么技术,这也算是个人对于前端这个工种的粗浅见解吧,欢迎吐槽,别扔鸡蛋~~

这个疑惑是大多数前端开发入门的困扰。。。说实在的,和后端相比,前端的知识体系太杂了,以至于很多入门者找不到方向。其实,前端既要宽度,也要深度,优秀的前端开发人员比后端开发人员难培养多了。

1,兴趣是最好的老师
学习前端,或者说(ˇˍˇ), 玩代码这一行,要玩得有深度,最基本也是最重要的,要自己有兴趣,没有兴趣就不要浪费时间了。虽然这是废话,但是当你碰到了技术发展的瓶颈期了,我觉得就应该能很比较好地理解这句废话的含义。

2,找一个好的导师
找一个愿意传授知识的导师,或找一个有大牛存在的团队,这是提高技能的最好也是最快的途径。如果什么都是自己研究,天赋异禀,或许会比别人快,但有一个人在关键时刻提点你,效果其实是非常显著的,突飞猛进指日可待。

说白了,你要和牛人一起干过活,知道大牛长什么模样的。

当然,在大中型项目中,大牛比较多,但这个对于入门者来说,如果你进入不了大中型项目,那么也可以在很多创业项目中物色,特别是电商领域等热门的、竞争激烈的领域,前端这一块至少需要一两只大牛来做前端架构和开发模式选型,能承担这样子角色的人选,一般都算是比较厉害的了。
竞争激烈的领域,如果连交互体验都不重视,那么这种项目绝对是没有成功的机会滴。

不同level,前端需要的技能分析
1,初级入门
html和css,这两个基本功。合理的html结构,很多时候可以减少js逻辑、css样式,以及避免绝多数的兼容性问题。基本功不好,到了一定程度会限制你往后发展的空间。
这一层面会涉及photoshop、美术方面的相关知识,而交互方面,大多数WEB需求是在jQuery或Zepto这样的库下进行的,会这两个库基本能够入门了。

2,中高级前端
初中级前端对于原生js开发能力的要求并不是很迫切,但是如果到了高级前端,就需要对js原生层面的API、属性以及不同浏览器的特性,都要有较深的了解了。
这一层面的前端,我个人认为必须深刻理解几个知识点:js的闭包、作用域以及类。熟练掌握几种js类的定义以及继承的方法,了解它们之间的差异,并能结合实际需求,在开发生产应用上。这其实就是具备面良好的向对象编程的编程开发思维了。
此外,中高级的前端必须掌握CMD或AMD的模块化方案中的一种,还掌握至少一个MVC或MVVM框架,能胜任比如OPOA页面,又如tmall、唯品会等电商网站的侧边工具条、提交订单等交互功能复杂的开发需求。

在这个级别的前端,我觉得,才好称之为程序员,和后端的开发一样,都是码农了。对于入门的,只要求会切图,写简单脚本或整合个jQuery插件来完成任务的,在我看来,还不能算是一个程序员。

3、前端leader
之前都是说技术的,而leader角色其实除了开发技能外,可能还需要一些管理方面的经验或能力。
在这个层面,不同的团队可能不一样,有偏技术的,有重管理的,但我个人认为,如果要底下的开发人员服你,至少代码层面的功力不能少,要不你无法做好代码review,保障整个团队是按照规范来执行得,有问题的时候需要leader快速定位问题,提供解决方案或解决思维。

小结,一个优秀的前端leader,我认为应该具备的能力:
①重要功能或需求的开发,或提供解决方案,做技术选型 ---> 技术功底
②需求分析评审,分发开发任务,和产品经理、设计师以及后端等沟通、协调 ---> 沟通能力,具备产品思维,前端转型做产品不在少数
③开发需求的跟进,代码review,代码合并与发布等,精通svn或git是必须的,记住是精通,你新招的新手同事很可能不知道什么时候把别人写好的东西弄没了,你至少要知道如何找回吧 ---> 项目管理能力
④前端开发规范,开发文档、开发标准的建立和实施,关键是实施 ---> 文档功力和执行力
⑤新员工的培训、辅导 ---> 做老师的能力
⑥前端的技术更新太快了,一个优秀的前端leader还要引导团队了解和学习新的技术,为以后做技术储备 --->行业观察能力
……
⑦不能太宅。这很重要,技术男大多很宅,要想做一个好的leader,就要多和不同的人特别是多和沟通方面强势的人打交道。要不,等你做到leader的位置,即便是站在前端的角度来看有些极度不合理的需求,你也可能镇不住,天天接这样的需求,怨言就犹如漫天飞雪,受不了的人会选择离开,如果你的团队离职率高的话。。。Boss会觉得你是合适的吗?

4,前端架构师


是的,前端也需要架构!
前端leader,或高级前端开发不就是了?可能是,但架构是一个系统性层面的东西,能做好前端管理,未必能做好架构,当然,做好前端架构了,未必就能做好前端团队的管理。

当然,这是两个层面的东西,也没所谓谁更高大上。

好吧。还是聊聊架构师这玩意吧,因为做架构要涵盖的前端方面方面,还包括一些后端的东西。听起来,还是挺高大上的。

现在的前端已经不再是刀耕火种的年代了,在整个web开发生产流水线上,可能一些企业网站还可能属于附属或边角的工作,就是干php的顺手也可以弄一下的那种,但是,但凡有点追求的,重视前端体验的项目,前端必须是专业人士来干的,前后端分离开发也是必须的。

如何实现前后端分离?为什么要实施前后端分离?这方面的知识,似乎不是这个主题的范畴了。我就不说了,这里主要是给前端架构师,这个细分工种,给出我个人的见解。

首先,在我看来,前端架构要解决三个层面上的问题:
①团队开发协作层面的——根据项目的情况,设定一套符合项目实际需求的,能够解决前端团队多人协作开发、代码模块化组织的开发架构或模式,减少前端开发的边际工作,方便开发人员把绝大多数精力专注于业务逻辑的本身实现。也就是,前端生产的工程化和发布的自动化。

②业务需求实现层面的——根据业务需求,设定或整合一套符合业务需求的,能够解决绝大多数业务场景的基础上,保持好良好的可扩展性以及良好的可维护性的Javascript框架或方案。

③除了解决前端自身开发的两个层面问题外,还可能协同后端架构师,确定前后端对接的API,定一套符合项目需求的RESTful方案,并整合到前端框架中,最终形成一套数据封装的js API,如果项目有采用MVVM框架的,最好是能结合Model,以便view视图的控制。

当然,对于前后端交集的部分,比如服务端view模板层的一些东西,可能也需要前端架构师提供一个合理的架构或方案,哪些东西是公共的,可继承或复用的,该抽象出来的。。。这在PHP项目中是必不可少。

当然,这个工作可能是前端Leader来干也合适的。

或墨水有限,或眼界有限,对于前端架构师这个工种的表述不是很到位的,欢迎补充。

举个例子吧,然后我再对前端架构师要干的活做一个小结。

以阿里巴巴为例,淘宝、天猫、一淘等平台,都是基于kissy框架以及基于kissy开发的模块,这是根据阿里巴巴复杂多变的业务需求,在多次迭代后形成的,几乎你想要的前端功能它都包含,底层的基础工具函数,表现层的业务实现代码,甚至标准模板都有的,如果把所有功能都打包,这个框架就很大,实际生产时不可能这么干,对吧?

没关系,它本身是模块化,可以按需请求。但这还需要结合在Combo技术和CDN技术,这其实是阿里前端的核心技术,这里也有些相关的介绍:
前端优化:淘宝的Combo Handler和新浪微博的link标签includes属性
模块化高扩展性的前端框架 KISSY

小结: 如果项目中要用上类似kissy这样的框架,到底涉及多少前端架构相关的技术:
1、前端自动化工程化——nodeJS/grunt /gulp
2、前端模块化——CMD或AMD,kissy是CMD,也就是seaJS,CMD就是阿里自己弄出来的标准
3、前端发布代码增量发布系统——git是必须的,NodeJS Express框架的自动化或可视化的发布界面
4、前端按需加载——在线Combo,CND缓存技术,这里的核心,我认为是解决js模块依赖分析以及CDN的强缓存问题
5、前后端数据交互——RESTful、模板控制系统(tmall内部好像是TMS系统),前端主导业务系统的API规范
6、前端开发环境的一些相关问题,这个因为前端开发比较零碎,边际工作多,提高开发体验和提高开发迭代速度,很多基础性工作,比如开发环境,数据模拟系统,等都是前端架构师要考虑的事情

当然,kissy很强大,但并不一定适合每个项目,所以架构师要做的事情要对技术做好选型,如果时间允许,架构师不妨考虑自己造一个轮子,但项目的时间规划上不允许,不是要你自己造一个轮子,而是整合各种资源,形成一套能快速用于实战的整合套餐。

比如,蘑菇街的前端开发框架就是一盘整合的套餐——requirejs+jquery+backbone+一套自定义的底层库+各种插件+在线combo

如果要了解大公司的前端是怎样的,或者别人是怎么做的,可以看这里的视频,——D2前端技术论坛——2014绽放丨章节
有不少底料,前端开发理念层面的东西比较多。当然,前提是你都看明白了,如果都理解别人的做法,我想,你距离大牛也就不远了吧。

题外话:在线combo和本地combo
在阿里和蘑菇街两个电商上,都用了在线Combo,说明这确实是一个前端非常重要的技术,模仿阿里前端资源在线combo的服务,咱用coffeescript也写了个在线combo的服务,基于node 的Express框架,有兴趣可以参考一下
github.com/lmtdit/stati

但是,我个人认为,在中小型的项目中,其实还用不上在线combo这种技术,因为这需要良好的服务器支持,而阿里、蘑菇街在这方面的资源并不是问题,而初起步的项目一开始就引入这种前端资源加载机制,是挺高大上的,但可能投入产出比上考虑不是很划算。。。
而本地化的Combo机制,生产代码在本地build好之后,再发布到第三方的CDN上,这种可能会比较实际,但也要解决好CSS和JS模块开发和生产混淆压缩以及静态资源的缓存问题。 唉,看了一圈,没人回答持续集成和在线接口/在线工具相关的东西。

- Gitlab Ci
- 代理工具/在线代理工具/HOSTS管理工具/...
- Mock接口服务/本地Mock工具
- ICON FONT
- 图片上传和在线优化/图片优化工具
- 错误追踪
- DPL + JS TOOLKIT
- ... 造轮子的路过:EFE Tech - 百度EFE(Excellent FrontEnd)技术体系
  • ECharts - 数据可视化图表库
  • ESL - AMD Loader
  • EDP - 前端开发平台
  • EST - 基于 Less 的样式工具库
  • Saber - 移动 SPA 项目解决方案
  • Rider - 移动样式工具库
  • ER - SPA 应用框架
  • ESUI - UI 组件库
  • ETpl - 灵活、高性能的模板引擎
  • iSlider - 轻量、高性能的移动滑动方案
  • 图说 - 可视化数据分享平台
  • Fontmin - 字体子集化方案
我们是创业小团队,我们的前端是:老师客户管理端 angular 1.3 -> angular-marterial -> gulp +bower 学生使用产品web端(以手机端为主,自适应页面将会与手机app原生的混合) : React + Flux + react-router + browserify + gulp +bower ;后端nodejs为主,以后准备逐渐往golang转;
-----------------------------------
广招天下豪杰加入我们,目前就我一个前端(累趴。。。)拉勾链接:新瓶子招聘-英芝教育科技(上海)有限公司招聘 工具框架都是为业务提供支持的,更好,更快,更舒服。

知道自己需要什么,再去看对应的工具,体会和理解会更好。

日常工作 我用的工具大部分都是自己写的。库,插件,用的多了,只是懒的自己写的时候会网上随便找找。

可能我很土,对其他楼主所说的新东西不甚了解。并不是因为不知道,而是知道后,觉得对自己目前工作没啥用。没去深入看完。

我反对什么都学,把精力留在深度上更好一点。而一些标准也都是人之所为。

需要就用,不足就改,没有就造。我对前端工具的看法。

工具只是手段啊,哪有什么流行不流行,更谈不上过时。 百度FIS 说说我们猎豹移动广研前端团队的一些实践方案:

工作流:
Grunt。如果你喜欢Gulp,也没问题。但是我更喜欢Grunt的写法。

模块化管理:
完全基于CommonJS规范,使用browserify组织代码。至于有人喜欢ES6模块或者AMD的方案,可以利用相应转换工具转换为CommonJS。我们的CSS代码、JS代码、HTML代码都是用require方式引入的(自己实现的插件)。异步加载代码,也有browserify插件实现,可以实现按需加载(自己实现的插件)。我们会对引入的任何代码进行cache bust(自己实现的插件)。以上3个browserify插件未来会进行开源。

样式:
因为产品需求差异比较大,样式都是自己写了。stylus + nib,用过的都说好!

前端框架:
分具体使用场景:
(1)内部管理系统extjs、Angular、React etc.我们鼓励在内部或者重要程度比较低的项目中,使用一些新的、热的或者前沿的技术;
(2)移动Web,基础库zepto。PC Web,基础库jQuery;
(3)小项目、活动页面,通常没有架构而言。大型项目,基本除了基础库,都会有个自己的业务框架;当然我们也有有些公用组件的沉淀;
(4)复杂的PC Web APP中,使用knockout做MVVM和knockout模块组织代码;knockout这东西好啊,大小合适,兼容性好,还支持组件化开发;

质量保障:
项目比较杂,暂时没有引入专业测试工具,主要是3点:
(1)自己编写的小的测试模块,做成工作流中的一部分,构建时就能发现一些低级错误(类似JSLINT);
(2)JS代码执行错误、AJAX质量、PVUV等的数据上报和统计;
(3)运维侧的各种监控工具;

前后端分离:
God Bless,我们大多数项目都是非展示型页面。对首页加载速度没有过多要求,所以我们通常都是前后端完全分离,即全部使用AJAX交换数据,即使是首屏。

抓包+替换资源:
Fiddler or Charles。 学好Native Javascript 自己找个库 用自己的代码模拟实现一下 回头再看别的库 so easy 看大家各抒己见,我也从前端开发的各个环节讲讲了解的一些东西吧:
1. 【调试服务器】首先如果你是一个准备做WEB开发实践的,不管前端、后台,首先需要了解一两种服务器apache,tomcat,nginx啥的,至少能够配置一个基本的本地服务和修改索引路径,前端页面使用http/https协议访问,而不是本地文件协议。
2. 【调试自动更新】服务器搭建好了,那么现在开始调试网页,然后你修改一点代码,去浏览器里面F5刷新页面看看效果,再修改一点代码,再去浏览器里面F5刷新页面看看效果...如此循环往复, maybe让工具帮助你检测本地文件修改然后实时刷新网页更靠谱。
3. 【换种方式写代码】然后就是写代码了,less/sass是不错的css组织工具,coffee也能让你的javascript代码显得更严谨和逻辑清晰,要是能够在访问页面的时候实时获取css/coffee编译结果神马的应该显得很cool。
4. 【模块化】当然在完成逻辑相对复杂的交互功能时候,可能需要你组织非常复杂的代码功能,这个时候了解一下模块化的开发思想显得很有必要require.js事实上更早,也更广泛一点,sea.js在国内也不错。
5. 【模板引擎】然后就是对于js生成HTML(或者其他什么的)的一种包装方式, 即:js模板引擎(handlebars,jade), 你可以尝试在开发时候使用这样的模板工具生成自己想要的HTML文档什么的,也是一种不错的体验,这个就像你用less写css代码一样,或者说用php,jsp这样的服务端语言工具生成实时HTML页面。
6. 【代理调试】有的时候你开发的东西并不只是前端代码,牵扯到跟服务端应用之间的数据交互,难免需要使用ajax,ajax这货基于安全考虑是不允许跨域的,因此可能需要通过代理的方式实现数据调试这样的工具也有不少,nginx服务器是其中的佼佼者。
7. 【资源合并优化】OK, 如果到完成开发阶段,你需要提交自己开发的代码到线上服务器了,在提交之前,你需要考虑将开发的资源进行最优化(合并,压缩神马的), js方面有uglify,css有cssmin神马的,图片压缩还可能根据不同的类型进行不同程度和配置的压缩,这些事情交给别个工具处理显得很有必要,要是能够一键处理那简直了, 百度的fis,业内最流行的grunt.js、gulp.js神马的,事实上它们在配置化编译LESS/Coffee这类工作在自己的流程中也很在行。
8. 【Combo】使用异步模块化开发带来的弊端就是对于大量零碎依赖文件需要分别开辟多个http链接去获取,这可不是一个好现象,要知道单个浏览器单域名并发获取资源的数量是很有限的, 因此例如KISSY就支持了简单配置一个combo参数来组织一个获取nginx的 http-concat格式资源的路径,当然这样的动态合并模式也适用于普通的资源请求合并。
9.【资源缓存和更新】 CDN 能够确保你已经发布到服务器上的资源以最快的响应时间到达浏览器,但是带来的问题是,你的代码更新,CDN则傻乎乎的不理你,除非你在使用的地方告诉它需要更新了( 时间戳、MD5文件名啥的 )。

事实上,我觉着凡是重复进行的工作总有可以程序和代码可以替你完成的部分,前端开发中这种事情尤其多,工具啥样的自己去定义才最合适自己,而nodejs的出现使得前端自己可以方便的开发这类东西(上面的less、coffee、uglify、gruntjs、fis、gulp这些个单词可以说:都依赖nodejs)。

最后是广告时间 f2e-server就是依据以上环节所开发的工具: shy2850/node-server · GitHub
Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn