Hi！ 我是小小，今天是本週的第二篇，本篇將會詳細講解Lombook的各種壞處，以及不建議使用Lombook的各種原因。
前言
我承認，Lombok是一個很不錯的Java庫，它可以讓你在少寫程式碼的同時耍耍酷，簡單的幾個註解，就可以幹掉一大片模板程式碼。但是，所有的原始碼很多時候是用來閱讀的，只有很少的時間是用來執行的（你可以細品這句話）。
一年以前，我和大多數人都認為Lombok的出現會讓Java的編碼體驗會更好，並極力的在我的團隊中推薦使用Lombok。一年以後，我開始對此產生顧慮，尤其是在我準備為開源的部落格系統Una-Boot升級Java版本時，我才意識到Lombok自己掉入了一個戲法陷阱。在我進一步分析其原始碼並理解相關注解的工作原理後，發現我並不需要使用一個非標準的第三方庫將Java轉換為一個精巧而酷炫的語言。引入Lombok讓我的專案一時爽，但一時爽的代價是隨著專案推進，技術債務開始累積。
接下來，我將用幾個大家耳熟能詳的場景，重演自己是如何掉入Lombok的戲法陷阱。
愛的開始，恨的根源
面對Lombok提供的諸多“神走位”，你並不會介意在IDE上新增一個外掛。對於IntelliJ IDEA玩家而言，只需搜尋“Lombok Plugin”便可找到這款神器並安裝上它。愛上Lombok從安裝Lombok外掛開始，恨也從此萌芽。
沒使用Lombok之前，我們的原始碼看起來是這一的：
每個JavaBean都會充斥著如上述getter，setter，equals，hashCode和toString的模板程式碼，這看起來像一個偏胖的人（不得不承認Java是一個有缺陷的程式語言）。當我們安裝好Lombok外掛後，IDE便可以識別其酷炫的註解，使用Lombok的@Getter和@Setter註解後，程式碼會像下面這樣看起來很苗條：
你以為Lombok就這點能耐？它還能讓你程式碼的“身材”更苗條，更魔鬼。上面的程式碼仍然還有改進的空間，我們可以用@EqualsAndHashCode註解替換到equals和hashCode方法：
現在的程式碼是否看起來爽多了？但這還不是最爽的時候。既然其他方法都替換掉了，那把toString方法也一起拿掉吧。如你所願，可以使用@ToString註解去掉對於的方法：
經過Lombok的戲法之後，相比一開始的程式碼，看起來是不是很酷炫，很苗條，很性感？你以為到此為止了？遠不止於此。你會發現類名上一大坨註解看起來好彆扭，Lombok提供了一個組合註解@Data，可以替換掉類名頭上那坨像翔一樣的東西：
現在，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註解，它將提供一個巨型構造器，讓外界有機會在初始化物件時修改類中所有的屬性。首先，這是極其不安全的，因為類中某系屬性我們是不希望被修改的；另外，如果某個類中有幾十個屬性存在，就會有一個包含幾十個引數的構造器被Lombok注入到類中，這是不理智的行為；其次，構造器引數的順序完全由Lombok所控制，我們並不能操控，只有當你需要除錯時才發現有一個奇怪的“小強”在等著你；最後，在執行程式碼之前，所有JavaBean中的方法你只能想象他們長什麼樣子，你並不能看見。
程式碼耦合度增加當你使用Lombok來編寫某一個模組的程式碼後，其餘依賴此模組的其他程式碼都需要引入Lombok依賴，同時還需要在IDE中安裝Lombok的外掛。雖然Lombok的依賴包並不大，但就因為其中一個地方使用了Lombok，其餘所有的依賴方都要強制加入Lombok的Jar包，這是一種入侵式的耦合，如果再遇上JDK版本問題，這將是一場災難。
得不償失使用Lombok，一時覺得很爽，但它卻汙染了你的程式碼，破壞了Java程式碼的完整性，可讀性和安全性，同時還增加的團隊的技術債務，這是一種弊大於利，得不償失的操作。如果你確實想讓自己的程式碼更加精煉，同時又兼顧可讀性和編碼效率，不妨使用主流的Scala或Kotlin這一基於JVM的語言。
我是小小，雙魚座的程式猿，我們下期再見~bye
END
「 往期文章 」