큰 Java 프로젝트가 있으며 빌드주기에 maven을 사용합니다. 이 프로젝트는 광범위하게 사용됩니다-다른 프로젝트, 다양한 응용 프로그램, 그중 일부는 다른 응용 프로그램에 포함되어 있습니다. 솔직히 말하면 약간 혼란 (특정에 대해 다른 시간에 다양한 비트가 추가됨) 목적), 나는 그것을 조금 정리하고 싶습니다. 또한 완전히 테스트되지 않았으며 (적절한 단위 및 통합 테스트없이 많은 비트가 추가되었습니다) 실행하는 데 오랜 시간이 걸리거나 실제로 통과하지 못하는 테스트가 있습니다 ... (uh-oh)-그래서 테스트는 maven 빌드주기 (다시, 어-오)에서 꺼집니다.
이 큰 프로젝트를 더 작은 특정 프로젝트로 분리하여 '최종'하위 프로젝트 (또는 여러 하위 프로젝트)가 필요한 다양한 하위 프로젝트를 선택할 수 있도록 생각하고 있습니다.
내 생각은 다음과 같습니다.
- 큰 프로젝트를 여러 하위 프로젝트로 분리하면 각 프로젝트의 책임이 무엇인지 명확하게 알 수 있습니다.
- 하위 프로젝트로 분리하여 각 하위 프로젝트의 테스트를 개별적으로 정리하고 Maven 빌드주기에서 해당 하위 프로젝트의 테스트를 켤 수 있습니다.
이것이 빌드 시간에 미치는 영향에 대해 약간 걱정하고 있습니다.
- 큰 프로젝트 (즉, 작은 하위 프로젝트)에 구조를 적용하면 컴파일러 속도가 느려 집니까?
또한 IDE에서 편집 시간이 미치는 영향에 대해 약간의 우려가 있습니다 (주로 Intellij를 사용합니다). Intellij는 종속성 트리를 통해 각 프로젝트를 차례로 빌드하는 것처럼 보입니다. 즉, C가 B에 의존하고 A가 A를 변경하면 A가 컴파일되지 않는 한 B를 빌드하려고 시도하지 않습니다. 아마도 그것은 유리하지만, 예를 들어 B와 C에서 널리 사용되는 A의 인터페이스를 변경하면 해당 변경으로 인한 모든 오류를 수정하는 데 시간이 걸립니다.
또 다른 질문은 팩토리 클래스를 사용하는 방법입니다. 프로젝트의 일부 측면은 외부 병에 달려 있습니다. 간혹 (고맙게도 자주는 아님) 이들은 업데이트되므로 마이그레이션해야합니다. 우리는 외부 코드의 올바른 버전을 가리키는 Factory 클래스를 사용하여 이것을 처리하는 경향이 있습니다 (따라서 코드베이스 전체에서 모든 구현을 변경할 필요는 없습니다).
현재 이것은 모두 큰 프로젝트에 있지만 하위 프로젝트로 전환하여 새로운 외부 코드 구현을위한 새 프로젝트를 개발하고 하위 프로젝트가 완벽하게 작동하고 테스트되었는지 확인할 수 있다고 생각합니다. 그런 다음 사용자 프로젝트에서 종속성 / 팩토리 클래스를 전환하십시오. 그러나 이는 대규모 프로젝트에서 인터페이스를 광범위하게 사용함으로써 더욱 복잡해집니다. 예를 들어
- 하위 프로젝트 A-인터페이스 포함
- 하위 프로젝트 B-인터페이스 및 이전 외부 jar의 경우 A에 의존
- 하위 프로젝트 C-B (따라서 A 및 이전 외부 jar)에 의존하고 B의 인터페이스 구현을 사용하는 Factory 클래스를 포함합니다.
B의 외부 항아리를 변경 해야하는 경우 다음을 수행 할 수 있습니다.
- 하위 프로젝트 B_ii 만들기-다시 A에 의존하고 이제 새로운 외부 jar
- 일단 완벽하게 작동하면 B_ii에 C의 종속성을 추가하고 새로운 인터페이스 구현을 사용하도록 Factory 클래스를 변경할 수 있습니다.
그것이 모두 작동하면 원본 B에 대한 C의 종속성을 제거하고 원하는 경우 하위 프로젝트 B를 제거 할 수 있습니다.
이것에 대한 합리적인 방법입니까?
따라서 일반적으로 내 질문은 다음과 같습니다.
- 누구든지 큰 프로젝트를 해체 한 경험이 있습니까? 공유하고 싶은 팁 / 트릭이 있습니까?
- 이것이 개발 및 구축 시간에 어떤 영향을 미쳤습니까?
- 그러한 프로젝트의 해체를 구성하는 데 어떤 조언을 해 줄 수 있습니까?