前端项目如何管理

柔情只为你懂 2022-03-08 13:38 193阅读 0赞

# 前端项目如何管理 #

前端项目的管理分为两个维度：项目内的管理与多项目之间的管理。

## 1. 项目内的管理 ##

在一个项目内，当有多个开发者一起协作开发时，或者功能越来越多、项目越来越庞大时，保证项目井然有序的进行是相当重要的。

一般会从下面几点来考证一个项目是否管理得很好：

*  可扩展性：能够很方便、清晰的扩展一个页面、组件、模块
 *  组件化：多个页面之间共用的大块代码可以独立成组件，多个页面、组件之间共用的小块代码可以独立成公共模块
 *  可阅读性：阅读性良好（包括目录文件结构、代码结构），能够很快捷的找到某个页面、组件的文件，也能快捷的看出项目有哪些页面、组件
 *  可移植性：能够轻松的对项目架构进行升级，或移植某些页面、组件、模块到其他项目
 *  可重构性：对某个页面、组件、模块进行重构时，能够保证在重构之后功能不会改变、不会产生新 bug
 *  开发友好：开发者在开发某一个功能时，能够有比较好的体验（不好的体验比如：多个文件相隔很远）
 *  协作性：多人协作时，很少产生代码冲突、文件覆盖等问题
 *  可交接性：当有人要离开项目时，交接给其他人是很方便的

### 1.1 可扩展性 ###

对于前端项目而言，可扩展性是并不难的，因为很多时候前端的代码、文件分块都是按照页面来的，所以天然就是一块一块的。

但这里还是要提一下，因为有些开发者不喜欢分块，把应该分块的东西杂揉在一起，比如：

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

更好的方式：

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

使前端项目具有高可扩展性，一般从目录文件结构入手，可以参考：[目录结构优化][Link 1]。

### 1.2 组件化 ###

这里的组件化是项目内的组件化，我们可以把多个页面之间共用的大块代码独立成组件，多个页面、组件之间共用的小块代码独立成公共模块。

这样做的目的是为了提高代码的可重用性，避免重复造轮子。另外，也有利于代码之间的解耦。

比如：

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

可以参考：[组件化][Link 2]。

### 1.3 可阅读性 ###

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

#### 1.3.1 目录文件结构 ####

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

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

- 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 页面
          - ...

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

关于目录文件结构的高可读性，可以参考：[目录结构优化][Link 1]。

#### 1.3.2 代码结构 ####

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

主要有下面的工具：

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

上面的具体用法可以参考：

*  [怎样提升代码质量][Link 3]
 *  [搭建自己的前端脚手架][Link 4]

### 1.4 可移植性 ###

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

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

### 1.5 可重构性 ###

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

*  js 模块：[jest][] / [mocha][] / [tape][] / [ava][]
 *  React 组件：[enzyme][] \+ [jest][]，另外可以使用 [react-testing-library][] 代替 `react-dom/test-utils`
 *  Vue 组件：[vue-test-utils][] \+ [jest][] / [mocha][] / [tape][] / [ava][]

可以参考：

*  [react 前端项目技术选型、开发工具、周边生态][react]
 *  [vue 前端项目技术选型、开发工具、周边生态][vue]

### 1.6 开发友好 ###

这主要是从目录结构优化着手，比如：

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

- 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.7 协作性 ###

当项目变大、多人协作时，我们就需要管理好哪些是正在开发的代码、哪些是提交测试的代码、哪些是已经上线的代码、如何避免代码冲突与线上新代码被旧代码覆盖等等。

具体可以参考：[web 项目如何进行 git 多人协作开发][web _ git]。

### 1.8 可交接性 ###

当有人要离开项目时，就需要把他负责的代码交接给别人，但怎么样才能使交接是轻松愉快的？

那就是文档，包括注释文档、接口文档等。想想，如果没有文档，该怎样交接呢？

可以参考：[api 接口管理工具][api]。

## 2. 多项目之间的管理 ##

多个项目之间，如何管理好项目之间联系，比如共用组件、公共模块等，保证快捷高效开发、不重复造轮子，也是很重要的。

一般会从下面几点来考证多个项目之间是否管理得很好：

*  组件化：多个项目共用的代码应当独立出来，成为一个单独的组件项目
 *  版本化：组件项目与应用项目都应当版本化管理，特别是组件项目的版本应当符合 [semver][] 语义化版本规范
 *  统一性：多个项目之间应当使用相同的技术选型、UI 框架、脚手架、开发工具、构建工具、测试库、目录规范、代码规范等，相同功能应指定使用固定某一个库
 *  文档化：组件项目一定需要相关的文档，应用项目在必要的时候也要形成相应的文档

### 2.1 组件化 ###

这里的组件化是项目之间的组件化，我们可以把多个项目共用的代码独立出来，成为一个单独的组件项目。

这样做的目的也是为了提高代码的可重用性，避免重复造轮子。另外，也便于版本化管理组件。

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

在 `project1` 中使用 `component1`、`component2`:

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

常用组件有：

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

组件化一般会与私有 npm 仓库一起使用。

可以参考：

*  [组件化][Link 2]
 *  [私有 npm 仓库][npm]

### 2.2 版本化 ###

如果应用项目使用 npm 来管理依赖，就是版本化管理了。

组件项目更不用说了，值得提一下的是组件项目的版本号应当符合 [semver][] 语义化版本规范。

> 版本格式：主版本号.次版本号.修订号，版本号递增规则如下：
> 
>  *  主版本号：当你做了不兼容的 API 修改，
>  *  次版本号：当你做了向下兼容的功能性新增，
>  *  修订号：当你做了向下兼容的问题修正。
> 
> 先行版本号及版本编译元数据可以加到“主版本号.次版本号.修订号”的后面，作为延伸。

可以参考：

*  [从 1 到完美，写一个 js 库、node 库、前端组件库][1 _ js _node]
 *  [从 0 到 1 再到 100, 搭建、编写、构建一个前端项目][0 _ 1 _ 100_]

### 2.3 统一性 ###

多个项目之间应当使用相同的技术选型、UI 框架、脚手架、开发工具、构建工具、测试库、目录规范、代码规范等，相同功能应指定使用固定某一个库。

这样做的目的是减少项目之间的环境差异，有利于项目之间的代码移植，也更有利于组件化、代码重用。

可以参考：

*  [react 前端项目技术选型、开发工具、周边生态][react]
 *  [vue 前端项目技术选型、开发工具、周边生态][vue]
 *  [搭建自己的前端脚手架][Link 4]
 *  [通用、封装、简化 webpack 配置][webpack]

### 2.4 文档化 ###

完善的文档，不管是对组件项目还是应用项目，都是很重要的。

组件项目需要用文档告诉开发者组件怎么用、有哪些接口；应用项目需要用文档来做小组交流、项目交接等。

## 后续 ##

更多博客，查看 [https://github.com/senntyou/blogs][https_github.com_senntyou_blogs]

作者：[深予之 (@senntyou)][_senntyou]

[Link 1]: https://segmentfault.com/a/1190000015816534
[Link 2]: https://segmentfault.com/a/1190000015297823
[.editorconfig]: http://editorconfig.org/
[eslint]: https://github.com/eslint/eslint
[stylelint]: https://github.com/stylelint/stylelint
[prettier]: https://github.com/prettier/prettier
[husky]: https://github.com/typicode/husky
[lint-staged]: https://github.com/okonet/lint-staged
[Link 3]: https://segmentfault.com/a/1190000015858432
[Link 4]: https://segmentfault.com/a/1190000016481132
[jest]: https://github.com/facebook/jest
[mocha]: https://github.com/mochajs/mocha
[tape]: https://github.com/substack/tape
[ava]: https://github.com/avajs/ava
[enzyme]: https://github.com/airbnb/enzyme
[react-testing-library]: https://github.com/kentcdodds/react-testing-library
[vue-test-utils]: https://github.com/vuejs/vue-test-utils
[react]: https://segmentfault.com/a/1190000017406286
[vue]: https://segmentfault.com/a/1190000017480921
[web _ git]: https://segmentfault.com/a/1190000018165757
[api]: https://segmentfault.com/a/1190000017893659
[semver]: https://semver.org/
[npm]: https://segmentfault.com/a/1190000015297864
[1 _ js _node]: https://segmentfault.com/a/1190000017064659
[0 _ 1 _ 100_]: https://segmentfault.com/a/1190000017158444
[webpack]: https://segmentfault.com/a/1190000017243411
[https_github.com_senntyou_blogs]: https://github.com/senntyou/blogs
[_senntyou]: https://github.com/senntyou
[3.0]: https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh