代碼檢查又一利器：ArchUnit

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看起來是一個很酷的三方庫，我並無在使用層面作過多介紹，由於我也在摸索中，感興趣的朋友能夠和我一塊兒交流。