引言

为什么我们要做那么多工程化架构上的事情？
这里我引用任正非的一段话：

“软件工程”和“质量工程”需要依靠架构技术，而不是依靠 CMM 和 QA 管理流程。一切工程问题，首先要思考能否通过技术解决，当前技术无法解决的问题，暂时由管理手段代劳，同时不停止寻找技术手段。

必要软件

开发过程中环境 Host 过多，请下载安装 SwitchHosts Tumax DIY 版 ，进行 Host 统一。

在 DIY 版 SwitchHosts 中，已经预制了项目中所需的各个环境，并有定时更新。后续如有 host 变动，会直接在服务器修改，软件会自动同步。

下载地址：http://192.168.1.69/

代码规范

使用 Prettier 进行代码  格式化

项目中已经配置.prettierrc，根据自己的编辑器配置相应插件即可

参考：https://prettier.io/docs/en/editors.html

私有方法\变量命名前加 _

由于 Js 的本身的问题，在 class 中没有后端语言当中的 public protected private 等属性。

所以在部分使用过程中，私有方法\变量前加入_来规定是否是私有变量。

在 vue 中因为官方保留了、$等关键字，所以按照官方建议，使用 $来代替

命名规范

按照 Js 的规范标准，声明变量使用 camelCase。

声明文件名，类名，组件名使用 PascalCase。

按照 Html 标准，所有涉及到类名，标签等 dom 类使用 kebab-case。

TypeScript 基本类型（统一用小写开头的类型, 与原生 js 保持一致）

let  isDoor : boolean = false;             反例：  let isDoor : Boolean = false

const width : number = 100;             反例：  const width : Number = 100;

let  appName : string =  'Tumax'       反例：  let  appName : String =  'Tumax'

目录结构

|- src 项目源码
  |-- api 和接口相关的文件
  |-- assets 资源存放目录
  |-- components 各类小型组件，通用组件
  |-- model 模型\资源 用于管理数据层
  |-- router 路由管理路由配置
  |-- scene 场景，用于处理渲染逻辑使用TypeScript书写
    |-- 3D 处理3D渲染层逻辑
    |-- 2D 处理2D渲染层逻辑
  |-- utils 工具，用于存放常用方法，变量(less)
    |-- index.js 暴露出常用js方法
    |-- variable.less 存放常用变量，如主题颜色，副主题颜色，以及常用样式
  |-- views 用于常用页面组件
    |-- SideBar 边栏组件
    |-- Stage 舞台组件
      |-- 2D 2D舞台组件
      |-- 3D 3D舞台组件
    | HeaderBar 顶部组件
  | App.vue 全局Vue
  | main.js 入口JS

项目安装及操作规范

以项目 README 为标准： Tumax README

开发流程及分支规范

项目中使用 Git 做代码管理，并有一整套的分支定义规范及流程，看图

分支规范

提交说明规范

在自己分支的开发过程中如：hotfix/xxx feature/xxx 对提交信息不做要求。

在有接通 CI 构建的分支提交内容时，需要遵循以下任意规范：

• feature: xxxxxxxx
• hotfix: xxxxxxxx

注意：这对后续的消息提醒与提单发布都非常重要，请认真填写

开发流程说明

作为开发，拿到 git 权限及需求后，应该要走的流程分为以下两种情况。

其中[]中表示对应角色，{CI} 表示有 CI 过程

迭代开发流程

• [组长\迭代负责人] 当接到一个新迭代时（例如 1.1.0），基于 master 分支创建出 release/1.1.0 分支，修改 package.json 的 version
• [开发者] 基于当前迭代的 release/1.1.0 分支开出对应迭代的功能开发分支 feature/xxx，并进入开发

  注意：这里功能分支颗粒度应该尽量细化，如果你以每一个功能点开辟一个分支，那么当这个迭代中假设产品经理给你 10 个功能点，但最终产品经理需求变更只上其中 8 个，那么你只需要将其中的 8 个功能点合并回 release 分支即可，避免代码剥离的过程

• {CI}[开发者] 将开发完成的功能分支 feature/xxx 合并回 release 分支 release/1.1.0
• {CI}[组长\迭代负责人] 将代码已经测试完成的 release 分支合并进入 master，并基于 master 分支创建 tag，如 release-1.1.0

  注意: 当测试人员测试通过，告诉你可以将代码发布至预发（UAT）环境时，那么此时我们认为功能已经完整并通过测试

修复开发流程

注意：此流程只适用于版本号第三位递增。如 release-1.1.0 到 release-1.1.1

当线上出现一些需要通过走非正常迭代上线的需求时，通常视为修复开发流程。

• [组长\迭代负责人] 当一个已有版本出现问题 ，需要修复上线时（例如 1.1.0），基于 release-1.1.0 的 Tag 创建出 release/1.1.1 分支，修改 package.json 的 version
• [开发者] 基于当前迭代的 release/1.1.1 分支开出对应迭代的功能开发分支 hotfix/xxx，并进入开发
• {CI}[开发者] 将开发完成的功能分支 hotfix/xxx 合并回 release 分支 release/1.1.1
• {CI}[组长\迭代负责人] 将代码已经测试完成的 release 分支合并进入 master，并基于 release/1.1.1 分支创建 tag，如 release-1.1.1

  注意: 此处与正常迭代分支的区别在于最后是在 release 分支直接创建 tag，而正常迭代分支必须基于 master 创建 tag

发布流程及规范

在上述过程中已经有提到我们的 Git 对于部分分支已经接入 CI（什么是 CI ）和 版本控制。

简单来说，就是通过一系列手段和自动化流程快速部署到对应环境，并通过版本控制精确控制用户可见范围。

注意：
需要注意的一点是，我们当前所有的发布成功都只是说把前端编译完成的内容发布到对应环境的服务器中。但我们所有的有变动静态资源都是增量发布，不会存在覆盖。在版本控制中心的配置项修改之前，用户看到的还是之前的客户端版本。

接下来分别介绍下 3 个环境的部署发布流程，以下地址你可能会用的到：

• CI 控制面板：http://ci.tumax.we.com/
• 版本切换后台：https://tumaxadmin.to8to.com/#/settings/versionsConfig/account
• 版本调度中心：http://versions.tumax.to8to.com
• BOSS 系统：http://boss.we.com/release/app/index.html

测试环境

测试环境的发布最简单，只需要将代码合并进入 release/* 的任一分支中，CI 构建完成即可。

• CI 构建进度查看：http://ci.tumax.we.com/
• 构建完成消息推送
• 版本切换：https://tumaxadmin.to8to.com/#/settings/versionsConfig/account

预发环境（UAT）

从预发环节开始，所有步骤都需要在BOSS 系统中提交工单进行。

在项目 git 中为某个版本创建 release-x.x.x 的 tag 后，CI 将会开始构建并发布到运维所需的跳板机\跳板仓库中。

接下来就是去 BOSS 系统提交本次上线的内容信息，回滚信息等。这个过程比较耗时，且提交内容常常跟 git commit message 内容相同。所以我们开发了一个内部使用自动化提单脚本：

• tu-commit: http://npm.tumax.we.com/#/detail/\@tumax/tu-commit

这个脚本可以为你填写最后一次 CI 构建的分支中的提交信息作为 BOSS 系统中的关键数据，快速提单。

接下来就是 BOSS 系统的标准步骤，跟进相关负责人审批

线上环境

线上环境是 UAT 的后续步骤，只需要继续过单即可发布到线上环境了

版本控制

版本号说明

项目中使用语义化版本规范

版本格式：主版本号.次版本号.修订号，版本号递增规则如下：

• 主版本号：当你做了不兼容的 API 修改，
• 次版本号：当你做了向下兼容的功能性新增，
• 修订号：当你做了向下兼容的问题修正。

版本切换

在上述发布流程中已经有说，在发布过程中所有的发布成功都是指发布到对应环境。

但并不一定会让用户可见，如果需要切换到对应版本请在对应环境的版本切换后台 进行切换 。

为什么要这样做可以参考《简谈版本管理中心》。

其他专题分享（关键点博客）

Whistle 的使用技巧

我们是如何将 Vue、ThreeJS、PIXI 结合的？

一起探索前端的面向对象

实现一个家具周边感应功能