자바 프로젝트 분리


12

큰 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를 제거 할 수 있습니다.

  • 이것에 대한 합리적인 방법입니까?

따라서 일반적으로 내 질문은 다음과 같습니다.

  • 누구든지 큰 프로젝트를 해체 한 경험이 있습니까? 공유하고 싶은 팁 / 트릭이 있습니까?
  • 이것이 개발 및 구축 시간에 어떤 영향을 미쳤습니까?
  • 그러한 프로젝트의 해체를 구성하는 데 어떤 조언을 해 줄 수 있습니까?

A, B 및 C가 나란히 체크 아웃 된 상위 프로젝트를 작성할 수 있습니다. 이를 통해 예를 들어 IntelliJ는 동시에 세 개의 메모리를 모두 보유하고 모듈 경계를 넘어 리팩토링을 수행 할 수 있습니다.
Thorbjørn Ravn Andersen

답변:


10

나는 이것에 대해 빠른 첫 컷을 할 것입니다 (위대한 Q BTW!) :

큰 프로젝트 (즉, 작은 하위 프로젝트)에 구조를 적용하면 컴파일러 속도가 느려 집니까?

충분하지는 않지만 오버 헤드는 실제로 Maven 호출에 있습니다.

또한 IDE에서 편집 시간이 미치는 영향에 대해 약간의 우려가 있습니다 (주로 Intellij를 사용합니다). Intellij는 종속성 트리를 통해 각 프로젝트를 차례로 빌드하는 것처럼 보입니다. 즉, C가 B에 의존하고 A가 A를 변경하면 A가 컴파일되지 않는 한 B를 빌드하려고 시도하지 않습니다. 아마도 그것은 유리하지만, 예를 들어 B와 C에서 널리 사용되는 A의 인터페이스를 변경하면 해당 변경으로 인한 모든 오류를 수정하는 데 시간이 걸립니다.

서로 다른 IDE는 Maven 바인딩 및 종속성 관리와 관련하여 서로 다른 강점을 가지고 있습니다. 현재의 플레이 상태는 대부분 최신 Eclipse, Netbeans 및 IntelliJ에서만 작동 하는 것 같습니다. 그러나 개발자에게 "디스크에서 소스 파일을 새로 고치고 모든 관련 maven 프로젝트를 다시 빌드하십시오"라는 긴급한 이중 문제를 개발자에게 가르쳐야합니다.

나는 요즘 그렇게 적게해야한다고 생각합니다. SSD 드라이브가 있으면 BTW와 큰 차이가 있습니다.

공장 클래스 단락

종속성 관리는 구현에 도움이되는 기술 (Maven / Ivy / 무엇이든)에 관계없이 엄청나게 중요합니다.

Maven 종속성 플러그인에서 광범위한 보고서를 가져 와서 얻은 정보를 가져옵니다. 일반적으로 POM의 종속성 관리에 대한 종속성을 가능한 한 먹이 사슬의 높이로 설정했지만 높지는 않습니다. 따라서 두 개의 하위 모듈이 외부 종속성을 사용하는 경우 해당 하위 모듈을 상위 POM 등에 넣습니다.

외부 JAR 업그레이드는 항상 적절한 미니 프로젝트로 수행해야합니다. 업그레이드하는 이유를 평가하고, 새로운 기능 / 버그 수정 등을 활용하도록 소스 코드를 변경하십시오.이 분석 및 작업없이 버전을 충돌 시키면 문제가 발생할 수 있습니다.

따라서 일반적으로 내 질문은 다음과 같습니다.

누구든지 큰 프로젝트를 해체 한 경험이 있습니까? 공유하고 싶은 팁 / 트릭이 있습니까?

  • 인터페이스와 의존성 주입은 당신의 친구입니다.
  • 레거시 코드를 효과적으로 다루는 Michael Feather의 책 은 반드시 읽어야합니다.
  • 통합 테스트는 당신의 친구입니다
  • 하위 프로젝트를 foo-api (인터페이스 만!) 및 foo-core로 분할하고 foo-api에만 의존하는 모듈을 갖는 것은 큰 도움이되고 분리를 강제합니다
  • Jboss 모듈 및 / 또는 OSGi는 깔끔한 분리를 도와줍니다

이것이 개발 및 구축 시간에 어떤 영향을 미쳤습니까?

개발 및 구축 시간에 미치는 영향은 매우 적습니다. 전체적인 지속적인 전달 파이프 라인의 시간이 크게 늘어납니다.

그러한 프로젝트의 해체를 구성하는 데 어떤 조언을 해 줄 수 있습니까?

작은 것을 올바르게하고 큰 것은 나중에 깨끗하게 빠지는 경향이 있습니다. 따라서 비트 단위로 분할-통합 테스트에서 높은 범위의 커버리지를 얻지 않는 한 전체 로트를 대규모로 재구성하지 마십시오.

분할 전에 통합 테스트를 작성하십시오. 분할 후 동일한 결과를 얻거나 줄여야합니다.

현재 보유하고있는 모듈화의 다이어그램을 그리십시오. 중간 단계를 설계하십시오.

포기하지 마십시오. 일부 Yak 면도는 이제 Ben의 " Shameless plug- > "와 " The Go-Grounded Java Developer "를 "두려워하지 않고 신속하게 구축 및 리팩토링"할 수있는 토대를 구축합니다 .

행운을 빌어 요!


0

이것에 대한 나의 취지는 필요할 때만 분리됩니다. 그러나 다음 질문이 나타납니다. 필요한지 어떻게 알 수 있습니까?

  • 아티팩트가 다른 경우 (예 : 동일한 프로젝트에서 EAR, WAR, JAR, integration-testing-jar을 빌드하지 않음)
  • 분리하는 동안 일부 코드가 둘 이상의 이슈에 있어야 새로운 코드로 리팩터링 할 수 있습니다.
  • 팀 외부의 다른 프로젝트가 프로젝트에있는 것을 사용하려고 할 때.

한 가지 이유는 개발자가 여러 프로젝트를 처리하고 어떤 Java 패키지가 어떤 프로젝트에 속하는지 알아 내려고 노력해야하기 때문입니다. 나는 그것이 실제로 빈혈이 된 프로젝트에 있었고 건축 방향이기 때문에 하나의 기능을 구현하는 4 개의 클래스가있는 프로젝트를 가졌습니다. 이것은 또한 Maven이 널리 사용되기 전에 돌아 왔으므로 클래스 경로와 IDE 및 Ant 스크립트 모두에 설정할 필요가 없습니다.

다른 이유는 파일을 배관하는 것과 관련하여 처리해야 할 부분이 더 많고 알기 전에 종속성 스파게티가있을 가능성이 있기 때문입니다.

리팩토링은 프로젝트 전체가 아닌 프로젝트 내에서 더 쉽습니다.

빌드 시간이 문제라면 더 나은 하드웨어를 제공하십시오.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.