是的,这是一个不好的做法,正是你所说的原因 - 你无法从源头重建.
是的,这是一个不好的做法,正是你所说的原因 - 你无法从源头重建.
这是过度模块化的症状之一.
我曾在一家公司工作过一次,在SVN存储库中有大约20个开发人员和60多个不同的活动项目.每个项目都有自己的构建脚本,并生成一个JAR文件,该文件是至少六个左右的其他项目的依赖项.管理所有这些依赖项是如此复杂,以至于我们浪费了大量时间尝试(不成功,我可能会添加)来设置maven项目以自动获取所有这些小型微项目的所有正确的库(以及正确的版本).
有趣的是(对我而言)它实际上只是一个项目,它甚至不是我们分发给外界的东西.它是一个托管应用程序,具有Web前端,在单个服务器群集上运行.
啧.
该体系结构的另一个副作用是,在几个不同的项目中,相同类型的功能一次又一次地重复(并不总是使用相同的算法或结果).我认为部分原因是因为人们不想为整个子项目引入新的依赖项,只是为了访问它的一些类.但我认为另一个原因是人们只是不知道代码存在于哪里,而不是找到他们想要重用的代码的麻烦,他们只是在他们自己的项目中重写它.
当然,模块化通常是一件好事.
但就像所有好事一样,它可以被视为荒谬的极端.
我的建议是找到那些循环依赖项并将项目合并到更大的块中,因为当前的项目细分可能代表了错误的模块化.最好将您的大项目划分为几个分离良好的模块,而不是拥有数以万计的伪模块在逻辑耦合类之间创建人为边界.
除了构建问题,循环引用总是表明设计缺陷.在.NET中,循环关系使两个程序集有效地成为一个程序集.如果没有一个人可以独立生活,那么单独构建它们只是一个练习 - 它并没有改变它们共同代表整体装配的事实.
我已经注意到了很多实用程序集.必须是反模式.