新來個技術總監，禁止我們使用Lombok!
“我有個學弟，在一家小型互聯網公司做 Java 后端開發，最近他們公司新來了一個技術總監。
圖片來自 Pexels
這位技術總監對技術細節很看重，一來公司之后就推出了很多"政策"，比如定義了很多開發規范、日志規范、甚至是要求大家統一使用某一款 IDE。
但是這些都不是我這個學弟和我吐槽的點，他真正和我吐槽的是，他很不能理解，這位新來的技術總監竟然禁止公司內部所有開發使用 Lombok。但是又沒給出十分明確的，可以讓人信服的理由。
于是他來找我聊天，問我這個要求到底是否合理。關于這個事情，我認為這位技術總監的出發點是好的，但是做法未免有些極端。
之所以說出發點是好的，是因為使用 Lombok 確實會帶來很多問題，而且我個人在工作中也基本不主動使用。
之所以說不主動使用，那是因為有些同事的代碼還是使用了的，所以我也被迫的要安裝 Lombok 的插件。
既然聊到這個話題，就簡單說說我的一些看法。
Lombok 有什么好處?
Lombok 是一款非常實用 Java 工具，可用來幫助開發人員消除 Java 的冗長代碼，尤其是對于簡單的 Java 對象(POJO)。它通過注釋實現這一目的。
如果大家對于 Lombok 比較了解的話，可以先跳過這一段，直接往后看，如果不是很熟悉的話，可以簡單了解一下。
想在項目中使用 Lombok，需要三個步驟：
①IDE 中安裝 Lombok 插件
目前 Lombok 支持多種 IDE，其中包括主流的 Eclipse、Intellij IDEA、Myeclipse 等都是支持的。
在 IDEA 中安裝方式如下：
②導入相關依賴
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 之前，在想到他的優點的同時，能夠考慮到他給代碼帶來的問題的，那么本文的目的也就達到了!
