從零構建Java專案（Maven+SpringBoot+Git） #02 奧斯丁專案

Java3y發表於2021-12-07

JavaMavenSpring BootGit

前兩天我說要寫個專案來持續迭代，有好多小夥伴都表示支援和鼓勵，專案的第一篇這不就來了麼~我給專案取了個名字，英文名叫做：austin，中文名叫做：奧斯丁

名字倒沒有什麼特別的含義，我單純覺得這個名字好看，說白了就是我喜歡。在起專案名的時候，可以不要取得那麼規矩。取系統名字可以按自己想法來搞就行了，人家只要用了你的系統，就自然「入鄉隨俗」了。不聊別的了，進入今天的主題吧。

從零開始一個專案，也得搭建技術環境的，所以今天先來聊聊搭建技術環境的內容吧

本文主題大綱：Maven和SpringBoot以及Git

什麼是Maven？為什麼要用Maven？

Maven是一個「專案管理」的工具

我記得以前我在大學的時候，還沒用到Maven，每次學習最頭疼的就是各種的依賴jar包。當我學習到Maven的時候，這個工具給我的第一感覺就是：這東西就是一個「依賴包管理」的工具

初體驗之後，直呼太TM香了！再也不用到處去找jar包了！

其實，Maven不僅僅承擔著「依賴包管理」功能，同時他在日常開發使用中也承擔著「編譯」、「測試」、「打包」、「部署」等等功能。

我在日常開發中常用到的maven命令：

1、mvn compile 
2、mvn test 
3、mvn clean 
4、mvn pakage 
5、mvn install 
6、mvn deploy  
7、mvn versions:set -DnewVersion=xxxx  設定Maven的版本  
8、mvn dependency:tree  檢視maven的依賴樹（排查依賴很有效）

常用引數
-Dmaven.test.skip=true
-Dmaven.javadoc.skip=true

現在Java後端專案很多都是用Maven來作為「專案管理」的工具，至少我接觸的都是。

有的人就好奇了：近幾年不是有個後起之秀Gradle嗎

說實話，我是沒用過（：不過我也去簡單瞭解了一番。

據我瞭解到的，總的來說，Gradle比Maven更靈活和簡潔，目前多用在Android專案上。還有很重要的一點，相對Maven而言，Gradle學習成本更大。

現在Java後端的專案也越來越輕量，很多時候也不需要那麼地”靈活“（Maven提供的功能基本夠用）。對於簡潔來說，XML也不是不能看（畢竟現在大家都在IDE上開發嘛）。所以，這次我構建的專案也直接用的Maven

不過啊，因為我是沒深度使用過Gradle，所以也不能說我用Maven比Gradle一定要合適（：但至少，在現在，我認為Maven還能戰10年

為什麼SpringBoot

這次我選用SpringBoot作為專案的基礎環境，至於為什麼SpringBoot，我先跟大家分享下群裡的對話。

我記得有一天，有個小夥伴在群裡問：今天我去面試了，面試官問我使用SpringBoot有什麼好處

接著，另一個小夥伴回答：使用SpringBoot最大的好處，就是讓我這種垃圾水平的開發都入了行，做上了程式設計師。

我在大學時是學過SSH和SSM的，我學這些的時候還沒用Maven，那時候搭建環境就尤其麻煩了。（當時還專門寫了部落格記錄自己是如何整合SSH和SSM的）

一個專案裡會用好幾種技術棧，不同的技術棧就需要有對應的配置（常見的Spring、SpringMVC、Mybatis）等等，然後這些技術都需要相容對應的版本（一般我們是把這些技術整合到Spring上的）。當我們要引入新的框架，那自然就需要對齊Spring版本並且有對應的配置檔案。

那時候真的是配置地獄（框架們都做得靈活，都支援我們把可能需要改動的內容寫到XML配置上，但隨著時間流逝，我們漸漸發現：這些XML配置我們都維護不動了...)

基於這種背景下，SpringBoot應運而生，它最明顯的就是簡化了我們開發的配置工作。當一項技術能減少開發時工作量都有一個特點：約定大於配置（開箱即用）

只要引入了SpringBoot，那隻要通過幾行的程式碼就能快速地從零寫出對應的HTTP介面（可參考官網SpringBoot 的Quick Start）

以前我們幹這種事，需要整合SpringMVC，需要配置一個Tomcat伺服器，需要對齊它們的版本（是否相容）....

我認為SpringBoot作為使用方，要了解以下兩塊內容：

一、當我們專案我們引入了SpringBoot的依賴(spring-boot-starter-parent)，點進去parent就會發現spring-boot-dependencies這個pom定義了非常多「預設的依賴」。這使得我們在專案中使用的時候，都不用寫版本了（因為SpringBoot已經預設幫我們已經寫上了），還不用擔心版本衝突的問題（：

二、在啟動SpringBoot專案的時候，還會幫我們初始化很多預設的配置。（這裡也是一個面試經常考察的地方「自動配置」）。總的來說，@SpringBootApplication等同於下面三個註解：

@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan

其中@EnableAutoConfiguration是關鍵(啟用自動配置)，內部實際上就去載入META-INF/spring.factories檔案的資訊，然後篩選出以EnableAutoConfiguration為key的資料，載入到IOC容器中，實現自動配置功能！

現在新寫的Java後端專案，基本都是用SpringBoot作為開發環境了（：畢竟是真的爽

作為程式設計師，我最煩的就是搞各種環境配置和版本依賴的問題（真正的髒累活），雖然很多時候只用搞一次，但是感覺很多時候就真的如下圖：

為什麼專案結構是多模組？

我搭建了專案，取了個名字叫：austin，然後我在IDE上新建了幾個Maven Module，目前分別是（後面可能還會新增）：

common(基本資訊->POJO/列舉配置)
support(Data獲取->DB/Redis/Elasticsearch)
service-api（服務介面)
service-api-imp（服務介面實現)
web（HTTP介面)

最開始我們初學寫程式碼的時候，可沒那麼講究，直接在一個包下一把梭就完事了（：

後來，他們說要分包，不同模組的程式碼寫到不同的包上。於是我們會在專案下新建對應包（其實就是資料夾），比如說dao/service/controller

而到現在，基本都是分模組了，不同職責的程式碼被分到對應的模組上。而austin直屬下的pom檔案就一般只用來管理依賴（把依賴和版本資訊定義在父pom上，具體哪個子模組需要引入就好了）

<dependencyManagement>
  <dependencies>
    <!--mysql驅動包-->
    <dependency>
      <groupId>mysql</groupId>
      <artifactId>mysql-connector-java</artifactId>
      <version>5.1.35</version>
    </dependency>
  </dependencies>
</dependencyManagement>

那麼這種分模組又比以前分包好在哪裡呢？

假設我們是分包的，那相當於所有的程式碼寫到一個模組上。每次當我們修改時，我們需要重新編譯整個模組（可能我只改了Dao包的某個實現類，但在編譯的時候會把整個模組都編譯一遍）。

如果是分模組的話，我們直接到模組下 mvn compile -Dmaven.test.skip=true 就完事了。

不過這只是一個方面，說服力好像也不太足。我認為最主要的是，我們分模組了以後可以複用

比如，現在我有austin這個專案，此時為了對資料進行處理，我需要去新建對應的Flink應用。可能受限於環境下，不會把flink相關的程式碼寫在austin專案下

（這也只是舉了個例子，我想表達的是：一個成熟的專案往往不只有一個Git地址就覆蓋了整個功能。在絕大多數時候，不同的功能都會分開到不同的專案上）。

那不同的專案下，很有可能需要做的事情是有重複的（比如我都需要去讀資料庫獲取資料）。那這時候，分模組的好處就體現出來了：可以直接引入對應的jar包(比如support包和common包)。

那就不用在兩個不同的專案上，寫一模一樣的程式碼了（：能夠共用一套程式碼

有沒有小夥伴好奇為什麼api和api-impl是分了兩個模組的嗎？這裡是為了：如果以後引入了RPC呼叫，那我們只需要提供api模組出去就好了，api模組的依賴一般很少。

（解決版本衝突是一件髒累活，人家嵌入你的SDK只是想用你的服務去獲取對應資訊，你別給人家整了一大堆毫無作用的依賴出來）

為什麼Git

到這裡，專案的架子已經搭好了。我要把專案上傳到Gitee跟大家愉快地玩耍（：

Git是一個版本控制工具。把austin被Git管理後，我每次提交的內容都會被看到（：這在多人協作中尤其重要

除此之外，有了“版本”的概念以後，用Git可以隨意回退版本（有後悔藥吃

我當時剛出來實習的時候，那家公司用的是SVN（我當時對版本控制工具理解其實是很模糊的，反正在我當時看來，就是把寫好的程式碼上傳到中央伺服器，只不過它能對比出每次修改的異同）

後來以後，在公司接觸都是Git了（現在開發基本離不開Git了，這玩意本身還是比較好學的，用起來還是挺爽的）

順便發一波我日常用到的Git命令吧：

1. git clone  (克隆程式碼)
2. git checkout -b （新建分支）
3. git checkout (切換分支)
4. git add / git commit /git push （這幾步我基本都是在IDE上用快捷鍵完成，很少自己敲命令）
5. git fetch (獲取最新的修改資訊)
6. git merge (合併程式碼)  
7. git stash /git pop (有的時候臨時會用，把程式碼放到暫存區中)  
8. git reset --hard  (程式碼寫爛了，直接回退吧)

一般Git我是一半用命令列，一半用IDE整合的工具。總的來說，怎麼舒服怎麼來（沒有限定說一定要用命令列，我是自己怎麼操作比較快就怎麼搞）

對於這個專案而言，我這裡使用到Git最大的原因就是：有遠端的倉庫裝載我的程式碼，並且你們能看到（：

Gitee連結：https://gitee.com/austin

GitHub連結：https://github.com/austin