Code Review總是讓人又愛又恨，它可以幫助我們在提測之前發現很多代碼中比較“丟人”的問題，但是，Code Review通常會比寫代碼更加耗費精力，因為你需要理解別人的代碼，而為了這一目的，往往需要很多次的溝通。
人們常說“見字如面”。我認為代碼也是一樣，看到一個人的代碼，就會對這個人有一個大概的印象。例如，當你看到一段代碼寫的非常隨意，隨意的格式、隨意的命名、隨意的封裝，然后又沒有單元測試，那我們一般會認為這段代碼的作者是一個不夠嚴謹、做事隨意、有些懶惰，又對自己的代碼責任心不強的人。如果你不是這樣的人，那就需要花費更多的力氣向同事證明自己。而如果在代碼中做好每一個細節，嚴格遵循編碼規范，單元測試覆蓋率比較高，那么同事對你的第一印象一定是這個人還是比較可靠的，跟他合作應該比較愉快。
說了這么多，其實就是想強調Code Review的重要性。那么既然它這么重要，但又給我們帶來了更大的工作量。作為程序員，我們一定會想，能不能自動化？答案當然是可以。事實上現在也有很多公司實現了自動化，例如自動進行靜態代碼分析來確保代碼質量，利用類似Cobertura這樣的工具來檢查單元測試覆蓋程度等等。但是這並不能完全保證代碼的整潔性和可靠性。
有了這些工具之后Code Review輕松了許多，但是這些工具的安裝、使用也是需要花費很高的成本的。所以我想給大家介紹的是一個使用簡單、方便的工具來幫我完成這些任務。在介紹之前，我們先來想一想我們平時在Review別人代碼時可能會注意哪些問題。這里我簡單列出來了一些：
- 拋出的異常不能太過廣泛
- 不能寫
System.out，而是要用日志輸出 - 不能使用
java.util.logging - 如果使用貧血模型開發，每個類需要放到對應的包中
- 接口不能放在實現類的包中
Service層代碼不能訪問Controller層代碼- 合理使用第三方庫
這些事情以前我們都是靠人工來檢查，直到我發現了ArchUnit這個庫。感覺像是抓住了自動化道路上的救命稻草。
什么是ArchUnit？
ArchUnit的官方網站是 https://www.archunit.org
官網中原話介紹是
ArchUnit is a free, simple and extensible library for checking the architecture of your Java code using any plain Java unit test framework.
意思是ArchUnit是一款免費、簡單可擴展的庫，它可以使用任何Java單元測試框架來檢查Java代碼的架構。
也就是說，它的主要功能是用來檢查代碼結構的。那么怎么使用呢？
如何使用？
ArchUnit的簡單絕對不是空談，如果你是maven項目，只需要在pom.xml文件中添加如下依賴：
<dependency>
<groupId>com.tngtech.archunit</groupId>
<artifactId>archunit</artifactId>
<version>0.12.0</version>
<scope>test</scope>
</dependency>
如果你是Gradle項目，使用起來同樣非常簡單
dependencies {
testCompile 'com.tngtech.archunit:archunit:0.8.0'
}
當你添加了依賴以后，就可以為我們前面提到的規則寫測試用例了。
當然，也有一些內建的通用規則，它們定義在
com.tngtech.archunit.library.GeneralCodingRules
這個類中。關於內建規則的細節，可以查看官方文檔。
自定義規則
除了內建規則以外，ArchUnit也支持你定義自己需要的規則，至於如何定義規則，文檔中都有詳細的介紹。當然，也可以參考這個例子來寫一些規則。 https://github.com/TNG/ArchUnit-Examples
如何執行
規則定義好以后如何執行呢？我們說ArchUnit使用起來非常簡單，如果需要測試，對maven項目來說只需要執行命令
mvn test
而對於Gradle項目來說，只要執行命令
gradle test
總結
ArchUnit看起來是一個很酷的三方庫，我並沒有在使用層面做過多介紹，因為我也在摸索中，感興趣的朋友可以和我一起交流。