公衆号關注 “五分鐘學Java”
作者 ：ramostear
如果您正在閱讀此文，想必您對 Project Lombok 已經有了一段時間的了解。您是否正準備擁抱 Lombok? 還是正準備将如此酷炫的項目推薦給你的團隊？如果您準備那麼做，不妨聽聽我在使用 Lombok 一年後的一些感受。
我承認，Lombok 是一個很不錯的 Java 庫，它可以讓你在少寫代碼的同時耍耍酷，簡單的幾個注解，就可以幹掉一大片模闆代碼。但是，所有的源代碼很多時候是用來閱讀的，隻有很少的時間是用來執行的 (你可以細品這句話)。
一年以前，我和大多數人都認為 Lombok 的出現會讓 Java 的編碼體驗會更好，并極力的在我的團隊中推薦使用 Lombok。一年以後，我開始對此産生顧慮，尤其是在我準備為開源的部落格系統 Una-Boot 更新 Java 版本時，我才意識到 Lombok 自己掉入了一個戲法陷阱。在我進一步分析其源代碼并了解相關注解的工作原理後，發現我并不需要使用一個非标準的第三方庫将 Java 轉換為一個精巧而酷炫的語言。引入 Lombok 讓我的項目一時爽，但一時爽的代價是随着項目推進，技術債務開始累積。
接下來，我将用幾個大家耳熟能詳的場景，重演自己是如何掉入 Lombok 的戲法陷阱。
愛的開始，恨的起源
面對 Lombok 提供的諸多 “神走位”，你并不會介意在 IDE 上新增一個插件。對于 IntelliJ IDEA 玩家而言，隻需搜尋 “Lombok Plugin” 便可找到這款神器并安裝上它。愛上 Lombok 從安裝 Lombok 插件開始，恨也從此萌芽。
沒使用 Lombok 之前，我們的源代碼看起來是這一的：
public class MyObject{
private Long id;
private String name;
private int age;
private int gender;
public Long getId(){
return id;
}
public void setId(Long id){
this.id = id;
}
public String getName(){
return name;
}
public void setName(String name){
this.name = name;
}
public int getAge(){
return age;
}
public void setAge(int age){
this.age = age;
}
public int getGender(){
return gender;
}
public void setGender(int gender){
this.gender = gender;
}
@Override
public boolean equals(Object o){
if(this == o){
return true;
}
if(o == null || getClass() != o.getClass()){
return false;
}
MyObject obj = (MyObject) o;
return age = obj.age &&
gender = obj.gender &&
Objects.equals(id,obj.id) &&
Objects.queals(name,obj.name);
}
@Override
public int hashCode(){
return Objects.hash(id,name,age,gender);
}
@Override
public String toString(){
return "MyObject{"+
"id="+id+
"name="+name+
"age="+age+
"gender="+gander+
"}";
}
} 每個 JavaBean 都會充斥着如上述 getter，setter，equals，hashCode 和 toString 的模闆代碼，這看起來像一個偏胖的人（不得不承認 Java 是一個有缺陷的程式設計語言）。當我們安裝好 Lombok 插件後，IDE 便可以識别其酷炫的注解，使用 Lombok 的 @Getter 和 @Setter 注解後，代碼會像下面這樣看起來很苗條：
@Getter
@Setter
public class MyObject{
private Long id;
private String name;
private int age;
private int gender;
@Override
public boolean equals(Object o){
if(this == o){
return true;
}
if(o == null || getClass() != o.getClass()){
return false;
}
MyObject obj = (MyObject) o;
return age = obj.age &&
gender = obj.gender &&
Objects.equals(id,obj.id) &&
Objects.queals(name,obj.name);
}
@Override
public int hashCode(){
return Objects.hash(id,name,age,gender);
}
@Override
public String toString(){
return "MyObject{"+
"id="+id+
"name="+name+
"age="+age+
"gender="+gander+
"}";
}
} 現在的代碼是否看起來爽多了？但這還不是最爽的時候。既然其他方法都替換掉了，那把 toString 方法也一起拿掉吧。如你所願，可以使用 @ToString 注解去掉對于的方法：
@Getter
@Setter
@EqualsAndHashCode
public class MyObject{
private Long id;
private String name;
private int age;
private int gender;
@Override
public String toString(){
return "MyObject{"+
"id="+id+
"name="+name+
"age="+age+
"gender="+gander+
"}";
}
} 經過 Lombok 的戲法之後，相比一開始的代碼，看起來是不是很酷炫，很苗條，很性感？你以為到此為止了？遠不止于此。你會發現類名上一大坨注解看起來好别扭，Lombok 提供了一個組合注解 @Data，可以替換掉類名頭上那坨像翔一樣的東西：
@Data
public class MyObject{
private Long id;
private String name;
private int age;
private int gender;
} 現在，Lombok 是否讓你的對象成為了你心目中完美的樣子？魔鬼的 “身材”，酷炫精煉。Lombok 還有其他一些注解，如 @Slf4j，@NoArgsConstructor，@AllArgsConstructor 等等，介紹 Lombok 用法不是本文重點。
以上代碼行數的變化過程，也許是無數程式員愛上 Lombok 的主要原因吧，這就像一個肥胖的人逐漸變成一個身材苗條的人。同時也讓你看到了一個現象：你以為程式員很懶嗎？其他有些時候他們比你想象中的還要懶。在爽的同時，也為代碼種下了禍根。
扭曲的審美，愛的隐患
扭曲的審美，導緻了被審視的對象處于亞健康狀态。使用 Lombok 插件之後，我們的代碼也處于 “亞健康” 狀态。還是回歸一開始的那句話：所有的源代碼很多時候是用來閱讀的，隻有很少的時間是用來執行的。
本質上講，我們都追求減少程式中的樣闆代碼以使其代碼更精煉簡潔，進而提高代碼的可讀性和可維護性。但 Lombok 并沒有達到我們所追求的這一願景，它僅僅是利用 Java 語言在編譯時的空檔期，使用一種很取巧的方式，将我們所需要的方法注入（寫入）到目前的類中，這種過程很像在 hack 我們的代碼，隻是一種看起來酷炫的把戲。這種把戲并不智能和安全，反而會破壞 Java 代碼現有的特性以及代碼的可讀性。下面，結合我自己使用 Lombok 之後的感受，談談 Lombok 帶來的幾大痛點。
1. JDK 版本問題
當我想要将現有項目的 JDK 從 Java 8 更新到 Java 11 時，我發現 Lombok 不能正常工作了。于是我不得不将所有的 Lombok 注解從項目源代碼中清除，并使用 IDE 自帶的功能生成 getter/setter，equals，hashCode，toString 以及構造器等方法，你也可以使用 Delombok 工具完成這一過程。但這終究會消耗你很多的時間。
2. 脅迫使用
當你的源代碼中使用了 Lombok，恰好你的代碼又被其他的人所使用，那麼依賴你代碼的人，也必須安裝 Lombok 插件 (不管他們喜不喜歡)，同時還要花費時間去了解 Lombok 注解的使用情況，如果不那麼做，代碼将無法正常運作。使用過 Lombok 之後，我發現這是一種很流氓的行為。
3. 可讀性差
Lombok 隐藏了 JavaBean 封裝的細節，如果你使用 @AllArgsConstructor 注解，它将提供一個巨型構造器，讓外界有機會在初始化對象時修改類中所有的屬性。首先，這是極其不安全的，因為類中某系屬性我們是不希望被修改的；另外，如果某個類中有幾十個屬性存在，就會有一個包含幾十個參數的構造器被 Lombok 注入到類中，這是不理智的行為；其次，構造器參數的順序完全由 Lombok 所控制，我們并不能操控，隻有當你需要調試時才發現有一個奇怪的 “小強” 在等着你；最後，在運作代碼之前，所有 JavaBean 中的方法你隻能想象他們長什麼樣子，你并不能看見。
4. 代碼耦合度增加
當你使用 Lombok 來編寫某一個子產品的代碼後，其餘依賴此子產品的其他代碼都需要引入 Lombok 依賴，同時還需要在 IDE 中安裝 Lombok 的插件。雖然 Lombok 的依賴包并不大，但就因為其中一個地方使用了 Lombok，其餘所有的依賴方都要強制加入 Lombok 的 Jar 包，這是一種入侵式的耦合，如果再遇上 JDK 版本問題，這将是一場災難。
5. 得不償失
使用 Lombok，一時覺得很爽，但它卻污染了你的代碼，破壞了 Java 代碼的完整性，可讀性和安全性，同時還增加的團隊的技術債務，這是一種弊大于利，得不償失的操作。如果你确實想讓自己的代碼更加精煉，同時又兼顧可讀性和編碼效率，不妨使用主流的 Scala 或 Kotlin 這一基于 JVM 的語言。
總結
---
由 五分鐘學算法 原班人馬打造的公衆号：五分鐘學 Java，現已正式上線！
接下來我們将會在該公衆号上，為大家分享優質的 Java 領域幹貨，不限于 BAT 面試, 算法，資料庫，Spring Boot, 微服務,高并發, JVM , Docker 容器，ELK 相關知識，期待與您一同進步。