paluch.biz - Lombok的資料類是有害的！為什麼我不再使用Lombok？

實際上，沒有免費午餐這樣的東西。

原因如下：

意外複雜性
透過引入程式碼生成（這是Lombok和Kotlin data classes所做的），我們獲得了很多功能，但真正的問題應該是：它是否是我想要的功能？或者我們是否希望明確控制功能？

在某些情況下，我們使用資料類是為了方便，我們發現我們隱含地使用了許多我們免費獲得的功能，例如相等的檢查。刪除Lombok生成的程式碼後，許多測試開始失敗，因為這些功能不再可用。缺少的功能引發了一個問題：是否需要此功能？（影響測試）

相反，採用明確的方法（不使用Lombok註解），可能我們的測試看起來會有所不同，或者我們會更清楚地瞭解具體功能。

在沒有生成實用程式的情況下顯式明確控制程式碼會強制您考慮功能是否真正需要。

什麼是樣板Boilerplate？
樣板Boilerplate程式碼是我們重複需要編寫，以實現某個功能而不是告訴程式碼我們希望此功能開箱即用的程式碼。典型的例子是屬性訪問器（Getters，Setters）和相等性檢查（equals/ hashCode）。有時也是建設者builder模式。與我們之前的觀點相反，將Lombok註釋自己的元件並不是樣板Boilerplate。它不精確，方便，不負責任。

圍繞編譯器工作
Lombok針對特定的編譯器，現實世界是：Java釋出節奏速度從Java 9開始提高，Lombok專案不是由公司驅動，而是由開源貢獻者團隊推動，時間有限。

Lombok阻止我們升級到更新的Java版本的元件：編譯器內部元件發生了變化，Lombok還沒有機會趕上。隨著Lombok的使用遍佈整個程式碼庫，唯一的選擇就是不升級。

但是：從長遠來看，不升級不是一種選擇。最終，Lombok迎頭趕上，開闢了再次升級到新版本的道路。

外掛
需要啟用Eclipse或IntelliJ外掛，如果沒有正確的IDE設定，任何想要處理Lombok程式碼的人都會收到錯誤/警告提出問題：這甚至是如何工作的？

認知負荷
每個非顯而易見的行為都會導致需要理解的複雜性。此外，每個非預設行為都會導致相同的路徑。人們第一次使用這樣的程式碼庫需要了解程式碼庫。雖然這不是特定於Lombok，但是為​​程式碼提供附加功能的所有輔助實用程式（程式碼生成器，AOP，JVM代理，一般的位元組碼操作）都有可能被描述為魔術。為什麼魔術？因為在第一時間發生的事情並不明顯。一旦有人向你解釋這個伎倆，它就會變得明顯。

別人改變你的（編譯）程式碼
使用程式碼生成功能，我們就只能依靠其他人來做正確的工作。

意外複雜性2：構建​​​​​​​
我們釋出了一個帶有公共API表面的庫，它帶有一個源jar和Javadoc。預設情況下，Lombok .class僅適用於您的檔案。這會導致源jar不包含生成的方法，Javadoc也不會列出生成的成員。為了獲得正確的源jar和Javadoc，我們需要在構建中新增外掛，首先對程式碼進行delombok（去Lombok），並允許源jar / Javadoc在delomboked原始碼之上執行。

複雜性的增加通常伴隨著更長的構建時間，我們可能會問自己，這是否值得我們得到。

雙重痛苦​​​​​​​
不使用程式碼生成功能使程式碼顯式化。顯式程式碼總是揭示它的作用。顯式程式碼需要設計。

打個比喻：你有一所房子，你把它租給一些房客，因為租房子裡的利潤是有利可圖的。最終你弄明白你的房客很亂，你開始驅趕你的房客。一旦你的房客離開，你就會意識到這個爛攤子的範圍，你開始清理房間。