前端项目如何管理

前端项目如何管理

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

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

使前端项目具有高可扩展性,一般从目录文件结构入手,可以参考:目录结构优化

1.2 组件化

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

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

比如:

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

可以参考:组件化

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

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

- 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,这就得靠测试用例了。

可以参考:

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

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

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

1.7 协作性

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

具体可以参考:web 项目如何进行 git 多人协作开发

1.8 可交接性

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

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

可以参考: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 中使用 component1component2:

# 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 仓库一起使用。

可以参考:

2.2 版本化

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

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

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

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

先行版本号及版本编译元数据可以加到“主版本号.次版本号.修订号”的后面,作为延伸。

可以参考:

2.3 统一性

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

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

可以参考:

2.4 文档化

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

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

后续

更多博客,查看 https://github.com/senntyou/blogs

作者:深予之 (@senntyou)

版权声明:自由转载-非商用-非衍生-保持署名(创意共享3.0许可证


前端小站
web, 前端, javascript, nodejs, electron, babel, webpack, rollup, react, vue ...

达则兼济天下,穷则独善其身。

12.7k 声望
6.5k 粉丝
0 条评论
推荐阅读
Spring 源码解析十五:SpringCloud 的基础组件
Spring 源码解析十五:SpringCloud 的基础组件SpringCloud 并不是只有一个项目,而是很多项目构成的生态体系总称,如spring-cloud-netflix: 对 https://github.com/netflix 开源组件的集成spring-cloud-gateway: ...

深雨2阅读 2.6k

从零搭建 Node.js 企业级 Web 服务器(零):静态服务
过去 5 年,我前后在菜鸟网络和蚂蚁金服做开发工作,一方面支撑业务团队开发各类业务系统,另一方面在自己的技术团队做基础技术建设。期间借着 Node.js 的锋芒做了不少 Web 系统,有的至今生气蓬勃、有的早已夭折...

乌柏木140阅读 11.9k评论 10

从零搭建 Node.js 企业级 Web 服务器(十五):总结与展望
总结截止到本章 “从零搭建 Node.js 企业级 Web 服务器” 主题共计 16 章内容就更新完毕了,回顾第零章曾写道:搭建一个 Node.js 企业级 Web 服务器并非难事,只是必须做好几个关键事项这几件必须做好的关键事项就...

乌柏木60阅读 5.9k评论 16

再也不学AJAX了!(二)使用AJAX ① XMLHttpRequest
「再也不学 AJAX 了」是一个以 AJAX 为主题的系列文章,希望读者通过阅读本系列文章,能够对 AJAX 技术有更加深入的认识和理解,从此能够再也不用专门学习 AJAX。本篇文章为该系列的第二篇,最近更新于 2023 年 1...

libinfs39阅读 6.1k评论 12

封面图
从零搭建 Node.js 企业级 Web 服务器(一):接口与分层
分层规范从本章起,正式进入企业级 Web 服务器核心内容。通常,一块完整的业务逻辑是由视图层、控制层、服务层、模型层共同定义与实现的,如下图:从上至下,抽象层次逐渐加深。从下至上,业务细节逐渐清晰。视图...

乌柏木39阅读 7.1k评论 6

CSS 绘制一只思否猫
欢迎关注我的公众号:前端侦探练习 CSS 有一个比较有趣的方式,就是发挥想象,绘制各式各样的图案,比如来绘制一只思否猫?思否猫,SegmentFault 思否的吉祥物,是一只独一无二、特立独行、热爱自由的(>^ω^&lt...

XboxYan41阅读 2.8k评论 14

封面图
还在用 JS 做节流吗?CSS 也可以防止按钮重复点击
举个例子:一个保存按钮,为了避免重复提交或者服务器考虑,往往需要对点击行为做一定的限制,比如只允许每300ms提交一次,这时候我想大部分同学都会到网上直接拷贝一段throttle函数,或者直接引用lodash工具库

XboxYan34阅读 2.2k评论 2

封面图

达则兼济天下,穷则独善其身。

12.7k 声望
6.5k 粉丝
宣传栏