传感器" width="403px" height="256px" style="outline: none;">
有害气体传感器
这篇博客文章解释了删除我参与的项目之一Lombok项目的动机。 它反映了我的个人观点，并不妨碍特定的技术。
大约三年前，我认识了Project Lombok ，这是添加剂Java代码的库。 我从一开始就喜欢它，因为它贡献了许多有用的功能。 因此，我经常处理实体(数据类)和值对象@Data或Kotlins data class很方便也就不足为奇了。 从字面上看，你会得到更多的回报。我在这里提到Kotlin是因为它共享了我们从Lombok获得的属性。
这种(语言生成)功能通常用于代码库。 由于使用免费功能，代码开发得越多，使用此类功能的组件就越多*方便并且已经习惯了。 使用单个注释或单个关键字，我们选择了可以为我们提供属性访问器的东西，包括equals / hashCode ， toString ，构造函数等。
* ：事实上，没有免费的午餐和其他东西。
现在，有些人可以说只使用你需要的东西，而你是完全正确的。 只需要属性访问器，请使用@Getters和@Setters 。 若希望得到equals / hashCode ，添加适当的注释。 真正。 在很多情况下，我们认为我们需要更多的功能，那么为什么要使用单个功能呢？@Data当注释得到我们想要的(和更多)时，为什么要混淆多个注释的代码？ 这不是样板吗？ 因此，减少注释的数量似乎是件好事。
好：不。
原因如下：
偶然的复杂性
通过引入代码生成(即Lombok和Kotlin data classes所做的事情)，我们获得了很多功能，但是真正的问题应该是：我是否希望使用该功能？ 还是想显式控制功能？在某些情况下，我们使用数据类是为了方便。 随着Lombok我们发现我们发现我们隐式使用了许多免费功能* ，比如相等检查。 随着生成代码的删除，由于这些功能不再可用，许多测试开始失败。 缺失的功能提出了一个问题:需要这个功能吗？
只要选择数据类，就可以很容易地忽略这个问题。 相反，我们将花更多的时间讨论这个话题，以一种明确的方法。 也许我们的测试看起来不同，或者我们对特定功能有更清晰的了解。
显式控制代码迫使您考虑该功能是否真的需要，而无需生成实用程序。
样板是什么？
样板代码是我们反复需要编写的代码来披露某些功能，而不是告诉代码我们希望这个功能可以打开和使用。 属性访问器是属性访问器(Getters，Setters)和等检查( equals / hashCode )。 有时也是构造函数。与我们以前的想法相反，它将是Lombok将注释分解为自己的组件不是样板。 不准确、方便、不负责任。
在编译器周围工作
这是Lombok具体方面。 Java编译器从使用编译器Lombok要做的事。 Lombok维修人员，维修人员做了出色的工作Lombok做什么。 以编译器为特定编译器的几种解决方案为代价。 javac在某种程度上，所需的不同Eclipse的ecj需要完成的工作。
静态布局，JDK和Eclipse IDE永不改变，一切都很好。 但现实世界是不同的。 Eclipse从Java 9开始，Java发布节奏加快。Lombok该项目不是由公司驱动的，而是由时间有限的开源贡献者团队驱动的。
过去，Java升级导致Lombok阻止我们升级到更新Java版本组件：编译器内部发生了变化，Lombok没有机会赶上。 随着Lombok用法遍布整个代码库，唯一的选择就是不升级。
但从长远来看，不升级不是一种选择。Lombok赶上路，为新版本的升级开辟了道路。
插入一切！
Lombok它需要告诉你的一个方面IDE关于生成类成员的信息。 虽然你的代码中没有例子Setter，但是有编译代码，所以你IDE要知道这一点，以免出错。 对于IntelliJ和Netbeans这不是什么大问题，因为你可以使用注释和使用可选的IntelliJ插件。 对于Eclipse，你需要一个可修改的Eclipse行为代理。 假如没有正确的IDE如果设置，任何想处理代码的人都会收到错误/警告，并提出以下问题：我该怎么办？
认知负荷
从某种意义上说，每一种不明显的行为都会导致复杂性。 同样，每一种非默认行为都会导致同样的路径。 初次使用这种代码库的人们需要了解如何掌握该代码库。 尽管这不是Lombok所有辅助实用程序(代码生成器，AOP，JVM一般来说，字节码操作具有被描述为魔术的潜力。 为什么是魔法？ 因为发生在第一刻并不明显。 一旦有人向你解释了这个技巧，它就会变得非常明显。
其他人更改你的(已编译)代码
使用代码生成功能，我们可以依靠他人来完成正确的工作。 因此，他们的工具为我们提供了有用的功能。 我们不再需要这样做了equals / hashCode正确的实现和麻烦，添加属性变得毫不费力，因为这一代人为我们工作。 手动扩展equals / hashCode并非易事。 有些工具可以为我们做到这一点，但正如你可能预料到的那样，我们将在不大幅改善我们状况的情况下做到这一点tool2 tool1 tool2 。有时，工具会改变其生成代码的方式或位置以及停止位置。 找出这些变化并不是一件有趣的事情，但如果我们购买了他们的编程模型，我们别无选择。 唯一的选择为代价，唯一的选择就是退后。
偶然复杂性2:构建
这可能只与我们的项目有关。 我们附带公众API表面的图书馆有源jar和Javadoc。 默认情况下，Lombok仅适用于你.class文件。 这将导致源jar不包括生成方法和Javadoc也不会列出生成的成员。 随着构建复杂性的提高，从消除样板代码开始。 获得正确的来源jar和Javadoc，我们需要将插件添加到插件中，插件首先需要代码delombok，并允许源jar / Javadoc在该delomboked运行在源以上。
根据您的设置，使用delomboked源只用于源jar和Javadoc。 这意味着你在文档目的中使用一个版本的代码。 该代码不同于您用于编译的代码。 Lombok本质上导致相同的输出代码。 使这一方面变得明显会使我们感到难受。
复杂性的增加通常需要更长的施工时间，我们可能会问自己是否值得。
Lombok社区正在分化
即使前面的部分听起来像我们在处理严重的问题，其中许多可能是针对我们的项目。 Lombok承诺减少样板代码。 它做得很好。 在面向数据的环境中工作，我们需要测试各种对象，甚至在生产代码中使用合适的数据对象/值对象。hashCode并提供良好的实现hashCode 。 因为不正确hashCode有两个实现CVE。 忘记在equals / hashCode添加字段是错误的另一个常见来源。在使用代码生成时，我们消除了这些错误来源。 此外，不存在的代码不会影响我们的测试覆盖率统计信息。 这并不意味着它不需要测试。
查看Lombok我们可以看到删除提交的统计信息：
删除：300行新增：1200线
这很好地说明了使用Lombok带来的好处。 一旦在一个地方使用了Lombok，我们通常会在其他地方继续使用它-因为它已经在类路径中了。 查看已删除的300行，我们应该改为将其删除为150行，因为它通常是一个import语句和一个注释，使我们在便捷代码和手动维护代码之间的比例大致为1：8。
我们不需要支付任何代码行，但是拥有更多代码会带来更大的维护面。
看看我的推文，有很多反对意见。 这些React就是为什么在您应该/不应该使用Project Lombok或Kotlin数据类时没有唯一答案的原因，因为它始终取决于您的团队，上下文和所编写的代码类型。
双重痛苦
不使用代码生成功能会使代码明确。 显式代码始终可以揭示其作用。 显式代码需要设计。 由于立即得到的结果和最初的简单性，进入代码生成功能很诱人。 一旦使用了这些功能，我们将经历不同的情况，并了解尚不立即显而易见的方面。 由于相关的成本，很难消除一个非常有益的功能。 还记得1：8的LoC比率吗？
仅仅因为我们想摆脱代码生成，并不意味着我们可以免费删除该工具收到的功能* 。 而是意味着我们需要自行提供此功能。
我这样说：您有一所房子，将其出租给某些租户，因为租用房屋可以赚钱。 最终，您发现租户很乱，并且开始摆脱租户。 租户出门后，您便会意识到混乱的程度，并开始清理房屋，以免房屋松动。
最终结果是相同的：您为该学习付出了很多努力(可能还有金钱)。
如果您的租户行为正常，则没有理由改变现状。
翻译自: https://www.javacodegeeks.com/2019/07/data-classes-considered-harmful.html
有害气体传感器
