如何将大型Java项目划分为更小的组件

sbl*_*ndy 8 java refactoring

我们试图将一个大的代码库分成逻辑模块.我想要一些工具建议以及你可能遇到的任何经验.

该应用程序由服务器WAR和分布在JAR中的多个富客户端组成.麻烦的是,它只是一个庞大的毛茸茸的代码库,一个> 2k文件战争的源代码树.每个JAR都有一个带有main方法的专用类,但依赖关系的纠结很快就会陷入困境.这并不是那么糟糕,一贯遵循良好实践,并且有一些具有特定任务的组件.它只是需要一些改进来帮助我们的团队随着它的发展而扩展.

每个模块都在一个由父POM构建的maven项目中.这个过程已经开始将每个JAR/WAR移动到它自己的项目中,但很明显,这只会刮开表面:每个应用程序JAR中的一些类和一个庞大的"遗留"项目.此外,已经有一些单元和集成测试.

无论如何,我对工具,技术和一般建议感兴趣,它们将过大且纠缠不清的代码库分解为更易于管理的东西.自由/开源是首选.

Jen*_*der 8

看看结构101.它可视化依赖关系,并显示依赖关系,以便在通往更清洁的结构时中断.


Dan*_*ler 6

我们最近完成了一个类似的任务,即一个由> 1k源文件组成的项目,其中包含两个必须拆分的主类.我们最终得到了四个独立的项目,一个用于基础实用程序类,一个用于客户端数据库,一个用于服务器(项目是rmi-server-client应用程序),另一个用于客户端gui.我们的项目必须分开,因为其他应用程序仅将客户端用作命令行,如果您偶然使用任何gui类,则会遇到无头的异常,这些异常仅在无头部署服务器上启动时发生.

从我们的经验中要记住的一些事项:

  • 使用整个sprint来分离项目(不要让其他任务干扰拆分,因为你需要整个sprint的时间)
  • 使用版本控制
  • 移动其他任何功能之前编写单元测试
  • 使用持续集成系统(无论是自家种植还是开箱即用)
  • 最大限度地减少当前变更集中的文件数量(当您必须撤消某些更改时,您将节省大量工作)
  • 移动类之前一直使用依赖性分析工具(我们已经使用DependencyFinder获得了很好的体验)
  • 花点时间将包重组为合理的每个项目包集
  • 不要害怕更改接口,但要在工作区中包含所有依赖项目,以便获得所有编译错误


Ita*_*man 2

两个建议:您需要的第一件事是测试套件。第二个建议是循序渐进。

如果您已经拥有强大的测试套件,那么您就处于有利位置。否则,我会进行一些良好的高级测试(又名:系统测试)。

高水平测试的主要优点是相对少量的测试可以获得很大的覆盖范围。它们不会帮助您精确定位错误,但您实际上并不需要这样做:如果您小步前进并确保在每次更改后运行测试,您将能够快速检测到(意外引入)错误:错误的根源在于自上次运行测试以来代码的一小部分发生了更改。