前端管理和编码规范

一、前端管理

这边的前端管理主要指的是项目管理和团队协作两大块内容。我们先来说下项目管理这块。

（一）、项目管理

这块的主要内容来源于网络上的一篇博客，我稍微做了一些修改。
两个维度：项目内的管理与多项目之间的管理

1. 项目内的管理
   在一个项目内，当有多个开发者一起协作开发时，或者功能越来越多、项目越来越庞大时，保证项目井然有序的进行是相当重要的。一般会从下面几点来考证一个项目是否管理得很好：
   可扩展性：能够很方便、清晰的扩展一个页面、组件、模块
   组件化：多个页面之间共用的大块代码可以独立成组件，多个页面、组件之间共用的小块代码可以独立成公共模块
   可阅读性：阅读性良好（包括目录文件结构、代码结构），能够很快捷的找到某个页面、组件的文件，也能快捷的看出项目有哪些页面、组件
   可移植性：能够轻松的对项目架构进行升级，或移植某些页面、组件、模块到其他项目
   可重构性：对某个页面、组件、模块进行重构时，能够保证在重构之后功能不会改变、不会产生新 bug
   开发友好：开发者在开发某一个功能时，能够有比较好的体验（不好的体验比如：多个文件相隔很远）
   协作性：多人协作时，很少产生代码冲突、文件覆盖等问题
   可交接性：当有人要离开项目时，交接给其他人是很方便的
2. 1 可扩展性
   对于前端项目而言，可扩展性是并不难的，因为很多时候前端的代码、文件分块都是按照页面来的，所以天然就是一块一块的。标准的vue文件具有template，script，style三大模块，天生就具备该属性。
3. 2 组件化
   这里的组件化是项目内的组件化，我们可以把多个页面之间共用的大块代码独立成组件，多个页面、组件之间共用的小块代码独立成公共模块。这样做的目的是为了提高代码的可重用性，避免重复造轮子。另外，也有利于代码之间的解耦。比如：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

- src/
  - data/                    # 常量、静态数据目录
    - data1.js          
    - data2.js
    - ...          
  - components/              # 组件目录
    - componnet1/          
    - componnet2/
    - ...          
  - utils/                   # 工具函数目录
    - util1.js          
    - util2.js
    - ...     
  - ...

1.3 可阅读性

这里的可阅读性有两个方面：目录文件结构、代码结构。

1.3.1 目录文件结构

目录文件结构可阅读性的好与否除了跟开发者有关系外，跟项目的搭建者也有很大的关系，因为如果搭建者在最初就定义好整个项目的目录结构，对后期的开发者是一个很好的约束。可阅读性比较差的目录文件结构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

- src/
  - css/                     # css 集合
    - main/                  # main 目录
      - alpha.css
      - beta.css
      - ...
  - js/                      # js 集合
    - main/                  # main 目录
      - alpha.js
      - beta.js
      - ...
  - html/                    # html 集合
    - main/                  # main 目录        
      - alpha.html           # alpha 页面
      - beta.html            # beta 页面
      - ...

可阅读性比较好的目录文件结构：

1
2
3
4
5
6
7
8
9
10
11
12
13

- src/
  - main/                    # main 目录
    - alpha/                 # alpha 页面
      - index.css            # css 入口文件
      - index.js             # js 入口文件
      - index.html           # html 入口文件
      - ...
    - beta/                  # beta 页面
      - index.css
      - index.js
      - index.html
      - ...
    - ...

1.3.2 代码结构

代码结构的可阅读性大部分取决于开发者的水平，但我们可以使用工具帮助开发者书写规范、格式良好的代码。主要有下面的工具：

● .editorconfig: 统一每个开发人员的编辑器配置
● eslint: 检查 js 语法（包括 jsx 语法），然后最大程度的矫正不符合规范的代码
● stylelint: 检查 css 语法（包括 less, scss 语法），然后最大程度的矫正不符合规范的代码
● prettier: 代码格式优化
● husky + lint-staged: 强制开发人员对代码进行检查、自动矫正与优化

更详细的编码规范，交由接下来的编码规范模块进行讲解。

1.4 可移植性

可能的情况下，让项目具有一定的伸缩性，可以在未来轻松的对项目进行架构升级。

让项目能够轻松的移植某些页面、组件、模块到其他项目，需要对整个项目代码尽量的解耦与模块化。另外，也与后面会讲到的“项目之间的统一性”有关。

1.5 可重构性

对页面、组件的重构是常有的事，但怎样保证在重构之后功能不会改变、不会产生新 bug，这就得靠测试用例了。

● js 模块：jest / mocha
● React 组件：enzyme + jest，另外可以使用 react-testing-library 代替 react-dom/test-utils
● Vue 组件：vue-test-utils + jest / mocha

1.6 开发友好

这主要是从目录结构优化着手，传统mvc中，通常习惯于通过角色组织代码，但是这对Vue应用开发而言并不友好，vue是组件化的应用，更适用与通过功能来组织代码，也就是说完成同一功能的代码放在同一个目录下。

比如：像下面这种目录结构，如果要编辑一个页面，需要到处找页面相关的文件，编辑器上就会形成一个很长的目录树，就不怎么友好：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

- src/
  - css/                     # css 集合
    - main/                  # main 目录
      - alpha.css
      - beta.css
      - ...        # 中间有 30 个页面
  - js/                      # js 集合
    - main/                  # main 目录
      - alpha.js
      - beta.js
      - ...        # 中间有 30 个页面
  - html/                    # html 集合
    - main/                  # main 目录        
      - alpha.html           # alpha 页面
      - beta.html            # beta 页面
      - ...        # 中间有 30 个页面

而像下面这种目录结构，所有的文件都在一个目录下，找文件就很方便，而且很清晰：

1
2
3
4
5
6
7
8
9
10
11
12
13

- src/
  - main/                    # main 目录
    - alpha/                 # alpha 页面
      - index.css            # css 入口文件
      - index.js             # js 入口文件
      - index.html           # html 入口文件
      - ...
    - beta/                  # beta 页面
      - index.css
      - index.js
      - index.html
      - ...
    - ...

1.7 协作性
当项目变大、多人协作时，我们就需要管理好哪些是正在开发的代码、哪些是提交测试的代码、哪些是已经上线的代码、如何避免代码冲突与线上新代码被旧代码覆盖等等。这个具体见接下来的协作流程。
1.8 可交接性
当有人要离开项目时，就需要把他负责的代码交接给别人，但怎么样才能使交接是轻松愉快的？那就是文档，包括注释文档、接口文档等。想想，如果没有文档，该怎样交接呢？
2. 多项目之间的管理
多个项目之间，如何管理好项目之间联系，比如共用组件、公共模块等，保证快捷高效开发、不重复造轮子，也是很重要的。一般会从下面几点来考证多个项目之间是否管理得很好：
组件化：多个项目共用的代码应当独立出来，成为一个单独的组件项目
版本化：组件项目与应用项目都应当版本化管理，特别是组件项目的版本应当符合 semver 语义化版本规范
统一性：多个项目之间应当使用相同的技术选型、UI 框架、脚手架、开发工具、构建工具、测试库、目录规范、代码规范等，相同功能应指定使用固定某一个库
文档化：组件项目一定需要相关的文档，应用项目在必要的时候也要形成相应的文档
2.1 组件化
这里的组件化是项目之间的组件化，我们可以把多个项目共用的代码独立出来，成为一个单独的组件项目。这样做的目的也是为了提高代码的可重用性，避免重复造轮子。另外，也便于版本化管理组件。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

- project1/                  # 项目一
  - package.json
  - src/ 
  - ...
  
- project2/                  # 项目二
  - package.json
  - src/ 
  - ...  
  
- component1/                # 组件一
  - package.json
  - src/ 
  - dist/ 
  - ...
  
- component2/                # 组件二
  - package.json
  - src/ 
  - dist/ 
  - ...

在 project1 中使用 component1、component2:

1
2
3
4
5
6
7
8
9

# package.json
{
  "dependencies": {
    "component1": "^0.0.1",
    "component2": "^0.0.1"
  }
}
import component1 from 'component1';
import component2 from 'component2';

常用组件有：

1
2
3
4

@yourCompany/utils: 工具类
@yourCompany/shortcut.css: 快捷 css 类
@yourCompany/data: 常用静态数据
...

（二）、团队协作

上面的管理比较抽象，下面我们进行具体的协作流程讲解。

1. 权限申请

1.1 Git账号及项目权限

下载按照git后配置一个全局账号，然后申请加入对应项目

2. 协作流程

2.1 派生项目

第一步：找到需要开发的源项目，点击派生（Fock）

第二步：选择派生的命名空间

点击命名空间后就开始派生项目，派生完成后会自动跳转到派生项目，后续的开发都在你派生后的项目下进行。

2.2 克隆项目到本地

● 复制使用ssh克隆的地址

● 克隆项目

我一般习惯在文件夹右键，直接运行命令行进行克隆，也可以使用工具SourceTree等进行克隆

● 检出新分支
找到需要进行开发的分支，并检出新分支
● 提交代码

格式:
■ code：info（code和info见下表）

code info
feat：msg 新功能 feature
fix：msg 修复 bug
merge：msg merge
docs：msg 文档修改
style：msg 格式，不影响代码运行的变动
refactor：msg 重构即不是新增功能，也不是修改bug 的代码变动
test：msg 增加测试
chore：msg 构建过程或辅助工具的变动
rm：msg 删除文件或代码

2.3 发起合并请求

找到你的派生出来的项目，点击合并请求，发起合并请求，并通知相关人员及时复查以及合并代码

二、编码规范

这个因公司而已，我的个人项目习惯采用Airbnb标准代码风格，点击前往官网
地址：https://github.com/airbnb/javascript