前兩天我說要寫個專案來持續迭代，有好多小夥伴都表示支援和鼓勵，專案的第一篇這不就來了麼~
我給專案取了個名字，英文名叫做：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
總結
說實話，如果還沒工作的人，我建議多學學Maven和Git的基本使用（這樣一來，去到公司就不用一臉懵逼了）
對於SpringBoot的學習是永無止境的，我個人的理解是，在瞭解了用法以後，可以嘗試面向「面試題」進行學習（畢竟面試題面的內容大多數都是比較核心的，至少不是偏門沒有任何用途的）
austin專案構建：
- Maven：依賴包管徑+專案管理（多模組）
- SpringBoot：基礎技術環境搭建（開箱即用）
- Git：版本控制工具（程式碼上傳至遠端Gitee）
今天就到這裡吧。我花了一個晚上搭建了架子，兩個晚上寫了這篇文章。自從有了這個迭代專案的想法以後，晚上的效率嘎嘎地就上去了。
關注我的微信公眾號【Java3y】來聊點不一樣的！
【對線面試官+從零編寫Java專案】 持續高強度更新中！求star!
原創不易！！求三連！！