易于维护的前端研发架构复制代码

RDE诞生的背景是，我们发现前端工程目前存在以下问题：

• 工程的开发与维护都是以工程为单位进行管理，每个工程都在重复开发基础设施

• 脚手架都只负责初始化工程，只能保持在创建时一致，后续维护靠业务开发者自己重复维护

  如果业务中有大量工程，就会造成人力浪费与推进改造效率低下等问题；RDE通过重构前端工程结构，给出一套可维护的脚手架方案，实现业务与工程基础设施的分离、基础设施可持续升级维护、进一步提升业务开发者的开发体验；

解决的问题

• 开发业务时，先要从一堆与业务无关的（配置）文件中定位到页面文件，整体工程的感觉比较混乱

• 每个工程重复建设基础设施，重复配置，如webpack基础配置，打点、sentry、mock搭建等

• 每次升级依赖，如webpack、vue等、优化打包等，都需要推进每一个工程升级，效率低下

• 很难同步多个工程的依赖规范，如统一使用echart，统一表单验证库等

• 很难同步多个工程的开发规范，如一些norm术语，lint、serve等，再比如目录结构规范；可以降低跨工程开发成本

• 工程文档维护比较困难，每个工程虽然可以放一个README，但是新人上手体验不好，并且README很容易由于没有及时维护而失效

实现方案

对原工程结构，按照功能进行拆分为3部分：

• 工程基础设施：打包、开发、mock、lint、precommit校验、commit-msg校验、lint规则制定、基础依赖包等

• 开发套件：多个工程复用的component、util、directive、mixin、decorator、filter、style、request方法等；

• 业务应用：业务生产的工程

  RDE充当着连接各部分的角色，提供方案，让这3部分的开发变得更简单；实现细节可以关注wiki，整体思路很简单，将工程拆分为一个app目录、一个template目录，app目录放业务，template目录放基础设施，app目录放在业务的git工程中，template目录发布在docker hub容器里，本地运行时，将二者在docker中进行聚合，然后运行；

核心功能 - CASE模型

RDC容器：用户自己封装维护，并发布在dockerhub上的的工程基础设施镜像，C代表Container

RDA应用：业务工程应用，A代表Application

RDS套件：在业务开发工作中，通用的不仅是组件，因此提出套件的概念，包括通用组件、方法、directive、mixin、decorators等

RDE工具： 整套方案的连接器，提供创建工程、开发运行、发布、生成IDE配置等功能

回顾前端发展进程，RDE可以作为集成汇总、组合所有服务的一个更通用的标准方案，让开发维护工程的粒度不再是工程，而可以根据自己实际需要，进行组合复用；如下图：

最佳实践

  RDE打破了原有以单工程维护的业务架构，但是具体在业务中如何重组工程，拆分几个RDC，RDC如何定位，需要根据各自的业务讨论决定，不建议直接使用外部的RDC，每个团队(或部门)应该自己维护自己的RDC；即使是个人，假设你开发多个工程，个人也可以维护一个RDC，方便后续维护；目前RDC可以作为但不限于以下场景：

• 作为业务工程的底层基建

• 作为组件库、套件库的底层基建，可以包含发布、测试等基本功能，方便上层快速开发发布组件库

• 可以作为Node端封装通用的配置或者逻辑部分

  RDC的维护者需要配合RDE提供的render配置，创造出覆盖面更广的底层基建，需要抛弃单工程的开发的思维，结合上层各种应该用的场景进行开发维护；下面例举一下业务底层RDC的开发可能需要考虑的问题：

• 是否封装了后台通用的菜单

• 菜单如果是多种，是否可以让app层进行选择

• 登陆、错误页、无权限页等通用场景是否需要封装进RDC

• 是否制定路由规范，省去配置路由的麻烦

• 制定团队lint规则

• 是否包含mock、proxy等基础功能

• 如果涉及发布、部署等命令，是否封装了这些操作

• 如果需要使用单测，RDC是否提供了对应包的安装和配置

• 一些最基础，最通用的包，是否安装， 如echart/momentjs/vue等

• 如果使用了ts，一些最基本的d.ts文件的定义，是否已提供

• 如果有样式规范，是否提供了最基本的样式以及对应的样式方法、mixins等，如BEM方法、常用的方法等

• 是否提供了方便应用开发使用的webpack alias配置

• 整个RDC哪些部分需要支持应用扩展，扩展规则如何制定

• 是否提供了完善的文档，供应用开发者使用

• 生态选型，版本升级维护，如未来的webpack升级，vue/react升级等

• 打包性能优化

上手体验

安装依赖环境

• Node

• Docker

$ docker pull node
复制代码

安装RDE

$ npm i -g rde$ yarn global add rde // if using yarn
复制代码

创建工程

$ rde create
复制代码

• 填写要创建的工程名

• 选择创建类型为Application

• 选择要创建的工程的框架

• 为了体验，容器和容器版本选择默认即可

开始探索

  创建成功后，可以开始探索了，先切换到工程目录后，发现生成了：

  其中这里我们要关注的只有app目录和rda.config.js，其他文件都是为了本地开发使用，从镜像中复制出来的，已经添加在gitignore中， 不允许修改的，具体解释如下：

• IDE显示：在vscode或者webstorm中开发时，是否显示该目录

• GITIGNORE: 默认已经加在gitignore中的规则

• sync覆盖： 执行rde sync时会被覆盖的文件

• RDA关注: 开发业务应用需要关注的文件

 接下来执行:

$ rde clean
复制代码

  会删除除了应用需要关注的目录外的所有文件；如果要还原，可以再执行

$ rde sync
复制代码

  又还原出了所有的文件，sync可以再每次升级容器版本、误删除某些文件的情况下使用；

  使用vscode或者webstorm打开工程，可以发现默认只能看到app, rda.config.js等几个文件，因为RDE已经帮你生成了初始配置，隐藏了不需要关注的文件； 另外，如果你使用的是vscode-insiders或者最新版的vscode(并且安装了remote插件)，在使用rde clean后就可以进行开发了，直接打开container即可；由于vscode-insiders不是稳定版本，所以只作为测试体验功能使用，不推荐；

更多详情请参考官网文档与github仓库