在过去的一年里，我在几乎所有的项目中都使用了Lombok，但不幸的是，我把它移除了。在一开始，这是一种非常干净的开发方式，但为新团队成员设置开发环境并不是非常容易和直接的。头痛时，我就把它去掉了。但这是一个很好的工作，需要一些更简单的设置。

当我向我的团队展示项目时，他们的热情很高，所以我认为你不应该害怕团队的反应。

就ROI而言，集成它很简单，并且不需要对其基本形式进行代码更改。(只需向类中添加一个注释) 最后，如果您改变了主意，您可以运行unlombok，或让IDE创建这些setter、getter和ctor(我认为一旦他们看到您的pojo变得多么清晰，就没有人会要求它们了)

在过去的一年里，我在几乎所有的项目中都使用了Lombok，但不幸的是，我把它移除了。在一开始，这是一种非常干净的开发方式，但为新团队成员设置开发环境并不是非常容易和直接的。头痛时，我就把它去掉了。但这是一个很好的工作，需要一些更简单的设置。

我读了一些关于龙目岛的意见，实际上我在一些项目中使用它。

嗯，第一次接触龙目岛时，我的印象很差。几周后，我开始喜欢上它了。但几个月后，我发现了很多使用它的小问题。所以，我对龙目岛的最终印象并不是那么积极。

我这么想的理由是:

IDE plugin dependency. The IDE support for Lombok is through plugins. Even working good in most part of the time, you are always a hostage from this plugins to be maintained in the future releases of the IDEs and even the language version (Java 10+ will accelerate the development of the language). For example, I tried to update from Intellij IDEA 2017.3 to 2018.1 and I couldn't do that because there was some problem on the actual lombok plugin version and I needed to wait the plugin be updated... This also is a problem if you would like to use a more alternative IDE that don't have any Lombok plugin support. 'Find usages' problem.. Using Lombok you don't see the generated getter, setter, constructor, builder methods and etc. So, if you are planning to find out where these methods are being used in your project by your IDE, you can't do this only looking for the class that owns this hidden methods. So easy that the developers don't care to break the encapsulation. I know that it's not really a problem from Lombok. But I saw a bigger tendency from the developers to not control anymore what methods needs to be visible or not. So, many times they are just copying and pasting @Getter @Setter @Builder @AllArgsConstructor @NoArgsConstructor annotations block without thinking what methods the class really need to be exposed. Builder Obssession ©. I invented this name (get off, Martin Fowler). Jokes apart, a Builder is so easy to create that even when a class have only two parameters the developers prefer to use @Builder instead of constructor or a static constructor method. Sometimes they even try to create a Builder inside the lombok Builder, creating weird situations like MyClass.builder().name("Name").build().create(). Barriers when refactoring. If you are using, for example, a @AllArgsConstructor and need to add one more parameter on the constructor, the IDE can't help you to add this extra parameter in all places (mostly, tests) that are instantiating the class. Mixing Lombok with concrete methods. You can't use Lombok in all scenarios to create a getter/setter/etc. So, you will see these two approaches mixed in your code. You get used to this after some time, but feels like a hack on the language.

就像另一个回答说的，如果您对Java的冗长感到愤怒，并使用Lombok来处理它，那么可以尝试Kotlin。

我对Lombok的看法是，它只是为编写样板Java代码提供了快捷方式。 当涉及到使用快捷方式来编写Java代码时，我会依赖IDE提供的这些特性——就像在Eclipse中一样，我们可以转到Source > Generate Getters and Setters菜单来生成getter和setter。 我不会依赖Lombok这样的库:

It pollutes your code with an indirection layer of alternative syntax (read @Getter, @Setter, etc. annotations). Rather than learning an alternative syntax for Java, I would switch to any other language that natively provides Lombok like syntax. Lombok requires the use of a Lombok supported IDE to work with your code. This dependency introduces a considerable risk for any non-trivial project. Does the open source Lombok project have enough resources to keep providing support for different versions of a wide range of Java IDE's available? Does the open source Lombok project have enough resources to keep providing support for newer versions of Java that will be coming in future? I also feel nervous that Lombok may introduce compatibility issues with widely used frameworks/libraries (like Spring, Hibernate, Jackson, JUnit, Mockito) that work with your byte code at runtime.

总而言之，我不喜欢用龙目岛来“调味”我的爪哇。

我个人(因此也是主观上)发现，与IDE/自己实现的复杂方法(如hashcode & equals)相比，使用Lombok使我的代码更能表达我想要实现的目标。

当使用

@EqualsAndHashCode(callSuper = false, of = { "field1", "field2", "field3" })

与任何IDE/自己的实现相比，保持Equals & HashCode一致并跟踪哪些字段被求值要容易得多。当您仍然定期添加/删除字段时，这一点尤其正确。

@ToString注释及其参数也是如此，它们清楚地传达了所期望的行为，包括包含/排除字段、getter的使用或字段访问，以及是否调用super.toString()。

同样，通过使用@Getter或@Setter(AccessLevel.NONE)注释整个类(并可选择覆盖任何发散的方法)，可以立即清楚哪些方法将可用于字段。

好处无穷无尽。

在我看来，这不是关于减少代码，而是关于清楚地传达您想要实现的目标，而不是必须从Javadoc或实现中找到答案。减少的代码只是使它更容易发现任何发散方法实现。