前端项目如何管理

原创 前端彭于晏 随笔 前端 85阅读 19 天前 举报

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

  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,这就得靠测试用例了。
js 模块:jest / mocha / tape / ava
React 组件:enzyme + jest,另外可以使用 react-testing-library 代替 react-dom/test-utils
Vue 组件:vue-test-utils + jest / mocha / tape / ava

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 协作性
      当项目变大、多人协作时,我们就需要管理好哪些是正在开发的代码、哪些是提交测试的代码、哪些是已经上线的代码、如何避免代码冲突与线上新代码被旧代码覆盖等等。
      1.8 可交接性
      当有人要离开项目时,就需要把他负责的代码交接给别人,但怎么样才能使交接是轻松愉快的?
      那就是文档,包括注释文档、接口文档等。想想,如果没有文档,该怎样交接呢?
      1. 多项目之间的管理
        多个项目之间,如何管理好项目之间联系,比如共用组件、公共模块等,保证快捷高效开发、不重复造轮子,也是很重要的。
        一般会从下面几点来考证多个项目之间是否管理得很好:
        组件化:多个项目共用的代码应当独立出来,成为一个单独的组件项目
        版本化:组件项目与应用项目都应当版本化管理,特别是组件项目的版本应当符合 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 仓库一起使用。
2.2 版本化
如果应用项目使用 npm 来管理依赖,就是版本化管理了。
组件项目更不用说了,值得提一下的是组件项目的版本号应当符合 semver 语义化版本规范。
版本格式:主版本号.次版本号.修订号,版本号递增规则如下:

主版本号:当你做了不兼容的 API 修改,
次版本号:当你做了向下兼容的功能性新增,
修订号:当你做了向下兼容的问题修正。
先行版本号及版本编译元数据可以加到“主版本号.次版本号.修订号”的后面,作为延伸。
2.3 统一性
多个项目之间应当使用相同的技术选型、UI 框架、脚手架、开发工具、构建工具、测试库、目录规范、代码规范等,相同功能应指定使用固定某一个库。
这样做的目的是减少项目之间的环境差异,有利于项目之间的代码移植,也更有利于组件化、代码重用。
2.4 文档化
完善的文档,不管是对组件项目还是应用项目,都是很重要的。
组件项目需要用文档告诉开发者组件怎么用、有哪些接口;应用项目需要用文档来做小组交流、项目交接等。

“我自己是一名从事了5年前端的老程序员,辞职目前在做讲师,今年年初我花了一个月整理了一份最适合2019年学习的web前端干货,从最基础的HTML+CSS+JS到移动端HTML5到各种框架都有整理,送给每一位前端小伙伴,这里是小白聚集地,欢迎初学和进阶中的小伙伴。"

加QQ群:931661106(招募中)

关注公众号:蝌蚪前端

每晚7点直播讲课,送前端学习资料,从基础到框架,专业的老师为你指导

加微❤:QD_666_QD

评论 ( 0 )
最新评论
暂无评论

赶紧努力消灭 0 回复