【实战】前端开发体系建设日记

IT资讯 860 Views

InfoQ编辑注:本文来自前端工程师张云龙的博客,由作者本人推荐至InfoQ进行分享。目前本系列已经发布了三个部分,本处分享的是第二部分,前端开发体系建设日记。建议在阅读本文前先阅读本文作者和其团队之前分享的《前端工程精粹》系列一、二、三。

上周写了一篇文章介绍前端集成解决方案的基本理论,很多同学看过之后大呼不过瘾。

本打算继续完善理论链,形成前端工程的知识结构。但鉴于如今的快餐文化,po主决定还是先写一篇实战介绍,让大家看到前端工程体系能为团队带来哪些好处,调起大家的胃口再说。

ps: 写完才发现这篇文章真的非常非常长,涵盖了前端开发中的很多方面,希望大家能有耐心看完,相信一定会有所斩获。。。

2014年02月12日 – 晴

新到松鼠团队的第二天,小伙伴 @nino 找到我说

nino: 视频项目打算重新梳理一下,希望能引入新的技术体系,解决现有的一些问题。

po主不禁暗喜,好机会,这是我专业啊,蓝翔技校-前端集成解决方案学院-自动化系-打包学专业的文凭不是白给的,于是自信满满的对nino说,有什么需求尽管提!

nino: 我的需求并不多,就这么几条~~

  1. 模块化开发。最好能像写nodejs一样写js,很舒服。css最好也能来个模块化管理!

  2. 性能要好。模块那么多,得有按需加载,请求不能太多。

  3. 组件化开发。一个组件的js、css、模板最好都在一个目录维护,维护起来方便。

  4. 用 handlebars 作为前端模板引擎。这个模板引擎不错,logic-less(轻逻辑)。

  5. 用 stylus 写css挺方便,给我整一个。

  6. 图片base64嵌入。有些小图可能要以base64的形式嵌入到页面、js或者css中使用。嵌入之前记得压缩图片以减小体积。

  7. js/css/图片压缩应该都没问题吧。

  8. 要能与公司的ci平台集。工具里最好别依赖什么系统库,ci的机器未必支持。

  9. 开发体验要好。文件监听,浏览器自动刷新(livereload)一个都不能少。

  10. 我们用nodejs作为服务器,本地要能预览,最好再能抓取线上数据,方便调试。

我倒吸一口凉气,但表面故作镇定的说:恩,确实不多,让我们先来看看第一个需求。。。

还没等我说完,nino打断我说

nino: 桥豆麻袋(稍等),还有一个最重要的需求!

松鼠公司的松鼠浏览器你知道吧,恩,它有很多个版本的样子。

我希望代码发布后能按照版本部署,不要彼此覆盖。

举个例子,代码部署结构可能是这样的:

release/

– public/

– 项目名

– 1.0.0/

– 1.0.1/

– 1.0.2/

– 1.0.2-alpha/

– 1.0.2-beta/

让历史浏览器浏览历史版本,没事还能做个灰度发布,ABTest啥的,多好!

此外,我们将来会有多个项目使用这套开发模式,希望能共用一些组件或者模块,产品也会公布一些api模块给第三方使用,所以共享模块功能也要加上。

总的来说,还要追加两个部署需求:

  1. 按版本部署,采用非覆盖式发布

  2. 允许第三方引用项目公共模块

nino: 怎么样,不算复杂吧,这个项目很赶,3天搞定怎么样?

我凝望着会议室白板上的这些需求,正打算争辩什么,一扭头发现nino已经不见了。。。正在沮丧之际,小伙伴 @hinc 过来找我,跟他大概讲了一下nino的需求,正想跟他抱怨工期问题时,hinc却说

hinc: 恩,这正是我们需要的开发体系,不过我这里还有一个需求。。。

  1. 我们之前积累了一些业务可以共用的模块,放在了公司内的gitlab上,采用 component 作为发布规范,能不能再加上这个组件仓库的支持?

3天时间,13项前端技术元素,靠谱么。。。

2014年02月13日 – 多云

一觉醒来,轻松了许多,但还有任务在身,不敢有半点怠慢。整理一下昨天的需求,我们来做一个简单的划分。

  • 规范

    • 开发规范

      • 模块化开发,js模块化,css模块化,像nodejs一样编码

      • 组件化开发,js、css、handlebars维护在一起

    • 部署规范

      • 采用nodejs后端,基本部署规范应该参考 express 项目部署

      • 按版本号做非覆盖式发布

      • 公共模块可发布给第三方共享

  • 框架

    • js模块化框架,支持请求合并,按需加载等性能优化点

  • 工具

    • 可以编译stylus为css

    • 支持js、css、图片压缩

    • 允许图片压缩后以base64编码形式嵌入到css、js或html中

    • 与ci平台集成

    • 文件监听、浏览器自动刷新

    • 本地预览、数据模拟

  • 仓库

    • 支持component模块安装和使用

这样一套规范、框架、工具和仓库的开发体系,服从我之前介绍的 前端集成解决方案 的描述。前端界每天都团队在设计和实现这类系统,它们其实是有规律可循的。百度出品的 fis 就是一个能帮助快速搭建前端集成解决方案的工具。使用fis我应该可以在3天之内完成这些任务。

ps: 这不是一篇关于fis的软文,如果这样的一套系统基于grunt实现相信会有非常大量的开发工作,3天完成几乎是不可能的任务。

不幸的是,现在fis官网所介绍的 并不是 fis,而是一个叫 fis-plus 的项目,该项目并不像字面理解的那样是fis的加强版,而是在fis的基础上定制的一套面向百度前端团队的解决方案,以php为后端语言,跟smarty有较强的绑定关系,有着 19项 技术要素,密切配合百度现行技术选型。绝大多数非百度前端团队都很难完整接受这19项技术选型,尤其是其中的部署、框架规范,跟百度前端团队相关开发规范、部署规范、以及php、smarty等有着较深的绑定关系。

因此如果你的团队用的不是 php后端 && smarty模板 && modjs模块化框架 && bingo框架 的话,请查看fis的文档,或许不会有那么多困惑。

ps: fis是一个构建系统内核,很好的抽象了前端集成解决方案所需的通用工具需求,本身不与任何后端语言绑定。而基于fis实现的具体解决方案就会有具体的规范和技术选型了。

言归正传,让我们基于 fis 开始实践这套开发体系吧!

开发概念定义

前端开发体系设计第一步要定义开发概念。开发概念是指针对开发资源的分类概念。开发概念的确立,直接影响到规范的定制。比如,传统的开发概念一般是按照文件类型划分的,所以传统前端项目会有这样的目录结构:

  • js:放js文件

  • css:放css文件

  • images:放图片文件

  • html:放html文件

这样确实很直接,任何智力健全的人都知道每个文件该放在哪里。但是这样的开发概念划分将给项目带来较高的维护成本,并为项目臃肿埋下了工程隐患,理由是:

  1. 如果项目中的一个功能有了问题,维护的时候要在js目录下找到对应的逻辑修改,再到css目录下找到对应的样式文件修改一下,如果图片不对,还要再跑到images目录下找对应的开发资源。

  2. images下的文件不知道哪些图片在用,哪些已经废弃了,谁也不敢删除,文件越来越多。

ps: 除非你的团队只有1-2个人,你的项目只有很少的代码量,而且不用关心性能和未来的维护问题,否则,以文件为依据设计的开发概念是应该被抛弃的。

以我个人的经验,更倾向于具有一定语义的开发概念。综合前面的需求,我为这个开发体系确定了3个开发资源概念:

  • 模块化资源:js模块、css模块或组件

  • 页面资源:网站html或后端模板页面,引用模块化框架,加载模块

  • 非模块化资源:并不是所有的开发资源都是模块化的,比如提供模块化框架的js本身就不能是一个模块化的js文件。严格上讲,页面也属于一种非模块化的静态资源。

ps: 开发概念越简单越好,前面提到的fis-plus也有类似的开发概念,有组件或模块(widget),页面(page),测试数据(test),非模块化静态资源(static)。有的团队在模块之中又划分出api模块和ui模块(组件)两种概念。

本文从开发目录设计、部署目录设计以及配置fis连接开发规范和部署规范三个方面进行了详细介绍,具体细节,请点击“阅读原文”。

总结

不可否认,为大规模前端团队设计集成解决方案需要花费非常多的心思。

如果说只是实现一个简单的编译+压缩+文件监+听自动刷新的常规构建系统,基于fis应该不超过1小时就能完成一个,但要实践完整的前端集成解决方案,确实需要点时间。

如之前一篇文章所讲,前端集成解决方案有8项技术要素,除了组件仓库,其他7项对于企业级前端团队来说,应该都需要完整实现的。即便暂时不想实现,也会随着业务发展而被迫慢慢完善,这个完善过程是普适的。

对于前端集成解决方案的实践,可以总结出这些设计步骤:

  1. 设计开发概念,定义开发资源的分类(模块化/非模块化)

  2. 设计开发目录,降低开发、维护成本(开发规范)

  3. 根据运维和业务要求,设计部署规范(部署规范)

  4. 设计工具,完成开发目录和部署目录的转换(开发-部署转换)

  5. 设计模块化框架,兼顾性能优化(开发框架)

  6. 扩展工具,支持开发框架的构建需求(框架构建需求)

  7. 流程整合(开发、测试、联调、上线等流程接入)

我们可以看看业界已有团队提出的各种解决方案,无不以这种思路来设计和发展的:

  • seajs开发体系,支付宝团队前端开发体系,以 spm 为构建和包管理工具

  • fis-plus,百度绝大多数前端团队使用的开发体系,以fis为构建工具内核,以lights为包管理工具

  • edp,百度ecomfe前端开发体系,以 edp 为构建和包管理工具

  • modjs,腾讯AlloyTeam团队出品的开发体系

  • yeoman,google出品的解决方案,以grunt为构建工具,bower为包管理工具

纵观这些公司出品的前端集成解决方案,深入剖析其中的框架、规范、工具和流程,都可以发现一些共通的影子,设计思想殊途同归,不约而同的朝着一种方向前进,那就是前端集成解决方案。尝试将前端工程孤立的技术要素整合起来,解决常见的领域问题。

或许有人会问,不就是写页面么,用得着这么复杂?

在这里我不能给出肯定或者否定的答复。

因为单纯从语言的角度来说,html、js、css(甚至有人认为css是数据结构,而非语言)确实是最简单最容易上手的开发语言,不用模块化、不用工具、不用压缩,任何人都可以快速上手,完成一两个功能简单的页面。所以说,在一般情况下,前端开发非常简单。

在规模很小的项目中,前端技术要素彼此不会直接产生影响,因此无需集成解决方案。

但正是由于前端语言这种灵活松散的特点,使得前端项目规模在达到一定规模后,工程问题凸显,成为发展瓶颈,各种技术要素彼此之间开始出现关联,要用模块化开发,就必须对应某个模块化框架,用这个框架就必须对应某个构建工具,要用这个工具,就必须对应某个包管理工具……这个时候,完整实践前端集成解决方案就成了不二选择。

当前端项目达到一定规模后,工程问题将成为主要瓶颈,原来孤立的技术要素开始彼此产生影响,需要有人从比较高的角度去梳理、寻找适合自己团队的集成解决方案。

所以会出现一些框架或工具在小项目中使用的好好的,一旦放到团队里使用就非常困难的情况。

前端入门虽易工程不易,且写且珍惜!

如未说明则本站原创,转载请注明出处:NULL » 【实战】前端开发体系建设日记