新來個技術總監，禁止我們使用Lombok！

我有個學弟，在一家小型網際網路公司做Java後端開發，最近他們公司新來了一個技術總監，這位技術總監對技術細節很看重，一來公司之後就推出了很多"政策"，比如定義了很多開發規範、日誌規範、甚至是要求大家統一使用某一款IDE。

但是這些都不是我這個學弟和我吐槽的點，他真正和我吐槽的是，他很不能理解，這位新來的技術總監竟然禁止公司內部所有開發使用Lombok。但是又沒給出十分明確的，可以讓人信服的理由。

於是他來找我聊天，問我這個要求到底是否合理。關於這個事情，我認為這位技術總監的出發點是好的，但是做法未免有些極端。

之所以說出發點是好的，是因為使用Lombok確實會帶來很多問題，而且我個人在工作中也基本不主動使用。

之所以說不主動使用，那是因為有些同事的程式碼還是使用了的，所以我也被迫的要安裝Lombok的外掛。

既然聊到這個話題，就簡單說說我的一些看法。

Lombok有什麼好處？

Lombok是一款非常實用Java工具，可用來幫助開發人員消除Java的冗長程式碼，尤其是對於簡單的Java物件（POJO）。它通過註釋實現這一目的。

如果大家對於Lombok比較瞭解的話，可以先跳過這一段，直接往後看，如果不是很熟悉的話，可以簡單瞭解一下。

想在專案中使用Lombok，需要三個步驟：

一、IDE中安裝Lombok外掛

目前Lombok支援多種IDE，其中包括主流的Eclips、Intellji IDEA、Myeclipse等都是支援的。

在IDEA中安裝方式如下:

![-w400][1]

二、匯入相關依賴

Lombok 支援使用多重構建工具進行匯入依賴，目前主要支援maven、gardle、ant等均支援。

如使用maven匯入方式如下：

<dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
    <version>1.18.12</version>
    <scope>provided</scope>
</dependency>

三、程式碼中使用註解

Lombok精簡程式碼的方式主要是通過註解來實現，其中常用的有@Data、@Getter/@Setter、@Builder、@NonNull等。

如使用@Data註解，即可簡單的定義一個Java Bean：

import lombok.Data;
@Data
public class Menu {
    private String shopId;
    private String skuMenuId;
    private String skuName;
}

使用@Data註解在類上，相當於同時使用了@ToString、@EqualsAndHashCode、@Getter、@Setter和@RequiredArgsConstrutor這些註解，對於POJO類十分有用。

即自動幫忙給例子中的Menu類中定義了toString、Getter、Setter等方法。

通過上面的例子，大家可以發現，我們是使用@Data註解大大減少了程式碼量，使程式碼非常簡潔。這也是很多開發者熱衷於使用Lombok的主要原因。

另外，關於Lombok的使用，不同人有不同的看法，因為很多人都使用過Lombok，對於他的優點都比較瞭解，所以接下來我們重點說一下Lombok的使用會帶來哪些問題。

Lombok有什麼壞處？

強X隊友

因為Lombok的使用要求開發者一定要在IDE中安裝對應的外掛。

如果未安裝外掛的話，使用IDE開啟一個基於Lombok的專案的話會提示找不到方法等錯誤。導致專案編譯失敗。

也就是說，如果專案組中有一個人使用了Lombok，那麼其他人就必須也要安裝IDE外掛。否則就沒辦法協同開發。

更重要的是，如果我們定義的一個jar包中使用了Lombok，那麼就要求所有依賴這個jar包的所有應用都必須安裝外掛，這種侵入性是很高的。

程式碼可讀性，可除錯性低

在程式碼中使用了Lombok，確實可以幫忙減少很多程式碼，因為Lombok會幫忙自動生成很多程式碼。

但是這些程式碼是要在編譯階段才會生成的，所以在開發的過程中，其實很多程式碼其實是缺失的。

在程式碼中大量使用Lombok，就導致程式碼的可讀性會低很多，而且也會給程式碼除錯帶來一定的問題。

比如，我們想要知道某個類中的某個屬性的getter方法都被哪些類引用的話，就沒那麼簡單了。

有坑

因為Lombok使程式碼開發非常簡便，這就使得部分開發者對其產生過度依賴。

在使用Lombok過程中，如果對於各種註解的底層原理不理解的話，很容易產生意想不到的結果。

舉一個簡單的例子，我們知道，當我們使用@Data定義一個類的時候，會自動幫我們生成equals()方法 。

但是如果只使用了@Data，而不使用@EqualsAndHashCode(callSuper=true)的話，會預設是@EqualsAndHashCode(callSuper=false),這時候生成的equals()方法只會比較子類的屬性，不會考慮從父類繼承的屬性，無論父類屬性訪問許可權是否開放。

這就可能得到意想不到的結果。

影響升級

因為Lombok對於程式碼有很強的侵入性，就可能帶來一個比較大的問題，那就是會影響我們對JDK的升級。

按照如今JDK的升級頻率，每半年都會推出一個新的版本，但是Lombok作為一個第三方工具，並且是由開源團隊維護的，那麼他的迭代速度是無法保證的。

所以，如果我們需要升級到某個新版本的JDK的時候，若其中的特性在Lombok中不支援的話就會受到影響。

還有一個可能帶來的問題，就是Lombok自身的升級也會受到限制。

因為一個應用可能依賴了多個jar包，而每個jar包可能又要依賴不同版本的Lombok，這就導致在應用中需要做版本仲裁，而我們知道，jar包版本仲裁是沒那麼容易的，而且發生問題的概率也很高。

破壞封裝性

以上幾個問題，我認為都是有辦法可以避免的。但是有些人排斥使用Lombok還有一個重要的原因，那就是他會破壞封裝性。

眾所周知，Java的三大特性包括封裝性、繼承性和多型性。

如果我們在程式碼中直接使用Lombok，那麼他會自動幫我們生成getter、setter 等方法，這就意味著，一個類中的所有引數都自動提供了設定和讀取方法。

舉個簡單的例子，我們定義一個購物車類：

@Data
public class ShoppingCart { 
    //商品數目
    private int itemsCount; 
    //總價格
    private double totalPrice; 
    //商品明細
    private List items = new ArrayList<>();
}
//例子來源於《極客時間-設計模式之美》

我們知道，購物車中商品數目、商品明細以及總價格三者之前其實是有關聯關係的，如果需要修改的話是要一起修改的。

但是，我們使用了Lombok的@Data註解，對於itemsCount 和 totalPrice這兩個屬性。雖然我們將它們定義成 private 型別，但是提供了 public 的 getter、setter 方法。

外部可以通過 setter 方法隨意地修改這兩個屬性的值。我們可以隨意呼叫 setter 方法，來重新設定 itemsCount、totalPrice 屬性的值，這也會導致其跟 items 屬性的值不一致。

而物件導向封裝的定義是：通過訪問許可權控制，隱藏內部資料，外部僅能通過類提供的有限的介面訪問、修改內部資料。所以，暴露不應該暴露的 setter 方法，明顯違反了物件導向的封裝特性。

好的做法應該是不提供getter/setter，而是隻提供一個public的addItem方法，同時取修改itemsCount、totalPrice以及items三個屬性。

總結

本文總結了常用的Java開發工具Lombok的優缺點。

優點是使用註解即可幫忙自動生成程式碼，大大減少了程式碼量，使程式碼非常簡潔。

但是並不意味著Lombok的使用沒有任何問題，在使用Lombok的過程中，還可能存在對隊友不友好、對程式碼不友好、對除錯不友好、對升級不友好等問題。

最重要的是，使用Lombok還會導致破壞封裝性的問題。

雖然使用Lombok存在著很多方便，但是也帶來了一些問題。

但是到底建不建議在日常開發中使用，我其實保持一箇中立的態度，不建議大家過度依賴，也不要求大家一定要徹底不用。

只要大家在使用的過程中，或者評估要不要在程式碼中引入Lombok之前，在想到他的優點的同時，能夠考慮到他給程式碼帶來的問題的，那麼本文的目的也就達到了！

參考資料：

https://time.geekbang.org/column/article/164907

https://projectlombok.org/

[1]: https://www.hollischuang.com/wp-content/uploads/2020/02/15812290986454.jpg