不得不承認，Lombok 是一個很不錯的 Java 庫，它可以讓你在少寫程式碼的同時耍耍酷，簡單的幾個註解，就可以幹掉一大片模板程式碼。但是，所有的原始碼很多時候是用來閱讀的，只有很少的時間是用來執行的 (你可以細品這句話)。

 

接下來，我將用幾個大家耳熟能詳的場景，重演我們是如何掉入 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@Setterpublic 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@EqualsAndHashCodepublic 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，可以替換掉類名頭上那坨像翔一樣的東西：

@Datapublic 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 的語言。

 

# 總 結

 

Lombok 本身是一個優秀的 Java 程式碼庫，它採用了一種取巧的語法糖，簡化了 Java 的編碼，為 Java 程式碼的精簡提供了一種方式，但在使用此程式碼庫時，需要了解到 Lombok 並非一個標準的 Java 庫。

 

使用 Lombok，會增加團隊的技術債務，降低程式碼的可讀性，增大程式碼的耦合度和調式難度。

 

雖然在一定程度上 Lombok 減少了樣板程式碼的書寫，但也帶來了一些未知的風險。

 

如果你正在參與一個團隊專案（或大型專案）, 考慮到後續的升級與擴充套件，是否使用 Lombok，請與你的團隊多溝通和三思