대규모 Maven 프로젝트의 저장소 레이아웃 탐색

이 포스트에서 설명하는 것처럼 여러 모듈이 있는 대규모 애플리케이션을 관리할 때, 개발자들은 종종 중요한 결정을 내리게 됩니다: Maven 프로젝트 저장소를 어떻게 구조화할 것인가? 약 50개의 모듈이 있는 경우 효과적인 레이아웃을 만드는 것이 명확성을 유지하고, 협력을 장려하며, 조직 프로세스를 단순화하는 데 필수적입니다.

고민: 트리 구조 vs. 플랫 구조

트리 구조

개발자들이 고려하는 일반적인 접근 방식 중 하나는 트리 구조입니다. 여기서는 모듈이 기능적 카테고리를 나타내는 하위 폴더로 구성됩니다. 예를 들어, 구조는 다음과 같을 수 있습니다:

• 애플리케이션
  • 통신 모듈
    • 색상 통신 모듈
    • SSN 통신 모듈
  • 라우터 모듈
  • 서비스 모듈
    • 투표 서비스 모듈
      • 웹 인터페이스 하위 모듈
      • 투표 수집 하위 모듈
    • 퀴즈 서비스 모듈

이 레이아웃은 계층적이고 시각적으로 직관적인 장점이 있지만, 상당한 단점이 있습니다:

• 복잡한 다중 모듈 보고: Maven에서 다중 모듈 보고를 잘 작동하게 하려면 많은 수정과 해킹이 필요할 수 있습니다.
• 서브버전 복잡성: Subversion에서 표준 트렁크/태그/브랜치 설정을 따르는 것은 구조를 더욱 복잡하게 만들 수 있습니다.

플랫 구조

대안으로 많은 개발자들이 플랫 구조를 지지합니다. 이 모델에서는 하나의 상위 프로젝트가 있으며, 모든 모듈, 하위 모듈, 관련 컴포넌트가 이 상위 프로젝트의 직접적인 자식입니다.

플랫 구조의 장점

• 간소화된 보고: 이 레이아웃은 Maven의 보고를 단순화하여, 의존성과 프로젝트 특성을 보다 효율적으로 처리할 수 있게 합니다.
• 서브버전과의 사용 용이성: Subversion에서 저장소를 관리하는 것이 보다 간단해지며, 탐색해야 할 계층이 줄어듭니다.
• 증가된 유연성: 플랫 구조는 모듈이 지속적으로 조직을 재구성하지 않고도 진화할 수 있도록 합니다. 통신 모듈로 시작한 모듈이 서비스 역할로 쉽게 적응할 수 있으며, 이는 저장소 구조의 큰 재구성을 요구하지 않습니다.

추천 사항: 플랫 선택

경험에서 얻은 통찰

대규모 애플리케이션을 관리하는 사람들—예를 들어 160개 이상의 OSGi 번들이 모두 Maven 모듈인 경우—의 경험에 따르면 플랫 구조가 더 좋습니다. 그 이유는 다음과 같습니다:

• 계층 구조에 따른 의미의 부여보다 유연성: 계층적 트리 구조를 사용하면 엄격한 의미에 얽매일 수 있습니다. 모듈의 목적이 개발 과정에서 변경되면, 문서, 스크립트 및 참조를 방해하는 광범위한 재배치가 필요할 수 있습니다.
• 다른 곳에서의 의미 완전함: 모듈의 목적과 기능을 전달하기 위해 물리적 구조에 의존하기보다는 다른 도구를 사용하는 것이 좋습니다. 전용 IDE 작업 공간이나 종합적인 문서를 통해 의미를 코딩하는 것은 저장소 구조의 유연성을 유지하면서 정보를 접근 가능하고 정리된 상태로 유지할 수 있습니다.

결론

결론적으로, 트리 구조와 플랫 구조 모두 장점이 있지만, 대규모 Maven 프로젝트에 플랫 저장소 구조를 채택하는 것이 유연성, 관리 및 Subversion과 같은 버전 관리 시스템과의 통합 용이성 측면에서 장기적으로 더 큰 이점을 가져다주는 경향이 있습니다.

이 주제에 대해 더 알아보고 싶다면, Stack Overflow에서 이 논의를 확인해 보세요. 여러 프로젝트 구조와 그 의미에 대한 설명이 나와 있습니다.

---