我想说，对于大多数用途来说，
@author是不需要的噪音。API的用户不应该-也许不应该-关心或想知道谁编写了哪些部分。
而且，正如您已经说过的那样，SVN已经以比代码更权威的方式拥有此信息。因此，如果我是团队中的一员，我将始终喜欢SVN的日志，而忽略
@author。我敢打赌，无论您采用哪种策略，代码都将与现实不同步。遵循“不要重复自己”的原则，为什么将这些信息放在两个地方？
但是，如果出于官僚或政策原因必须将此信息包含在代码中，那么您是否考虑过在
@author签入时自动更新代码中的标签？你可以 或许
与SVN钩子实现这一目标。例如，您可以列出所有更改给定文件顺序的开发人员；或更改最多的人；管他呢。或者，如果
@author您在外部发布的（源）代码中强制执行，则可以考虑将
@author自动添加作为发布版本的一部分（我怀疑您可以某种方式从SVN中获取此信息）。
至于添加多个类
@author标记（或其他注释），我会说您会积累很多无用的声音。（同样，您有SVN。）
以我的经验，识别历史更改（例如对一行代码或方法的更改），然后找出与之相关的更改集（以及哪个跟踪记录），会更加有用。然后，您具有更改的完整上下文：您拥有故障单，更改集，可以在同一故障单上找到其他更改集，或者大约在同一时间可以找到相关的故障单，并且可以看到所有更改形成了那个工作单元。您永远不会从代码中的注释或注释中获得此信息。
