Java注解的可维护性？

Question

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

对于能够维护带注释的代码的开发团队，您在现实世界中有什么经验？

Answer 1

我觉得它分成了注释的两种用法--提供类的“描述”的注释和提供类的“依赖”的注释。

我同意在类上使用注解的“描述”--这是属于类的东西，注解有助于创建一个简写版本-- JPA注解就属于这一类。

然而，我真的不喜欢“依赖”注解-如果你将依赖直接放在类上-即使它是在运行时通过注释而不是在类中的编译时确定的-这不是破坏依赖注入吗？(也许在精神上，而不是在规则上…)

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

Answer 2

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

关于注解的好处是，它们使您的类上的配置自我记录。现在，不必搜索一个巨大的XML文件来试图找出框架是如何使用您的类的，而是由您的类告诉您。

通常，像这样的变化的问题是，习惯它们只是需要时间。大多数人，包括开发人员，都拒绝改变。我记得我刚开始使用Spring的时候。在最初的几周里，我想知道为什么会有人忍受与之相关的头痛。然后，几周后，我想知道没有它我该如何生活。

Answer 3

我非常喜欢注解。我尽可能地从Hibernate/JPA、Seam、JAXB....anything中使用它们。没有什么比打开XML文件只是为了了解类是如何处理的更糟糕的了。

在我看来，注释允许类自己说话。另外，注释(希望)是IDE内容辅助的一部分，而使用XML配置，您通常只能靠自己。

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