-
Notifications
You must be signed in to change notification settings - Fork 12
Home
塞伯坦CYB 是面向前端模块化工程的构建工具。主要目的是帮助开发者统一前端开发模式和项目开发结构，提高功能扩展和降低维护成本，自动化前端工作流，提高开发效率和开发质量。
曾经很长一段时间，前端跟服务端的配合方式是这样的：前端产出demo页面，服务端负责参考html代码来写velocity模板，这个过程就是传说中的“套页面”了，这个过程往往不是那么愉快的，有时候服务端的同学会把标签嵌套搞错，前端出了bug，则需要服务端重新改模板。这种前、后端代码的夹杂，维护性、扩展性是个非常大的问题，沟通协作方式也极大的影响了团队开发效率，这种开发模式在很多团队由于多种原因一直在沿用，即便有些项目团队尝试或者已经在改变着使用前后端分离的开发模式，然而，随着项目应用复杂度的提升、团队人员的扩充、前端技术的日新月异，导致团队间或是团队内的不同项目使用的开发方案不尽相同，很多项目在迭代几期、或交接给其它项目团队常常都会打掉重新开发，极大的浪费了研发资源。
::: tip 大多团队现状
- 开发模式落后、复杂项目功能迭代及代码维护困难。
- 开发方案繁杂、标准不统一，团队协作、项目交接成本较高。
- 大量机械重复的web开发工作流程，极大影响开发效率。
- 业务繁重，大多团队无暇研究多种类型的项目通用的高效开发方案。
- 现有构建工具在功能、扩展、适用性及常用开发场景解决方案落伍。 :::
随着Web应用复杂度的提升、团队人员的扩充、用户对于页面交互友好与性能优化的需求，前后端分离与富客户端的概念日渐为人认同，智能手机开发普及，移动端大浪潮的汹涌而来，SPA单页应用的设计理念也大行其道，相关联的前端模块化、组件化、响应式开发、混合式开发等等技术需求甚为迫切，也更需要工程化的方法帮助我们提高研发效率。大部分时候我们谈论到工程化这个概念的时候，往往指的是工具化，然而任何一个通向工程化的道路上都不可避免的会走过一段工具化的道路。前端工程化，目标就是希望能用工程化的方法，用最短的时间和最少的人力、物力、以尽可能快的速度实现可信赖的高质量的软件产品。
::: tip 工程化的目标
- 借助ES6/ES7特性，统一前端模块化开发标准、提高扩展和维护性。
- 规范各种类型项目的开发结构、降低维护及沟通成本。
- 自动化机械重复的前端开发工作流程、提高研发效率。
- 集成业界先进的常用开发场景解决方案，以适用各种类型的项目开发。
- 助力项目开发的技术选型，让团队研发人员更专注于业务逻辑的快速实现。 :::
前后端分离本质上是前端与后端适用不同的技术选型与项目架构，前后端分工非常清晰，协作点是约定API接口，分头开工并行开发，前端使用Node构建开发环境并自动化前端工作流，通过MOCK方式进行开发和测试及完全自主的优化WEB性能，完全独立的规划功能模块和组件，提高可复用性、扩展性及维护性。并在特定的时间节点前后端做一次性沟通的集成测试，前后端分离的开发模式，对于整个产品的开发速度与可信赖性有着很大的促进作用。
- 将原本由服务端负责的数据渲染工作交由前端进行，并且规定前端与服务端之间只能通过标准化协议进行通信。
- 组织和技术架构上的分离，由早期的服务端开发人员顺手去写个界面转变为完整的前端团队构建工程化的前端架构。
项目开发速度
开发速度是最为直观、明显的工程化衡量指标，也是其他部门与程序员、程序员之间的核心矛盾。绝大部分优秀的工程化方案首要解决的就是开发速度，但是磨刀不误砍材工，我们在追寻局部速度最快的同时不能忽略整体最优，初期单纯的追求速度而带来的技术负债会为以后阶段造成不可弥补的损害。
前后端API接口衔接
在前后端分离的情况下，前后端常常是各成体系与团队，那么前后端的沟通也就成了项目开发中的主要矛盾之一。前端在开发的时候往往是根据界面来划分模块，命名变量，而后端是习惯根据抽象的业务逻辑来划分模块，根据数据库定义来命名变量。最简单而是最常见的问题譬如二者可能对于同意义的变量命名不同，并且考虑到业务需求的经常变更，后台接口也会发生频繁变动。此时就需要前端能够建立专门的接口层（service层）对上屏蔽这种变化，保证界面层的稳定性。
多个业务系统的组件复用
当我们面临新的开发需求，或者具有多个业务系统时，我们希望能够尽量复用已有代码，不仅是为了提高开发效率，还是为了能够保证团队内部应用风格的一致性。
多平台适配与代码复用
在移动化浪潮面前，我们的应用不仅需要考虑到PC端的支持，还需要考虑移动端浏览器、微信小程序、微信内H5、APP内嵌H5等等平台内的支持。这里我们希望能够尽量的复用代码来保证开发速度与重构速度，但有时候移动端和PC端本身设计风格差异较大，并不是所有的项目都适合响应式开发来复用界面组件，更多的应该是着眼于逻辑代码的复用，鱼与熊掌，不可兼得，需要因地制宜，不能一概而论。
工具的存在是为了帮助我们应对复杂度，在技术选型的时候我们面临的抽象问题就是应用的复杂度与所使用的工具复杂度的对比。工具的复杂度是可以理解为是我们为了处理问题内在复杂度所做的投资。如果投的太少，就起不到规模的效应，不会有合理的回报。如果要解决的问题本身是非常复杂的，那么你用一个过于简陋的工具应付它，就会遇到工具太弱而使得生产力受影响的问题。反之，如果所要解决的问题并不复杂，但你却用了很复杂的工具，那么就相当于杀鸡用牛刀，会遇到工具复杂度所带来的副作用，不仅会失去工具本身所带来优势，还会增加各种问题，例如培训成本、上手成本，以及实际开发效率等。
::: tip 正确使用工具的打开方式
- 尽量不重复造轮子，善于整合工具，集成业界优秀的开源框架工具库，形成团队内真正意义的工程体系。
- 使用渐进式前端解决方案思想，让工具本身的能力根据项目需求而变化。 :::
为了帮助开发者统一前端开发模式和项目开发结构，提高功能扩展和降低维护成本，自动化前端工作流，提高开发效率和开发质量。目前前端工具化已经进入到了非常繁荣的时代，如百度的FIS、京东的JDF、京东凹凸实验室的athena、以及vue-cli、react-create-app等工程构建工具，每个构建工具都有自己的特点，但是随之而来很多前端开发者也甚为苦恼，疲于学习。鉴于前端技术的日新月异、帮助开发者更加自由的技术选型、避免重复造轮子的高度维护成本，也是需要一个不同于传统高度封装的集成策略，而使用渐进式解决方案的思想，集成业界先进、通用的框架库作为基础方案，封装基本的配置接口和规则以及前端开发固定常用的工作流程，根据项目需求可以自由的扩展功能，以达到更加自由的适应各种类型项目的开发。
近几年前端的发展，一片欣欣向荣，各种优秀的应用层框架层出不穷，我们不能让团队局限于一种应用框架的使用，需要支持快速创建基于Vue、React、jQuery技术平台的项目，并且很容易与其它第三方框架库集成，借助ES6/ES7的行业标准，统一开发模式和项目开发结构，简化前端开发的工作流程，以帮助我们在瞬息万变、浩瀚无边的技术选型中恣意的扬帆远航。
- Vue
支持Vue单文件组件形式的高级开发模式，结合Vue渐进式的特性和强大的模板视图层，可以最小成本改造旧应用或快速创建各种类型的新项目，加之Vue生态系统的支持，可以快速开发复杂的高性能单页或多页WEB应用程序。
- React
支持React组件化开发模式，结合JSX赋予开发者许多的编程能力，依托Facebook的各种工具和框架，可以开发更加庞大的大型应用程序，加之同时适用于web和原生体验的React Native，可以大幅提高研发效率和降低开发成本。
- jQuery
支持使用ES6/ES7的标准特性开发jQuery项目，jQuery作为了影响一代前端开发者的框架，它留下了璀璨的痕迹与无法磨灭的脚印。在未来相当长的一段时间内，jQuery并不会直接退出历史的舞台，很多时候我们都只是需要快速开发一个专题页面或者小型的官方网站，jQuery庞大生态圈的众多功能强大的插件依然能够帮助我们大幅的提高研发效率、开发高质量的WEB应用。
模块化是一种处理复杂系统分解为更好的可管理模块的方式。每个模块完成一个特定的子功能，所有的模块再进行统一的拼装和加载，成为一个整体，完成整个系统所要求的功能。模块化在工程上会大大提升项目的可维护性及拓展性，同时会带来一些代码可复用的附加效果。但是，模块化的指导策略一定是分治而不是复用，分治的目的是为了使得组件之间解耦跟正交，从而提高可维护性及多人协同开发效率。如果以复用为指导原则那么组件最后一定会发展到一个配置繁杂代码臃肿的状态。
::: tip 模块化宗旨
- 模块内部逻辑高内聚并自由控制
- 作用域独立不与其它模块产生影响
- 松耦合的与其它模块任意组合 :::
使用规范的文件目录结构，这有助于提高项目的逻辑结构合理性，大大提高项目的功能扩展能力，以及项目后续的迭代维护成本。但是任何规范都需要有一个度的把控，规范太多不利于模块的规划和自由组合，规范太少将使项目结构过于混乱而不利于后续的扩展和维护，构建工具要做的是规划基本的目录结构，每个项目团队再根据团队和项目情况，自行规划统一的详细的目录结构。
.
├── cyb.config.js
├── package.json
└── src
├── static
│ ├── fonts
│ ├── images
│ └── styles
│ ├── page1.scss
│ └── page2.scss
└── views
├── page1
│ ├── index.html
│ ├── index.js
│ ├── service.js
│ └── module
│ ├── mod1
│ │ └── index.js
│ └── mod2
│ └── index.js
├── page2
│ ├── index.html
│ ├── index.js
│ └── module
│ ├── mod1
│ │ ├── index.js
│ │ └── service.js
│ └── mod2
│ └── index.js
│ └── service.js
└── public
└── module在新项目开发时，无论我们选择任何的应用层框架，都需要有开发过程、测试过程、以及发布过程。也都会需要less/sass/stylus编译、css前缀自动补全、css压缩、图片压缩、javascript编译/合并/压缩、添加版本号等前端流程。
常用前端开发工作流程
- 创建新项目
快速创建统一结构化项目，包括默认创建首页html模板、统一规划JS脚本、样式文件、图片/字体等静态资源的存放目录。创建项目时可以选择Vue、React、jQuery技术平台。
- 创建新页面
快速创建统一结构化页面，包括创建页面的html模板，对应的脚本文件和样式文件。支持传统的页面资源部署，或者一切皆模块的组件化部署，更加方便的开发多页面应用。
- 研发过程
在本地构建Node开发服务器，脱离nginx、apache等后台服务的依赖，实时编译前端的各种资源，并且在开发过程中任何文件的更改，都会自动更新浏览器界面，实时查看修改效果。
- 发布过程
编译和处理源码目录中的所有源文件，通过智能提取、合并压缩、添加CDN前缀、生成md5版本号等自动化流程，并将编译成功后的所有上线文件发布到dist目录。
- 测试过程
在本地构建Node测试服务器，读取dist目录中的代码，借助前后端分离的API请求模式，无需发布上线，即可在本地打开浏览器测试上线代码和所有业务逻辑。
- 打包上线代码
读取dist目录中所有的代码，在项目根目录下打包压缩成dist.zip文件，用于通过其它途径、或流程工具将代码发布到线上服务器，或发送给客户、领导、合作伙伴验收。
- 特殊字体解决方案
根据设置的文本抽取大文件TTF的字体信息，转换为eot/woff/ttf等格式的网页字体，告别特殊字体做成图片的lower，帮助我们开发完美个性化的官方网站、活动专题等项目。
- 图片深度无损压缩解决方案
对整站或单个图片深度无损压缩，整合业界前沿的程序算法，压缩率达50%以上，并且几乎看不出质量差别，极致的图片性能优化，帮助我们开发拥有极致用户体验的产品。
- SSH上线部署或部署静态资源
快速部署上线代码，根据配置的SSH服务器信息，读取dist目录中的所有代码，通过SFTP快速发布代码到线上服务器或测试服务器，可以配置仅部署静态资源到CDN服务器。
构建工具需要集成了大量应用场景的前端工作流程和业界先进的解决方案，并且任何机械的重复性的工作都应该自动化完成，用以提高项目整体的研发效率。
常用需要自动化的流程
- 自动化创建统一结构化项目、及统一结构化的项目页面。
- 自动化搭建本地研发环境，快速响应文件更改并自动刷新浏览器。
- 自动化在开发/测试过程中同步浏览器中滚动页面、点击等行为到其他浏览器和设备中。
- 自动化编译ES6/ES7或CommonJS标准的JS代码，并生成source map便于浏览器端调试。
- 自动化编译Sass/Less/Stylus => CSS文件。
- 自动化使用Autoprefixer添加CSS3的各种浏览器前缀。
- 自动化压缩JS、CSS、HTML等静态资源。
- 自动化深度无损压缩PNG/JPG/JPEG/GIF图片。
- 自动化提取/合并第三方框架库(vendor)、项目公共代码(common)
- 自动化根据配置自定义合并前端JS、CSS文件。
- 自动化注入编译后的JS、CSS文件到HTML页面。
- 自动化ESlint编码规范、代码检查及代码测试。
- 自动化生成所有静态资源MD5版本号。
- 自动化添加所有静态资源CDN地址。
- 自动化搭建用于测试上线代码的多终端测试环境。
- 自动化通过SFTP部署上线、或部署静态资源。
- 自动化通过Mock方式构建随机数据，模拟研发和上线的数据环境。
- 自动化SVG高清图片/图标解决方案。
- 自动化移动端REM等比适配解决方案。
- 自动化智能WebP解决方案。
- 自动化页面中使用特殊字体解决方案。
- 前端异步编程
异步编程对JavaScript语言太重要。Javascript语言的执行环境是"单线程"（single thread）。所谓"单线程"，就是指一次只能完成一件任务。如果有多个任务，就必须排队，前面一个任务完成，再执行后面一个任务，以此类推。这种模式的好处是实现起来比较简单，执行环境相对单纯。坏处是只要有一个任务耗时很长，后面的任务都必须排队等着，会拖延整个程序的执行。常见的浏览器无响应，往往就是因为某一段Javascript代码长时间运行，导致整个页面卡在这个地方，其他任务无法执行。为了解决这个问题，Javascript语言将任务的执行模式分成两种：同步（Synchronous）和异步（Asynchronous）。所谓"异步"，简单说就是一个任务分成两段，先执行第一段，然后转而执行其他任务，等做好了准备，再回过头执行第二段。"异步模式"非常重要，在浏览器端，耗时过长的操作都应该异步执行，避免浏览器失去响应。使用异步编程模式也可以更好的组织模块化业务逻辑，同时提高代码运行、及页面渲染效率。
- 数据流驱动页面
随着WEB应用变得越来越复杂，再加上node前后端分离越来越流行，对数据流动的控制就显得越发重要。前端变革的一个核心路线就是从以操作DOM为核心到以控制State为核心，这样也就能将逻辑控制、渲染与交互给分离开来。我们不需要关心DOM是如何变更的，只需要在我们的业务逻辑中完成状态转变，便会自动将这个变更显示在UI中。即数据的变化让页面模块和界面显示自动的排列组合。数据流驱动的页面，毫无疑问会将编程工作，特别是复杂的交互与逻辑处理变得更加明晰，也方面了产品迭代与变更，也就是敏捷式开发的理念。
- 响应式开发
随着移动智能手机终端的飞速普及，大量的流量来自于手机端而不再是PC端，很多时候我们都是面向PC端与移动端设计不同的页面，这样就毫无疑问将原来的工作量乘以二，加上项目规划、产品设计、开发部署、后期迭代等流程，工作量将成几何倍的增加。而响应式的优点就在于一份代码各种终端设备兼容，自动适配PC端、手机端、Pad端及各种大小的屏幕，可以内嵌到手机端任何APP中使用（微信、微博、京ME等），若做产品APP只需要IOS端和Android端做个壳引入页面即可，一次性研发投入，同步收获多个平台的产品成果，为产品的多元化几何倍的提高开发效率，极大降低多平台项目的开发成本。但是，响应式还是有缺点：它只是将原本在模板层做的事，放到了样式（CSS）层来完成。复杂度同力一样不会消失，也不会凭空产生，它总是从一个物体转移到另一个物体或一种形式转为另一种形式。而对于APP内嵌H5的Hybrid形式也并不像原生的应用操作体验的友好和流畅，而随着技术的发展，特别是CSS3中Flexbox的提出，以及智能终端硬件的飞速发展，这些问题也都会逐渐得到改善，也更能方便地践行响应式设计的原则。
在所有恐怖民间传说的妖怪中，最可怕的是人狼，因为它们可以完全出乎意料地从熟悉的面孔变成可怕的怪物。为了对付人狼，我们在寻找可以消灭它们的银弹。软件项目具有一些人狼的特性，常常看似简单明了的东西，却有可能变成一个落后进度、超出预算、存在大量缺陷的怪物。因此，我们听到了近乎绝望的寻求银弹的呼唤，寻求一种可以使软件的研发成本迅速降低、提高团队研发效率、解决一切研发缺陷的酷似尚方宝剑的工具。还有，近年的前端生态“欣欣向荣”的发展影响最大的应该就是新产品的技术选型了，乱花渐欲迷人眼，我们很难设计出一套适应大部分场景、而且短时间内不会被淘汰的架构方案和工程化的工具。前端的变化太快通常会导致一些技术决策的反复，今天的最佳实践很可能明天就被视为反模式。工具的变革也会非常迅速，也许很多优秀的工具可能都只是历史长河中的一朵浪花，而蕴藏其中的工程化思维则会恒久长存，没有完美的架构方案，更没有完美的工程化工具，而为了团队共同的梦想，只要我们保持思考、心怀技术激情，才能永远的走在Front-end这条道路上。
致力于为业务研发提供高效的工程化解决方案！
- 官方网站：http://cyb.hestudy.com
- github：https://github.com/jd-cyb/cyb-cli
- Wiki使用文档：https://github.com/jd-cyb/cyb-cli/wiki
- NPM：https://www.npmjs.com/package/cyb-cli
- Yarn：https://yarnpkg.com/zh-Hans/package/cyb-cli
- 塞伯坦前端小组：https://github.com/jd-cyb
Copyright (c) 2018, 塞伯坦前端小组