前端项目如何管理
前端项目如何管理
前端项目的管理分为两个维度：项目内的管理与多项目之间的管理。css
1. 项目内的管理
在一个项目内，当有多个开发者一块儿协做开发时，或者功能愈来愈多、项目愈来愈庞大时，保证项目井井有理的进行是至关重要的。html
通常会从下面几点来考证一个项目是否管理得很好：前端
- 可扩展性：可以很方便、清晰的扩展一个页面、组件、模块
- 组件化：多个页面之间共用的大块代码能够独立成组件，多个页面、组件之间共用的小块代码能够独立成公共模块
- 可阅读性：阅读性良好（包括目录文件结构、代码结构），可以很快捷的找到某个页面、组件的文件，也能快捷的看出项目有哪些页面、组件
- 可移植性：可以轻松的对项目架构进行升级，或移植某些页面、组件、模块到其余项目
- 可重构性：对某个页面、组件、模块进行重构时，可以保证在重构以后功能不会改变、不会产生新 bug
- 开发友好：开发者在开发某一个功能时，可以有比较好的体验（很差的体验好比：多个文件相隔很远）
- 协做性：多人协做时，不多产生代码冲突、文件覆盖等问题
- 可交接性：当有人要离开项目时，交接给其余人是很方便的
1.1 可扩展性
对于前端项目而言，可扩展性是并不难的，由于不少时候前端的代码、文件分块都是按照页面来的，因此自然就是一块一块的。vue
但这里仍是要提一下，由于有些开发者不喜欢分块，把应该分块的东西杂揉在一块儿，好比：node
- src/
- main/ # main 目录
- css/ # css 集合
- alpha.css
- beta.css
- ...
- js/ # js 集合
- alpha.js
- beta.js
- ...
- alpha.html # alpha 页面
- beta.html # beta 页面
- ...
更好的方式：react
- src/
- main/ # main 目录
- alpha/ # alpha 页面
- index.css # css 入口文件
- index.js # js 入口文件
- index.html # html 入口文件
- ...
- beta/ # beta 页面
- index.css
- index.js
- index.html
- ...
- ...
使前端项目具备高可扩展性，通常从目录文件结构入手，能够参考：目录结构优化。webpack
1.2 组件化
这里的组件化是项目内的组件化，咱们能够把多个页面之间共用的大块代码独立成组件，多个页面、组件之间共用的小块代码独立成公共模块。git
这样作的目的是为了提升代码的可重用性，避免重复造轮子。另外，也有利于代码之间的解耦。github
好比：web
- 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 协做性
当项目变大、多人协做时，咱们就须要管理好哪些是正在开发的代码、哪些是提交测试的代码、哪些是已经上线的代码、如何避免代码冲突与线上新代码被旧代码覆盖等等。
具体能够参考：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 中使用 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 文档化
完善的文档，不论是对组件项目仍是应用项目，都是很重要的。
组件项目须要用文档告诉开发者组件怎么用、有哪些接口；应用项目须要用文档来作小组交流、项目交接等。
后续
更多博客，查看 https://github.com/senntyou/blogs
版权声明：自由转载-非商用-非衍生-保持署名（创意共享3.0许可证）
- 1. 前端项目如何管理
- 2. 如何管理前端项目中的复杂依赖关系
- 3. 前端项目目录如何组织
- 4. 如何区分项目组合管理，项目集管理，和项目管理
- 5. 如何用项目管理软件管理项目进度
- 6. 项目经理如何用项目管理工具进行项目管理
- 7. duo, gulp 管理前端项目
- 8. 【前端开发与项目管理】
- 9. 前端项目应该如何部署
- 10. 如何建立一个前端项目
- 更多相关文章...
- • XSD 如何使用? - XML Schema 教程
- • Mozilla 项目 - 浏览器信息
- • 使用阿里云OSS+CDN部署前端页面与加速静态资源
- • Docker 清理命令
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 前端项目如何管理
- 2. 如何管理前端项目中的复杂依赖关系
- 3. 前端项目目录如何组织
- 4. 如何区分项目组合管理，项目集管理，和项目管理
- 5. 如何用项目管理软件管理项目进度
- 6. 项目经理如何用项目管理工具进行项目管理
- 7. duo, gulp 管理前端项目
- 8. 【前端开发与项目管理】
- 9. 前端项目应该如何部署
- 10. 如何建立一个前端项目