你想过为啥要用Maven、Git、SpringBoot吗？开始搭建GoodGuy，梦开始的地方

系列文章目录

01、GoodGuy 的诞生（一个消息推送平台）
02、GoodGuy 试图去揣摩一个好产品会如何进行消息推送管理平台的需求设计
03、GoodGuy 个人开源项目部分技术选型的初步思考

---

---

前言

大家好，我是处于 Java 行业下水道，励志重见天日的好人。

重要的事放在前面，热乎乎的 GitHub仓库地址请查阅：https://github.com/haoRen404/GoodGuy.git点击跳转
Gitee搞了点小动作，大家应该也知道，我懒得去验证了，正好代码也需要重新整理，干脆转到 GitHub 了。以后私人项目放 Gitee，公开项目放 GitHub，美滋滋。

---

大家好哇，看了上一篇的朋友，应该都知道我前几天提离职了，现在心情十分愉悦。

剩下这个把星期，我只需要对之前的任务进行收尾，并且进行工作交接，总的来说会比较闲了，所以有更多的时间做 GoodGuy 了。

前面也提过，目前的状况是项目走在博客前面，所以我觉得应该先花点时间，将博客赶上来，再继续做项目，并且在这篇也奉上了 git 仓库地址。（吐槽一下，好久不用 github，变化好大，搞了老半天才 push 成功）

回归正题，我们终于要开始搭建项目了。

GoodGuy 会使用 Maven 来构建项目，使用 git 来管理项目代码，项目会采用分模块的方式基于 SpringBoot 框架进行技术整合。

很多人可能会觉得，选用这些工具和技术是理所当然的，并不会去细究为何使用它们，所以我想聊一聊。

---

一、为什么用 Maven？

Maven 是一个项目管理工具。Maven 提供了一个项目对象模型文件（pom.xml），根据一定的规范编写该对象模型文件，我们就可以轻松构建项目。

还记得初学 Java 的时候，任何依赖包都要自己到官网或者第三方网站去下载，然后拷贝到项目 lib 目录下，再引入到项目中进行使用。

为什么要使用 Maven？因为老师告诉我要用 Maven？但是即使不使用我们也能够进行 B/S 项目的开发啊，为何还要使用 Maven 呢？

1、自动下载 jar 包并重复利用

在以前，我需要自己去下载 jar 包，很多第三方 jar 没有官网，下载很费解，经常找半天。而且每创建一个新项目，都需要重复地进行 jar 包的拷贝和管理。这样会存在大量的重复工作，和大量重复的 jar 包。

而使用 Maven，只需要在本地仓库存储一份 jar 包，在项目中通过一定的规范引入 jar 包即可，也就是我们所说的“Maven 坐标”。这样不仅节省存储空间，构建项目也会更加灵活。

2、自动下载依赖 jar 包

jar 包往往都不是独立的，A 包中引用了 B 包，这种引用关系称之为依赖，各个 jar 包之间会形成复杂的依赖关系。此时如果只引入了 A 包，但未引入 B 包，A 包是不能正常工作的。举个例子，commons-fileupload-1.3.jar 依赖于 commons-io-2.0.1.jar，如果没有 IO 包，FileUpload 包就不能正常工作。

还有，当我们拿到一个新的 jar 包时，你怎么知道这个 Jar 包是否完整，是否需要添加其他 jar 包？很难搞吧？

还有，假如项目特别大，需要上百个，乃至几百个 jar 包，你还觉得自己拷贝 jar 包到 lib 目录下是一件容易的事情吗？

这些事情，Maven 可以帮我们做。我们需要使用 commons-fileupload-1.3.jar 包，只需要在 pom.xml 中引入即可，Maven 会自动帮我们下载 commons-io-2.0.1.jar。

3、自动解决 jar 包冲突

上面是 jar 包少了的情况，jar 包其实多了也不行，容易造成 jar 冲突。举个例子，项目中有 A、B、C 三个模块，依赖关系是 A <-- B <-- C。当 A 中引入了 log4j.1.2.17.jar，而 B 中引入了 log4j.1.2.14.jar，此时 C 就不知道应该引入哪个版本的 log4j jar 包。冲突少的情况下，我们可以手动处理，但是也有个上百个，人工也无能为力。

而 Maven 会使用最短路径者优先和先声明者优先两个原则来解决 jar 包冲突问题。此时 C 会引入 log4j.1.2.14.jar。

最短路径者优先：产生依赖冲突的依赖采用离项目最近（就是路径最短的）的那个版本
先声明者优先：相同路径深度时，采用最先声明的那个版本

4、模块拆分，并实现分布式部署

对于一些大型项目来说，如果所有代码都集中在一个模块中，那样会显得特别臃肿，而且项目构建和编译也会变得缓慢。而项目拆分能够很好地解决这些问题。

项目拆分主要注意：开闭原则（对扩展开放、对修改关闭）、高内聚低耦合。

我们搭建的是微服务，服务需要独立部署，而 Maven 拆分服务之后，可以实现分布式部署。

编译、打包、测试、部署

其实 Maven 不仅仅是用来进行依赖的管理，还有项目编译、打包、测试、部署等功能。

对标产品 Gradle

有一个与之对标的后起之秀叫 Gradle。Gradle 比 Maven 更简洁灵活，但是学习成本更大。我没学习过 Gradle，暂时如果没需求的话，可能一时半会也不会去学习 Gradle，所以还是用 Maven。其实 Gradle 在安卓开发会比较火，Java 开发还是用 Maven 的人多。再则，其实灵活也不一定是好事。

Maven 常用命令：

打包：mvn package
编译：mvn compile
清空：mvn clean（清除编译后目录，默认是target目录）
运行测试：mvn test
安装jar包到本地仓库中：mvn install
跳过测试：mvn xxx -DskipTests

二、为什么用 Git？

版本控制

git 是一个开源的分布式版本控制软件,用以有效、高速的处理从很小到非常大的项目版本管理。

告诉大家一个秘密，其实毕业论文也可以使用 git 来进行版本管理。大概在一年前，好人和室友都在为了毕业而奋笔疾书。好人累了，端起水杯来到室友旁边，看着他的文件夹：

毕业论文_初稿.docx
毕业论文_修改1.docx
毕业论文_修改2.docx
毕业论文_修改3.docx
毕业论文_终稿.docx
毕业论文_最终稿.docx
毕业论文_再终一次.docx
毕业论文_死也不改.docx

好人会心一笑，回到电脑前打开 git 仓库地址，暗自窃喜。

如果把毕业论文替换成项目代码，是不是明白 git 是干嘛用的了，可以用来进行代码版本管理。

使用 git 我们就能够进行版本控制了，但是版本记录只能保存在本地。我们可以配合 gitee、github 等远程代码仓库，通过 git 将代码提交到代码仓库，也可以从代码仓库拉取最新代码。所以 git 对项目版本的迭代、代码存储、团队合作都有很大的辅助作用。

如果今后有网友想和好人一起开发 GoodGuy，那时通过 Git 就能轻松实现团队开发。

版本控制常用命令：

提交代码到仓库的命令：
git add *.c
git add README
git commit -m '初始化项目版本'
git init
git add .
git commit 

拷贝项目到本地：
git clone url

提交与修改：
git add 添加文件到仓库
git status 查看仓库当前的状态，显示有变更的文件
git diff 比较文件的不同，即暂存区和工作区的差异
git commit 提交暂存区到本地仓库
git reset 回退版本
git rm 删除工作区文件
git mv 移动或重命名工作区文件

分支控制

git 不仅能够进行版本管理，其实其精髓是分支管理。使用分支意味着可以从开发主线上分离开来，然后在不影响主线的同时继续工作。

比如，团队需要同时开发两个功能A、B。主线任务是A，必须完成；支线任务是B，进行技术调研，可能实现不了。此时可以为 B 开辟分支，主线和支线可以同时开发，当 B 开发好了，进行分支合并。

当然合并的时候可能会出现合并冲突，git 为我们提供了代码对比工具，手动修改冲突的代码。

分支管理的常用命令：

git branch 查看分支
git branch aa 添加分支aa
git checkout aa 切换到aa分支
git branch -d aa 删除aa分支
git branch -d aa 合并完后就可以删除分支

关于 git 更多的知识大家可自行了解。

三、为什么用 SpringBoot？

SpringBoot 应该每个 Java 开发都接触过的吧，谁还没尝试过 SpringBoot，可真得尝试一下了，实在太好用了。

记得最开始使用 SSM 的时候，就是把 SSM 三个框架整合起来都非常费劲，版本冲突、配置地狱，可真的让一个新手非常头大。后来学习了 SpringBoot，啥技术整合都能轻松搞定，大大拉低了 Java 入行门槛。

SpringBoot 本身并不提供 Spring 框架的核心特性以及扩展功能。它只是 Spring 框架的脚手架框架，能够让我们快速、敏捷地进行 Spring 开发。同时它集成了大量常用的第三方库配置（如 Redis、MongoDB、JPA、RabbitMQ、Quartz 等），SpringBoot 应用中这些第三方库几乎可以零配置进行开箱即用，大部分的 SpringBoot 应用都只需要非常少量的配置代码，开发者能够更加专注于业务逻辑。

约定大于配置

SpringBoot 之所以能够整合几乎所有框架，之主要得益于其核心设计思想——约定大于配置。通俗地讲，所有的配置项，能设定默认值的项都设定了默认值，开发者只需要补齐未能设置默认值的配置项即可，如果对默认值不满意，再配置一下差异化的配置项即可。这样所有开发细节都依据约定大于配置思想进行了实现，让开发者尽可能少地配置，更关注业务。

Starters

另外还有 Starters 机制。

Spring Boot Starters 基于约定优于配置的理念来设计，Spring Boot Starter 中有两个核心组件∶ 自动配置代码和提供自动配置模块及其它有用的依赖。也就意味着当我们项目中引入某个 Starter，即拥有了此软件的默认使用能力，除非我们需要特定的配置，一般情况下我仅需要少量的配置或者不配置即可使用组件对应的功能。

SpringBoot 提供了非常多的 Starter，并且鼓励第三方技术开发自己的 Starter。Starter 让 SpringBoot 整合技术变得非常简单，某项技术或某个功能场景所需要的配置和依赖都封装到了 Starter 里面，只需要在 Maven pom.xml 中引入 Starter 即可开箱即用。

比如我们需要搭建 Web 项目，只需要引入下方的 Web 依赖即可。

<dependency>
    <groupId>org.springframework.bootgroupId>
    <artifactId>spring-boot-starter-webartifactId>
dependency>

Spring、SpringBoot、SpringCloud 的关系

Spring 是整个 Spring 生态的基石，其最强大的两个核心功能是 IOC、AOP。正是 IOC、AOP 成就了 Spring，基于 IOC、AOP 不断发展，诞生了 Spring 事务、SpringMVC、SpringBoot 等一系列伟大的技术。如今 Spring 生态几乎能够为所有企业级 Java 开发提供解决方案。

SpringBoot 是在 Spring 的基础上诞生的，SpringBoot 的名气可能比 Spring 还要大，有些朋友可能觉得 SpringBoot 已经替代了 Spring，其实 SpringBoot 的诞生并不是为了取代 Spring。前面我们提到过：“SpringBoot 本身并不提供 Spring 框架的核心特性以及扩展功能。它只是 Spring 框架的脚手架框架，能够让我们快速、敏捷地进行 Spring 开发。”所以 SpringBoot 是为了让广大开发者更好地使用 Spring。SpringBoot 约定大于配置的理念和 Starters 机制，快速整合了市面上的轮子，为 Spring 提供了更强大的生命力。

SpringCloud 其实并不属于一门技术，而是一系列框架的有序集合，将已有的优秀技术方案基于 SpringBoot 再封装，简化了分布式系统基础设施的开发。SpringCloud 集成了服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等功能，为微服务开发提供了一套完整的解决方案。

总结

说真的，如果大家还没有进入职场，Git 还是得认真学一下，不要觉得会推拉代码就行了，团队开发中会大不一样。建分支、分支合并、合并冲突等，是经常发送的事情。当然，合并冲突，按照一定的规则提交代码是可以有效避免的。

SpringBoot 的相关内容，其实上面讲得很简陋，SpringBoot 的学习我觉得越深入越好，毕竟它可以整合所有技术。约定大于配置、Starters、自动装配、@SpringBootApplication 注解等，都是很重要的内容，大家先自行了解吧。

再一次贴上 github 地址：https://github.com/haoRen404/GoodGuy.git
希望能和大家一起学习进步。

篇幅有限，咱们先说这么多，欢迎批评指正。