誰再把IDEA的Project比作Eclipse的Workspace，我就跟誰急
阿新 • • 發佈：2021-02-01
# 前言
你好，我是A哥(YourBatman)。
有一個觀點：**若一個Java開發者能把IDEA玩得666，則技術一定不會差；但若玩不轉IDEA（如不會設定、定製、解決日常問題、快捷鍵等等），那大概率水平很一般。因為高手一般得有高手的樣子**，你同意這個觀點嗎？
通過[上篇文章](https://mp.weixin.qq.com/s/Tt7tmegWOOwaKYhY6wxcDg) 你也瞭解到，現今的Javaer絕大部分都使用IntelliJ IDEA作為IDE進行開發，但同時發現（從身邊同事調查）大部分同學都並不能很好的使用IDEA，其中表現最為突出的是IDEA裡的**Project和Module**兩個概念，混淆不清或者概念完全扭曲。
A哥是一個相對來講很注重基礎知識搭建的Javaer，所以對於最常用的工具也是如此，願意花些時間去搞明白，包括頁佈局、功能定製、外掛、以及快捷鍵都會調為自己最順手的狀態，畢竟**工欲善其事，必先利其器**。
本文將著眼於幫你深入的介紹IntelliJ IDEA裡最重要的兩個概念：**Project和Module**，它是最最最基礎也是最重要的，我認為本文不僅適合使用IDEA的萌新，同樣適合使用IDEA的“老手”（曾經eclipse的重度使用者尤甚）。
## 本文提綱
## 版本約定
- IntelliJ IDEA：2020.3.1
# 正文
IntelliJ IDEA相較於Eclipse可謂是後起之秀，2006年開始嶄露頭角，2012年整體效能上完敗Eclipse，2016年市場份額完成全面超越，一步步的逐漸成為JVM平臺的主流IDE。
正是由於有這樣的歷史程序，有大批“老”程式設計師是從Eclipse過度到IDEA來的，因此就有了一個頗具代表性的概念對比表格，方便“遷移”：
誠然，IntelliJ IDEA的使用成本比eclipse略高，在那樣的歷史背景下，這張表格確實降低了“老”程式設計師們的遷移過度成本，即使現在看來這張表格的描述**並不準確**，設定具有極大的誤導作用（副作用開始展現......）。
IDEA和eclipse的概念類比上，最“著名”的當屬**把IDEA的Project比作Eclipse的Workspace**，回憶下你當初是不是經常聽到這樣的聲音？部落格文章這樣說、培訓機構老師這樣說、甚至大學的老師也是教你這麼去理解的。更有甚者，對於很多“中毒”很深的、曾經的eclipse使用者來說，他們是這樣使用IDEA的：
實現了所謂的：**IDEA在同一視窗顯示多個專案**。若你發現你身邊有這麼樣管理專案的同事，那麼他是你的“前輩”沒跑了，因為鐵定是eclipse的資深使用者，然後遷移到IDEA來。
這種做法是錯誤的，**毫不相干的專案（遠端呼叫不叫有關係）沒有理由放在同一視窗內**，除了干擾還是干擾。Eclipse裡有workspace工作空間的概念尚可理解，可IDEA裡是絕對不要這麼做。
在 IntelliJ IDEA 中，沒有類似於 Eclipse 工作空間（Workspace）的概念，而是提出了Project和Module這兩個概念。本文來告訴你，IntelliJ IDEA是如何管理專案Project、模組Module以及它倆關係，看完之後你會發現單這一點IntelliJ IDEA就比Eclipse優秀得多。
## Project和Module概念
### 什麼是Project
Eclipse中一個Workspace可以包括多個Project，而在IDEA裡Project是**頂級概念**。
Project（翻譯為：專案）IntelliJ IDEA的**頂級**組織單元，它是個**邏輯概念**。一般來說一個Project代表一個**完整的**解決方案，如它可包含多個部分，如：
1. 原始碼
2. 構建指令碼
3. 配置檔案
4. 文件
5. SDK
6. 依賴庫
7. ...
也就是說Project是個完整體，是個資源的集合，扔到任何地方都是可以被解釋的。
> 說明：建議把Project翻譯為專案，而非工程，不在一個維度。因為一個module其實也可以理解為一個工程，避免混淆
### 什麼是Module
模組是是專案Project的一部分，**必須**隸屬於Project而存在。它可以**獨立**編譯、測試、執行甚至部署。
模組是分而治之思想的體現，是降低**大型專案複雜度**的一種有效手段。模組是可重用的，若需要，一個模組可以被多個模組引用，甚至多個Project專案引用（比如commons模組）。
---
此處強烈不再建議你把Eclipse的Workspace引入進來做類比，那隻會把你帶跑偏了。細品這兩個概念定義，總結一下：
1. 在IDEA中，Project專案是**最頂級**的結構單元，一個IDEA視窗有且只能代表一個Project
1. 現在知道為何把user、account、order扔到一個視窗裡有多麼的不合適了吧
2. 一個Project由一個or多個Module模組組成，對於**大型專案**來講一般會有N多個module組成，如dubbo專案結構如下圖所示：
3. 一個module模組裡，依舊可以有子模組，曾經可無限延伸（但不建議太多）
4. **Project是個邏輯概念，Module才是最終的存在形式**
### 錯誤使用
**優點：**
1. 一個視窗，能看見全貌
**弊端：**
2. 視窗功能不單一。account、order、user屬於不同專案，是為了解決不同問題而存在，沒有理由放在一起
3. 干擾性太強。比如他們三都有類叫`ProcessService`，那麼在你查詢的時候永遠無法“精確定位”
4. 額外效能開銷。比如你只想開發user，但還得把其它的載入進來，完全沒有必要嘛。
1. 說明：idea不能像eclipse一樣close project的，畢竟人家那是workspace的概念，而idea同一視窗屬於同一專案，總不能說關閉某個模組吧，模組一般相關性很強，完全沒必要單獨開/關
2. 想一想，若你一個人負責了20+個專案，每次開啟是不是得花上個幾分鐘呢？
5. 概念上混亂。這麼放在一起，其實就不是user專案、order專案了，而是user模組、order模組，很明顯概念上就不準確了
### 正確使用
這種使用方式介面清爽，執行流暢，解決了上面錯誤方式的所有弊端。
## 新建專案Project
萬丈高樓平地起，使用IDEA的第一步一定是新建一個專案Project：
或者你也可以在視窗**內部**新建，頂部選單欄`File -> New -> 三選一`：
三種建立方式：
1. 建立一個全新專案
2. 開啟現有專案
3. 從VCS版本控制系統裡clone一個專案
本文就以1為例，因為2和3從本質上講都叫開啟專案，並不會經歷建立流程。下面我們按步驟走一篇建立流程：
第一步：選擇建立專案的方式，本文選擇建立建立Java專案
第二步：選擇根據模版建立專案。這個在maven還沒出現之前挺有用，現在幾乎不用了，因此一般都不勾選
第三步：填寫專案名、專案位置（以及同步建立的模組名、位置等，可選）
- **①**：專案儲存位置，一般作為整個專案的根目錄
- **②**：內容根目錄
- **③**：模組檔案存放的目錄
- **④**：專案格式檔案（IDEA負責識別，後面它還會出鏡）
`More Setttings`選項預設是收起狀態，也就是說大多數情況下建立時你並不需要修改同步建立的模組的這些資訊，而實際上也確實是這麼幹的。
點選Finish，IDEA **100%**就會在新視窗（或者覆蓋本視窗）開啟新建立的這個專案：
該專案在硬盤裡的表現形式僅僅是一個檔案目錄而已：
### .idea資料夾的作用
每個Project專案都對應**1個** .idea資料夾（隱藏目錄），該專案所有特定設定都儲存在該.idea資料夾下，比如專案模組資訊、依賴資訊等等。
一般來講它裡面會有這些檔案/目錄：
- `misc.xml`：描述該專案一些混雜資訊，如SDK、語言等級、專案輸出的目錄等等
- `modules.xml`：描述該專案有哪些Module模組
- `workspace.xml`：描述視窗的資訊。如Project視窗在左邊還是右邊，窗體大小，顏色，是否隱藏，滾動情況等等（每個Project都允許你個性化配置，規則都被記錄在這個檔案裡）
- `vcs.xml`：使用的VCS工具資訊，如Git
除了這些，一些外掛也經常會往這個目錄增加檔案，如：
- `saveactions_settings.xml`：saveaction外掛的專屬配置檔案
- `jarRepositories.xml`：遠端倉庫配置檔案
- `encodings.xml`：描述模組資料夾編碼資訊的配置檔案
- `compiler.xml`：描述每個module模組使用的編譯器資訊的檔案。如使用1.8編譯，是否加了編譯引數`-parameters`等等都在這裡體現
總的來講，這個資料夾裡面的東西**不用關心**，由IDEA/外掛自己自動維護，我們只需要介面化操作即可。當然嘍，若瞭解一二對於定位一些常見問題（如不知`-parameters`是否生效）是有幫助的。
## 新建模組Module
建立好一個Project預設會有一個**同名的**的module（Empty Project除外），如果專案比較小複雜度較低，一個模組足矣。但是，稍微有點複雜性的專案一般都希望進行模組拆分，建立多個模組，分而治之。比如：
- hello-service：實現核心業務功能處理
- hello-persistence：複雜持久化工作
- hello-client：作為客戶端暴露出去
第一步：頂部選單欄給該專案建立模組
當然還有一種方式是在`Project Structure`裡建立（這個咱們下篇文章再聊）：
第二步：選擇該模組型別，可以是Java專案、maven專案、Kotlin專案等等都行
第三步：給模組命名，並制定該module模組的存在位置。一般來講只需要寫名稱即可，模組的路徑預設會放在project目錄的**子目錄**下
關於目錄選擇再強調一遍：預設情況下模組路徑會在Project（或者父模組）的**子目錄**下，但這並不是必須的，你也可以改為和Project的同級目錄也是可以的，邏輯上依舊屬於Project的模組，不會有問題。但一般建議保持這種層級關係而不要修改~
> 若是父子目錄，層級關係更明顯些，否則是一種plat平鋪目錄關係，看著會不太“舒服”
點選Finish，在Project視窗就可以看見該模組啦（層級結構展示哦）：
這個時候的Project - Module層級結構圖是這樣子的：
**這時我就丟擲一個問題，若要實現下圖這種層次結構（plat全部平級），新建模組時需要注意些什麼呢？**
---
模組建立好後，這時再看看`.idea`這個資料夾裡的`modules.xml`，內容為：
### xxx.iml檔案的作用
每個Module模組都對應一個**同名的** .iml檔案，用於描述該模組的相關資訊。如：SDK、語言等級、依賴、原始碼所在位置、輸出路徑等等。
# 總結
本文主題是介紹IDEA的Project和Module兩個重要概念，然後再通過具體示例的方式加深理解，講的還是比較清楚的（可能是全網最清楚的？），希望可以幫助到你加深對IDEA的理解，**再也不要把IDEA的Project比作Eclipse的Workspace**。
簡單總結一下本文內容：
- Project是一個不具備任何編碼設定、構建等**開發功能**的概念，主要作用就是起到一個專案定義、範圍約束的效果（比如user專案，裡面所有內容應該是為了解決user問題而存在的），你也可以理解它就是一個目錄，然後這個目錄的名字就代表專案名
- Module模組是程式碼的實際表現形式。在預設情況下，一個Project對應一個Module，它倆“合二為一”，對於中大型專案來說，一般都會使用**多模組**程式設計
下篇預告：在IDEA中，對專案結構`Project Structure`的設定**尤為重要**，下篇就為你剖析該頁面每個tab選項，到底如何玩轉它，具備一個高手的樣子，這對你理解Maven專案也將非常非常有幫助，敬請關注
## 本文思考題
本文所屬專欄：**IDEA**，後臺回覆專欄名即可獲取全部內容，已被*https://www.yourbatman.cn*收錄。
**看完了不一定懂，看懂了不一定會**。來，文末3個思考題幫你覆盤：
1. IDEA的Project和eclipse的workspace的本質區別在哪裡？
2. 如何給Project/module單獨新增依賴庫？
3. IDEA模組的.iml檔案有什麼作用？
## 推薦閱讀
- [IntelliJ IDEA 20週歲啦，為期2天的週年慶活動對開發者免費開放](https://mp.weixin.qq.com/s/Tt7tmegWOOwaKYhY6wxcDg)
- [IntelliJ IDEA 2020.3正式釋出，年度最後一個版本很講武德](https://mp.weixin.qq.com/s/vNnfKEGRm7R3PN_lCtXJDA)
- [IntelliJ IDEA 2020.2正式釋出，諸多亮點總有幾款能助你提效](https://mp.weixin.qq.com/s/8voJSbmcBbdfNUCUBIcKcA)
```java
System.out.println("點個贊吧!");
print_r('關注【BAT的烏托邦】！');
var_dump('私聊A哥：fsx1056342982');
console.log("點個贊吧！");
NSLog(@"關注【BAT的烏托邦】！");
print("私聊A哥：fsx1056342982");
echo("點個贊吧！");
cout << "關注【BAT的烏托邦】！" << endl;
printf("私聊A哥：fsx1056342982");
Console.WriteLine("點個贊吧！");
fmt.Println("關注【BAT的烏托邦】！");
Response.Write("私聊A哥：fsx1056342982");
alert("點個贊吧！");
```
作者簡介：A哥(YourBatman)，Spring Framework/Boot開源貢獻者，Java架構師，領域專家，DDD驅動設計。**非常注重基本功修養**，底層基礎決定上層建築，才能煥發程式設計師更強生命力。擅長結構化拆解專題，抽絲剝繭頗具深度。這些專題也許可能大概是**全網最好或獨一份**哦，歡迎自取。
