在工作中,我们有许多需要共享一些共同代码的项目.有些代码是完全通用的,而有些代码只是由我们项目的一部分共享.我应该将公共代码拆分为两个单独的项目,还是为单个项目使用两个不同的常春藤配置？

选项1 – 两个单独的项目.

> Proj 1 – 通用发布为默认配置
> Proj 1 – Common-xml作为默认配置发布

潜在问题：要求我有两个单独的项目,两个单独的构建文件和两个单独的常春藤文件.

选项2 – 一个项目,针对不同工件的多个常春藤配置

>神器1 – 常见的核心版本
>神器2 – 作为core-xml发布的常见xml

潜在问题：我可能必须在同一个项目中维护单独的源目录.

在任何一种情况下,公共xml组件可能依赖于公共核心组件.

那么,SF,我该怎么做才能维护我的公共代码？这两种方法我错过了哪些问题,以及其他任何优点/缺点或替代解决方案是什么？

解决方法:

嗯,这真的取决于你喜欢如何管理你的源代码.但首先,我要问的问题是你是否真的需要拆分来源.公共项目的想法是封装代码,类,接口等,可以被其他项目用作通用工具包.这并不意味着这些项目必须使用Commons中的所有内容.他们可能只使用它的一小部分.这完全没问题,可能是因为分裂你的Commons实际上超过了优化.

想一想 – 如果您的下一个项目使用Commons库的不同子集会发生什么？你要再分手吗？