带你360度玩转项目工程化(一):浅谈项目工程化

最新推荐文章于 2024-07-24 21:47:59 发布

Mark_MMXIX

最新推荐文章于 2024-07-24 21:47:59 发布

阅读量2.8k

点赞数 7

分类专栏：项目工程化文章标签：单元测试 java 项目管理项目工程化自动化

本文链接：https://blog.csdn.net/qq_28540443/article/details/105687490

版权

项目工程化专栏收录该内容

5 篇文章 0 订阅

订阅专栏

带你360度玩转项目工程化(一):浅谈项目工程化

带你360度玩转项目工程化(二):实现规范化Git提交流程

项目工程化定义

工程化即系统化、模块化、规范化的一个过程。
如果说计算机科学要解决的是系统的某个具体问题，或者更通俗点说是面向编码的，那么工程化要解决的是如何提高整个系统生产效率。
与其说软件工程是一门科学，不如说它更偏向于管理学和方法论

项目工程化解决什么问题

工程化解决的问题是，如何提高编码、测试、维护阶段的生产效率。

从什么时候开始需要思考项目工程化？

在我的开发生涯中，经历过多次将一个小项目通过不断迭代升级重构成一个大项目，这里小项目的定义可以说是项目功能较为单一、子系统量小或者是单系统的项目，而大项目的定义则是一个功能复杂，带有n个子系统共同维护的项目，中间无论小项目还是大项目都需要经历需求定义、项目开发、项目测试、项目上线、项目维护这些步骤，一开始对于小项目，在项目管理上比较粗糙，为什么呢？因为项目体量小，功能单一，相对来说开发测试维护都比较简单迅速，不需要一开始投入那么多精力去做项目开发测试维护的规划，但是随着迭代升级，小项目变成了大项目，这时候当一个开发者拿到项目到手上的时候，就只有完整的代码，这时候，我相信绝大部分的开发者都会崩溃，当然崩溃完之后，花费很多点时间总能掌握项目的，这时候回到我们的问题，从什么时候开始需要思考项目工程化？，对，就是完全崩溃完之后。
在这里插入图片描述

我们需要我们的项目是具备一定的开发、测试、维护的效率以及可持续性，需求、开发、测试、运维各个岗位人员按照规范各施其职、分工协作推动项目发展，将时间花在对的地方，而不是多个人在同一个地方持续踩坑，降低效率。

项目工程化需要怎么做？

1. 制定各项规范，让工作有章可循

1.统一团队成员的编码规范，便于团队协作和代码维护
2.目录结构，文件命名规范
3.编码规范：p3c,eslint, stylelint
4.开发流程的规范
- 使用敏捷，增强开发进度管理和控制
- 应对各项风险，需求变更等
- code review 机制
- UAT 提升发布的需求的质量
5.前后端接口规范，其他文档规范

编码规范工具推荐：

Alibaba Java Coding Guidelines 支持Java代码规范检测

使用引导：https://blog.csdn.net/dawei_yang000000/article/details/103031728
eslint，主要用于前端项目规范检测

使用引导：https://juejin.im/post/5d17309be51d45773f2e8f90
stylelint，主要用于前端项目代码规范检测

使用引导：https://www.cnblogs.com/jiaoshou/p/11284204.html

项目管理工具推荐：

JIRA:事务与项目跟踪软件

官方手册： https://confluence.atlassian.com/display/JSZH1

前后端接口管理工具推荐：

swagger

使用引导：https://blog.csdn.net/ii19910410/article/details/90031310
yapi
使用引导：https://hellosean1025.github.io/yapi/documents/index.html

2. 使用版本控制工具，高效安全的管理源代码

使用 git 版本控制工具
Git分支管理
Commit描述规范，例如：task-number + task 描述
创建 merge request，code review 完毕之后方可合并代码

git版本管理工具推荐：
Github https://github.com/
Gitee https://gitee.com/
GitLab https://about.gitlab.com/

git分支管理规范推荐：
- GitFlow
  
  GitFlow介绍：http://www.ruanyifeng.com/blog/2015/12/git-workflow.html
- git-flow-integration，Idea插件
  
  开源地址：https://github.com/OpherV/gitflow4idea
  
  使用引导：https://www.jianshu.com/p/2bad1d6062ec
git其他辅助工具推荐：
git commit templete: git提交信息规范插件(IDEA)
commitizen : git changelog生成工具
standard version ： git changelog生成工具

3. 使用合适的技术和框架，提高生产效率，降低维护难度

每个公司都有自身的技术栈，想我们公司甚至提供自己的一套框架，在中间件的使用上基本都是统一的，这样带来一个好处就是不需要在项目底层设计上花费太多力气，因为每个公司能定下自己的一套技术栈，必定是经过多个项目实践沉淀下来的，当然对于不同时期不同的项目需求的时候，还是需要开发团队对项目具体需求进行评估，选择最为适合项目的技术框架。

4. 提高代码的可测试性，引入单元测试，提高代码质量

曾几何时，我觉得写单元测试是多余的、是浪费时间的，实际上单元测试反而是最有效率，同时兼备维护性。

为什么说多余，浪费时间？

一开始我就是认为写单元测试是形式化、是浪费时间，偏向于写完了程序，直接接口请求/界面调用调试就行了，有什么必要每个function写个测试。
在这里插入图片描述

但是结果呢？

开发的朋友高高兴兴地提测，测试的朋友高高兴兴地提bug,开发的朋友又"高高兴兴"地改bug…如此循环n次，直到质量过关，这个结果是正常的，但是很多时候由于开发者的疏忽，会重复出现同类型的bug，甚至出现明明就还没完成功能的现象，导致这个n很大，导致项目周期变得紧张，最终导致加班。😀😀😀😀😀😀

在这里插入图片描述

小老弟，不是有单元测试吗？

从后端项目来说，我们一般来说，项目结构还是走MVC模式，如图所示：

MVC 分层有助于管理复杂的应用程序，可以在一个时间内专门关注一个方面。例如，可以在不依赖业务逻辑的情况下专注于视图设计,同时也让应用程序的测试更加容易。

MVC 分层同时也简化了分组开发。不同的开发人员可同时开发视图、控制器逻辑和业务逻辑。

利用单元测试保障MVC各层各个子方法的程序质量，实现代码的终极目标，第一个是实现需求，第二个是提高代码质量和可维护性。 这里编写单元测试的时间与调试、来回被测试”优待“的时间其实只少不多，而且单元测试的威力更多不是体现在新代码的编写上，而是对已有代码的更改。 之前我在负责开发某项目重构的时候，单元测试代码覆盖率==0，后果，手动全部功能测一遍，而且还可能遗漏。假如在重构前写好单元测试，就能重构完执行test命令验证就完事了，起码能省掉一部分精力同时开发人员能安心。而且持续维护单元测试，在项目越来越复杂的时候，越能发挥作用，极大降低开发维护成本。
在这里插入图片描述

什么时候开搞单元测试？

我倡导单元测试，但我不认为TDD(测试驱动开发)是一条好路，选择单元测试的时机应该选择合适的时机， 我认为对于Model层、数据库读写一些，通用方法的单元测试可以一开始就写，因为他跟业务的粘性相对没有那么深；往上走就是逻辑层，对于一个项目的开始，需求变动之快，简直就是你写完一个业务功能，他就改一个业务功能的节奏，这时候一开始就让开发人员写单元测试，跟叫他白费力气的意思差不多，对于业务逻辑的单元测试，我觉得起码是一个到了第一稳定版本的时候，才统一写，毕竟在下一个版本来临之前，中间还有一些缓冲的时间，已经经过测试的代码具有验证的价值，这时候写就稳得一逼，当然这个写单元测试只是对于团队的时机选择，个人来说，你什么时候写都可以。

单元测试工具推荐