java - 跟踪实用程序类

Question

我最近对我的项目代码库中出现的一个问题感到越来越沮丧。

我正在开发一个具有 >1M 行代码的大型 Java 项目。接口(interface)和类结构设计的很好，编写代码的工程师也很熟练。问题在于，为了使代码更简洁，人们在需要重用某些功能时编写实用程序类，结果随着时间的推移和项目的发展，越来越多的实用程序方法出现了。但是，当下一位工程师遇到对相同功能的需求时，他无法知道有人已经在代码中的某处实现了实用程序类(或方法)并在不同的类中实现了该功能的另一个副本。结果是大量的代码重复和太多具有重叠功能的实用程序类。

我们作为一个团队可以实现任何工具或任何设计原则，以防止实用程序类的重复和低可见性？

示例:工程师 A 有 3 个地方需要将 XML 转换为 String，因此他编写了一个名为 XMLUtil 的实用程序类并放置了一个静态 toString(Document) 方法。工程师 B 有几个地方可以将文档序列化为各种格式，包括字符串，因此他编写了一个名为 SerializationUtil 的实用程序类，并有一个名为 serialize(Document) 的静态方法，该方法返回一个字符串。

请注意，这不仅仅是代码重复，因为上述示例的 2 个实现很可能是不同的(比如一个使用转换器 API，另一个使用 Xerces2-J)所以这可以看作是“最佳实践”的问题...

更新:我想我最好描述一下我们当前的开发环境。我们使用 Hudson 进行 CI，使用 Clover 进行代码覆盖，使用 Checkstyle 进行静态代码分析。我们使用敏捷开发，包括日常谈话和(可能不够)代码审查。我们在 .util 中定义了所有实用程序类，由于它的大小，现在在根 (.util) 类下有 13 个子包和大约 60 个类。我们还使用 3rd 方库，例如大多数 apache commons jar 和一些构成 Guava 的 jar。

我很肯定，如果我们让某人负责重构整个包的任务，我们可以将实用程序的数量减少一半，我想知道是否有任何工具可以降低该操作的成本，是否有任何可以尽可能延迟问题再次发生的方法。

Answer 1

这个问题的一个很好的解决方案是开始添加更多的面向对象。使用您的示例:

Example: engineer A has 3 places he needs to transform XML to String so he writes a utility class called XMLUtil and places a static toString(Document) method in it

解决方案是停止使用原始类型或 JVM 提供的类型(String、Integer、java.util.Date、java.w3c.Document)并将它们包装在您自己的项目特定类中。然后您的 XmlDocument 类可以提供方便的 toString 方法和其他实用方法。您自己的 ProjectFooDate 可以包含解析和格式化方法，否则这些方法最终会出现在各种 DateUtils 类等中。

这样，当您尝试对对象执行操作时，IDE 将提示您使用实用程序方法。