前端工程化介绍--模块化、组件化、规范化、自动化

一、模块化的目的，就是便于多人协作开发，对于项目后期便于功能的扩展和修改
1、ES6的到来，使JS可以模块化的组织代码。
2、CSS 可以使用CSS Moudle技术来模块化代码。

二、组件化的目的，就是方便把复杂的页面分割到每个组件中去实现，用分而治之的方式去解决问题。
用React视图库，就会很方便的用组件的方式搭建页面。

三、规范化，模块化和组件化确定了开发模型，就需要规范去落实。

-- src                        # 源码目录
   |__ index.js               # 项目入口，注入store, 调用render方法
   |__ App.js       # 应用入口，页面整体布局，处理页面路由
   |__ App.less      # 全局共用样式文件
   |__ theme.less      # 项目主题文件
   |__ Components
       |__ ActiveChart        # [组件ActiveChart ]
           |__ index.js       # 组件实现源码文件
           |__ index.less
       |__ AxisTitle       # [组件AxisTitle]
            |__ index.js       # 组件实现源码文件
            |__ index.less
   |__ routes    定义应用的页面容器组件                 
       |__ Cockpit              # [页面1]
           |__ index.js       # 页面具体业务代码
           |__ indes.less
           |__components   页面的私有组件
       |__ WorkSpace              # [页面2]
             |__ index.js       # 页面具体业务代码
             |__ indes.less
   |__models
       |__ index.js           # 导出封装后的所有store，以及初始化saga
       |__ request.js         # 封装网络请求，比如所所有的方法进行拦截（inspector）
       |__ model1            # [模块1]store基于具体业务模块来编写，方便多页面调用
           |__ actionTypes.js 
           |__ actions.js     
           |__ reducer.js    封装业务逻辑
       |__ model2           # [模块2]
 |__services
      |__model1.js   封装接口请求
      |__model2.js   封装接口请求
 |__common 公用的工具库
      |__chartUtil
      |__arrayUtil
      |__constants

编码规范
加入ESLint，让工具帮我们约束代码
前后端接口规范
参考地址
Git分支管理
master-作为主分支，存储已发布版本的源码，不能在此分支上进行开发，只能合并release和hotfix分支。在master分支上构建生产版本,发布完之后打包tag。
hotfix-热修复分支，用来修复线上紧急的bug,以线上版本对应的主分支为基础新建。
test-预发布分支，也可以称为提测分支，可以在此分支上修复bug，以develop分支为基础新建或者合并develop分支。
dev-作为开发分支，用于汇总各feature分支，只能在此分支上进行合并，不能进行开发，这个分支一般上项目负责人使用。
current feature-当前版本迭代功能的分支，业务人员均在feature分支上进行开发。
future feature-未来版本迭代功能的分支，比如某个非常重要的功能需要在几个版本之后开放，且开发耗时比较长，所以需要提前投入开发。如果项目中没有类似场景，可忽略此分支。
Commit描述规范
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
标题行: 必填, 描述主要修改类型和内容
主题内容: 描述为什么修改, 做了什么样的修改, 以及开发的思路等等
页脚注释: 放 Breaking Changes 或 Closed Issues

分别由如下部分构成:
type: commit 的类型
1.feat: 新特性
2.fix: 修改问题
3.refactor: 代码重构
4.docs: 文档修改
5.style: 代码格式修改, 注意不是 css 修改
6.test: 测试用例修改
7.chore: 其他修改, 比如构建流程, 依赖管理.
scope: commit 影响的范围, 比如: route, component, utils, build...
subject: commit 的概述
body: commit 具体修改内容, 可以分为多行
footer: 一些备注, 通常是 BREAKING CHANGE 或修复的 bug 的链接.

定期CodeReview
定期CodReView，可以保证代码的质量，并且发现一些测试人员不易发现的问题

四、自动化
前端工程化的很多脏活累活都应该交给自动化工具来完成。

持续集成将开发人员提交的代码进行快速集成，并且实现自动化构建和测试

持续交付在持续集成的基础上，将集成并自动构建、测试通过的代码自动部署到测试或者仿真生产环境中。

持续部署在持续交付的基础上，进一步自动化，将部署生产环境的工作自动完成。

目前项目中使用gitlab搭配jenkins进行持续集成。

最后编辑于：2020.05.03 17:36:40