java - Java注解的可维护性？

Question

我的项目正在慢慢实现 Java 注释。一半的开发人员——包括我自己——发现使用注释做任何复杂的事情似乎增加了我们的整体维护负担。团队的另一半认为他们是蜜蜂的膝盖。

开发人员团队能够维护带注释的代码，您的实际经验是什么？

Answer 1

我个人的经验是，平均而言，对于大多数开发人员来说，处理注释要比处理标准的 Java XML 配置地狱容易得多。对于 JPA 和 Spring 测试之类的东西，它们绝对是救命稻草。

注释的好处是它们使您的类的配置自记录。现在，不必搜索巨大的 XML 文件来尝试找出框架如何使用您的类，您的类会告诉您。

通常，此类更改的问题在于习惯它们只需要时间。大多数人，包括开发人员，都抵制变革。我记得当我开始使用 Spring 时。在最初的几周里，我想知道为什么有人会忍受与之相关的头痛。然后，几周后，我想知道没有它我是如何生活的。

Answer 2

我觉得它分为注释的两种用途 - 提供类的“描述”的注释与提供类的“依赖关系”的注释。

我对在类上使用注释的“描述”很好——这是属于类的东西，注释有助于制作它的简写版本——JPA 注释属于这一类。

但是，我真的不喜欢“依赖”注释——如果你将依赖直接放在类上——即使它是在运行时从注释而不是在类中的编译时确定的——这不是破坏依赖注射？（也许在精神上而不是在规则上......）

这可能是个人喜好，但我喜欢包含我的应用程序的所有依赖信息的一个大 XML 文件 - 我将其视为“应用程序配置”而不是“类配置”。我宁愿搜索一个已知位置，也不愿搜索应用程序中的所有类。

Answer 3

我非常喜欢注释。我从 Hibernate/JPA、Seam、JAXB 中使用它们......我可以的任何东西。IMO 没有什么比打开一个 XML 文件来了解如何处理一个类更糟糕的了。

在我看来，注释可以让一个班级自己说话。注释也（希望）是您的 IDE 内容辅助的一部分，而使用 XML 配置通常是您自己的。

但是，它可能归结为任何特定库（大多数都提供两者）如何实际使用 XML 配置和注释，以及使用哪种注释。我可以想象定义特定于构建的东西（例如文件/url路径）的注释实际上可能更容易作为XML配置。

Answer 4

它高度依赖于 IDE 支持。我觉得注释应该通过 IDE 中的检查与代码保持同步，但是对此的支持有些缺乏。

例如，如果您在没有@Override 的情况下覆盖函数，旧版本的IDEA 会发出警告，但如果您更改方法签名（或超类签名，就此而言）并破坏关系，则不会删除@Override 标记。

在没有支持的情况下，我发现它们是一种将元数据添加到代码中的繁琐方式。

Answer 5

我个人认为您提到的特定用例（自动生成 Web 表单）是一个很好的注释用例。我认为，任何可以编写简化代码并让框架根据一些建议（又名注释）进行繁重（通常重复）提升的“框架”场景都是注释的理想用例。

我很好奇为什么在这种情况下你不喜欢注释，你认为什么是“维护负担”？（而且，我不是想侮辱你的立场，只是理解它）。