트러블슈팅
📚프로젝트 초기 설정 문제
프로젝트 시작 시, 모든 Entity를 미리 생성하지 않아 의존성 주입에 어려움을 겪었음. 예를들어, 카트에 메뉴를 담아야 하는데 Service를 만드는 도중 메뉴 Entity가 없어서 가져오지 못함.
📖해결 방법
진행중이던 코드를 일단 병합한 후 기본적인Entity와 Repository를 만든 후 다시 코딩함.
📚서비스 계층에서의 예외 처리
Service 계층에서 Optional 객체를 처리할 때마다 .orElseThrow()를 사용하는 것이 코드 가독성을 떨어뜨렸음. 하나의 클래스에 여러 의존관계가 있고, 가져와야하는 대상이 많으면 지져분해 보임.
📖해결 방법
서비스 클래스 내에 공통적으로 사용할 수 있는 private Store getStore() 메서드와 같이 예외처리 로직을 분리하여 중복 코드를 제거하고 가독성을 향상시킴.
Store store = getStoreEntity(storeId);
/**
* Store 객체 가져오며 예외처리
*/
private Store getStoreEntity(Long storeId) {
return storeRepository.findById(storeId)
.orElseThrow(() -> new NoSuchElementException("Store with id " + storeId + " not found"));
}📚장바구니(Cart) 설계 논의
장바구니와 관련된 엔티티 설계 시 팀원 간 의견 차이가 있었음. Cart와 Orders를 결합하여 사용 하는 방식과 Cart, Cart_items, Orders로 나누어 사용하는 방법으로 나뉘었음. 결합하여 사용하는 방식은 단일 책임 원칙을 지키지 못함.
📖해결 방법
팀원들과의 논의를 통해 Orders, Cart, Item으로 엔티티를 분리함.
⭐KPT 회고
Keep (유지할 점)
프로젝트 초기 설정 시 기본적인 엔티티와 레포지토리를 먼저 생성함.
빌더 패턴을 활용해 가독성 높고 유연한 객체 생성을 구현함.
팀원 간 적극적인 논의를 통해 장바구니 관련 엔티티 설계를 최적화했던 협업함.
Problem (문제점)
프로젝트 시작 시 전체적인 엔티티 구조 설계가 부족해 의존성 문제를 초래함.
서비스 계층에서 중복적으로 사용되는 .orElseThrow() 코드로 인해 가독성이 저하됨.
void 반환 메서드 테스트 시 직접적인 값 검증이 어려움.
초기 장바구니 설계에서 엔티티 간 관계와 역할 정의가 명확하지 않아 혼란 발생.
Try (시도할 점)
프로젝트 초기 설계 단계에서 전체적인 엔티티 구조를 명확히 정의하고 문서화하기.
테스트 코드 작성 시 verify와 같은 도구를 활용해 void 메서드의 간접적인 검증을 체계화하기.
엔티티 설계 시 더 많은 예제를 참고하거나, 초기 설계 단계에서 외부 피드백을 받아 설계 품질을 높이기.
