Service, Repository를 interface로 만들었을... - 인프런

Java/Spring 테스트를 추가하고 싶은 개발자들의 오답노트

Service, Repository를 interface로 만들었을때 궁금한게 있습니다.

작성

231

수정됨

테스트 코드를 작성할 때 DIP를 이용해서 결합도를 낮추고, 빠르게 테스트를 하는 것을 확인하였습니다.
궁금한 점은 interface로 서비스 레파지토리를 선언해서 사용하면,

인터페이스 자체가 어떻게보면 다형성을 위해 도면을 구성한다고 생각되는데, FakeImpl을 만들기위해서 너무 많이 다형성을 사용하는게 아닌가 싶은 생각도 들어서요. 초기 프로젝트에는 오버엔지니어링이 되지는 않을까 고민이 됩니다.
소스코드 관리하는 점에서 따라가기 쉽지 않은 것을 느꼈습니다. 물론 패키지 구조를 잘 알고 있는 사람이라면 쉽게 접근하겠지만, 그렇지 않은 사람이 코드를 분석했을 때 함수를 클릭해서 접근은 하는 경우가 많더라고요. 이럴 경우에는 패키지 구조를 도식화해서 공유해서 해결하는지, 궁금합니다.

답변 2

프로덕트 규모가 작은 프로젝트라고 한다면 오버엔지니어링이 맞습니다. 다만 프로덕트 규모가 커지게 되고 모듈 단위가 다양하다면 모듈 단위로 테스트 가능하게 코드가 만들어져 있지 않으면 사람이 테스트를 수행하는 수 밖에 없습니다.
개발 문서 또는 readme 에 아키텍처 구조, 컨벤션 같은 것을 작성하고 공유하는게 좋습니다.

안녕하세요, 인프런 AI 인턴입니다.

박태영님의 질문에 대해 답변드리겠습니다.

서비스와 레포지토리를 인터페이스로 분리하는 것은 DIP(의존성 역전 원칙)을 이행하여 의존성의 관리를 유연하게 하기 위한 방법 중 하나입니다. 초기 프로젝트에서 인터페이스를 사용하는 것이 오버엔지니어링처럼 느껴질 수 있지만, 장기적으로 프로젝트의 확장성과 유지보수성을 고려할 때 유리합니다. FakeImpl 같은 테스트용 구현체를 만들어 사용하는 것도 다형성을 활용하면서 유연한 테스트가 가능해집니다. 따라서 프로젝트의 규모와 향후 유지보수 계획을 고려하여 적절한 수준에서 인터페이스를 도입하는 것이 좋습니다.
소스 코드 관리 및 프로젝트의 구조를 이해하는 것은 초보자에게는 분명 어려울 수 있습니다. 이러한 문제를 해결하기 위해, 일반적으로는 문서화 작업을 통해 패키지 구조를 명확히 설명하고, 클래스 및 인터페이스 간의 관계를 도식화하여 공유합니다. 또한, 모던 IDE를 활용하면 코드를 통한 네비게이션이 용이하므로, 적절한 도구 사용도 하나의 해결 방안이 될 수 있습니다. 프로젝트 멤버들이 패키지 구조와 코드의 구성을 빠르게 이해할 수 있도록 지속적인 커뮤니케이션과 문서화 작업을 병행하는 것이 중요합니다.

프로젝트 초기 단계에서 이러한 고민을 하는 것은 매우 긍정적인 접근이라 할 수 있습니다. 팀원들과 충분한 논의를 거쳐, 프로젝트에 가장 적합한 개발 방법을 찾으시길 바랍니다.