我承認，要放棄使用Lombok了！
我承認，Lombok是一個很不錯的 Java 庫，它可以讓你在少寫代碼的同時耍耍酷，簡單的幾個注解，就可以干掉一大片模板代碼。
圖片來自 Pexels
但是，所有的源代碼很多時候是用來閱讀的，只有很少的時間是用來執行的(你可以細品這句話)。
一年以前，我和大多數人都認為 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 帶來的幾大痛點。
JDK 版本問題
當我想要將現有項目的 JDK 從 Java 8 升級到 Java 11 時，我發現 Lombok 不能正常工作了。
于是我不得不將所有的 Lombok 注解從項目源代碼中清除，并使用 IDE 自帶的功能生成 getter/setter，equals，hashCode，toString 以及構造器等方法。
你也可以使用 Delombok 工具完成這一過程，但這終究會消耗你很多的時間。
脅迫使用
當你的源代碼中使用了 Lombok，恰好你的代碼又被其他的人所使用，那么依賴你代碼的人，也必須安裝 Lombok 插件(不管他們喜不喜歡)，同時還要花費時間去了解 Lombok 注解的使用情況，如果不那么做，代碼將無法正常運行。使用過 Lombok 之后，我發現這是一種很流氓的行為。
可讀性差
Lombok 隱藏了 JavaBean 封裝的細節，如果你使用 @AllArgsConstructor 注解，它將提供一個巨型構造器，讓外界有機會在初始化對象時修改類中所有的屬性。
首先，這是極其不安全的，因為類中某系屬性我們是不希望被修改的;另外，如果某個類中有幾十個屬性存在，就會有一個包含幾十個參數的構造器被 Lombo k注入到類中，這是不理智的行為。
其次，構造器參數的順序完全由 Lombok 所控制，我們并不能操控，只有當你需要調試時才發現有一個奇怪的“小強”在等著你。
最后，在運行代碼之前，所有 JavaBean 中的方法你只能想象他們長什么樣子，你并不能看見。
代碼耦合度增加
當你使用 Lombok 來編寫某一個模塊的代碼后，其余依賴此模塊的其他代碼都需要引入 Lombok 依賴，同時還需要在 IDE 中安裝 Lombok 的插件。
雖然 Lombok 的依賴包并不大，但就因為其中一個地方使用了 Lombok，其余所有的依賴方都要強制加入 Lombok 的 Jar 包，這是一種入侵式的耦合，如果再遇上 JDK 版本問題，這將是一場災難。
得不償失
使用 Lombok，一時覺得很爽，但它卻污染了你的代碼，破壞了 Java 代碼的完整性，可讀性和安全性，同時還增加的團隊的技術債務，這是一種弊大于利，得不償失的操作。
如果你確實想讓自己的代碼更加精煉，同時又兼顧可讀性和編碼效率，不妨使用主流的 Scala 或 Kotlin 這一基于 JVM 的語言。
總結
Lombok 本身是一個優秀的 Java 代碼庫，它采用了一種取巧的語法糖，簡化了 Java 的編碼，為 Java 代碼的精簡提供了一種方式，但在使用此代碼庫時，需要了解到 Lombok 并非一個標準的 Java 庫。
使用 Lombok，會增加團隊的技術債務，降低代碼的可讀性，增大代碼的耦合度和調式難度。
雖然在一定程度上 Lombok 減少了樣板代碼的書寫，但也帶來了一些未知的風險。
如果你正在參與一個團隊項目(或大型項目)，考慮到后續的升級與擴展，是否使用 Lombok，請與你的團隊多溝通和三思。
作者：ramostear
編輯：陶家龍
出處：https://www.toutiao.com/a6820517160964588044/
