지도 범위 내 클러스터형, 마커형 나의 다이어리 조회 API 구현

[dnzp75]

📌 PR 제목

• 지도 범위 내 마커형 공개 다이어리 조회 API 구현 #33
  -> 이전 브랜치 병합하여 계속 작업 진행

✨ 변경 사항

지도 범위 내 클러스터형 나의 다이어리 조회 API

• 줌레벨 10 미만: 시/도(Sido) 단위로 클러스터링
• 줌레벨 10 이상: 시/군/구(Sigg) 단위로 클러스터링
• 다이어리 좌표 기준으로 해당 지역 매핑 → 지역별 다이어리 수 집계
  • 매핑 실패 시 "UNKNOWN" 으로 처리하고 경고 로그 출력

지도 범위 내 마커형 나의 다이어리 조회 API

• 특정 사용자(userId)의 다이어리를 지도 범위(south, north, west, east) 내에서 조회

🔍 변경 이유

✅ 체크리스트

• 코드가 정상적으로 동작하는지 확인
• 관련 테스트 코드 작성 및 통과 여부 확인
• 문서화(README 등) 필요 여부 확인 및 반영
• 리뷰어가 알아야 할 사항 추가 설명

📸 스크린샷 (선택)

📌 참고 사항

• 추 후 성능 테스트 필요함

[github-actions]

Claude의 전체 변경사항 및 관련 파일에 대한 리뷰:

개선된 사항:

• 다중 데이터베이스 설정(MySQL과 PostgreSQL)을 통한 확장성 개선
• 지도 기능 추가로 사용자 경험 향상
• 클러스터링 및 마커 기능을 통한 효율적인 데이터 시각화
• 전략 패턴을 활용한 유연한 지역 데이터 처리

주요 이슈:

1. 트랜잭션 관리 개선 필요

   • 제안: MapService의 increaseRegionDiaryCount 메소드에 @transactional 어노테이션 추가

   @Transactional
   public void increaseRegionDiaryCount(Double lat, Double lon) {
       // 기존 코드
   }

2. 예외 처리 강화

   • 제안: MapService에서 지역을 찾지 못했을 때 NotFoundRegionException 처리

   public void increaseRegionDiaryCount(Double lat, Double lon) {
       sidoAreasRepository.findRegionByLatLon(lat, lon)
           .orElseThrow(() -> new NotFoundRegionException("시도 지역을 찾을 수 없습니다."))
           .flatMap(sido -> sidoAreasDiaryCountRepository.findById(sido.getId()))
           // 나머지 코드
   }

3. 테스트 커버리지 확대

   • 제안: MapController에 대한 단위 테스트 추가

   @WebMvcTest(MapController.class)
   class MapControllerTest {
       @Autowired
       private MockMvc mockMvc;
   
       @MockBean
       private MapService mapService;
   
       @Test
       void getDiaryClusters_shouldReturnClusters() throws Exception {
           // 테스트 코드 구현
       }
   }

관련 파일에 대한 영향 분석:

• DiaryService: MapService와의 통합으로 다이어리 생성 시 지역 데이터 업데이트 필요
• CustomDiaryRepository: 지도 기능 추가로 인한 쿼리 최적화 필요 가능성
• 테스트 클래스들: 새로운 기능에 대한 테스트 케이스 추가 필요

전반적인 의견:
코드 품질이 전반적으로 향상되었으며, 새로운 기능 추가로 애플리케이션의 가치가 높아졌습니다. 다만, 트랜잭션 관리와 예외 처리에 대한 추가적인 주의가 필요하며, 테스트 커버리지를 확대하여 안정성을 더욱 높일 필요가 있습니다.

[github-actions]

Claude의 전체 변경사항 및 관련 파일에 대한 리뷰:

Error: API returned status code 529

[TTaiJin]

고생하셨습니다! 지도 관련 부분은 다뤄본적이 없어서 완벽하게 이해는 조금 힘드네요..ㅎ
다이어리 생성할 때 해당 지역에 대한 다이어리 개수 증가는 추가하신거같은데 삭제할 때는 해당 지역의 다이어리 개수 감소가 없는 거 같은데 한번 확인 부탁드립니다!

[dnzp75]

감소는 생각치 못하고 있었네요. 올라와있는 PR들 머지 후 새로운 브랜치에서 작업 진행하겠습니다!

[InJunKangW]

환경 설정도 복잡하고 코드도 많아서 어려우셨을텐데 고생 많으셨습니다.
리팩토링 관점에서만 몇 가지 리뷰 남겨서, 그 부분 확인해주시면 될 것 같아요!

[InJunKangW]

@AuthenticationPrincipal CustomOAuth2User customOAuth2User,

이거로 받고 getUserId() 호출 하기로 했었던 걸로 기억을 해요. 기존 건희님 코드 (Comment) 에서도 그렇게 하셨던데, 혹시 다르게 하신 이유가 따로 있을까요?

[dnzp75]

스웨거에서 바로 테스트 진행하고자 임시로 이렇게 했었습니다. 다시 수정해두겠습니다~

[InJunKangW]

트랜잭션 설정이 안돼있는 것 같아요~

[InJunKangW]

SidoAreas랑 SiggAreas를 Areas라는 추상 클래스를 상속하도록 변경하고

public static <T extends Areas> DiaryClusterResponseDto of(T region, Long diaryCount){
    return new DiaryClusterResponseDto(
			region.getName(),
			region.getId(),
			region.getLat(),
			region.getLon(),
			diaryCount
		);
	}

같이 추상화 할 수 있을 것 같아요!

[dnzp75]

저도 entity 클래스 추상화를 고민하고 있었는데, 자세한 예시까지 작성해주셔서 훨씬 이해하기 쉬웠습니다. 감사합니다.

추상화를 주저했던 이유는, entity 내부에 오버라이드 메서드를 추가해야 하고 나중에 응답 데이터 형식이 바뀔 경우 해당 메서드들도 함께 수정해줘야 한다는 점에서 유지보수 부담이 생길 수 있겠다는 우려 때문이었던 것 같아요.

근데 어차피 of() 메서드에서 getter를 사용하는 구조라면 결국 책임이 어디에 위치하느냐의 차이일 수도 있다는 생각도 드네요. 꼼꼼한 리뷰 감사합니다

[InJunKangW]

위의 DiaryClusterResponseDto 에서 남긴 것과 같은 맥락에서,

public interface AreaRegion<T extends Areas> {
	List<T> findRegionsInBounds(double south, double north, double west, double east);

	Optional<T> findRegionByLatLon(double lat, double lon);

	default String extractAreaName(T area){
           return area.getName()
          };

	default DiaryClusterResponseDto toDto(T area, Long count){
            return DiaryClusterResponseDto.of(area, count);}
         }
}

로 만들면
밑의 두 매서드는 오버라이딩 안해도 될 것 같아요.

[dnzp75]

그러네요. 제네릭 사용하는 것에 있어서 이해가 부족했던 것 같네요. 수정하면서 배워갑니다!

[sonarqubecloud]

Quality Gate passed

Issues
15 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
1.6% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

Claude의 전체 변경사항 및 관련 파일에 대한 리뷰:

개선된 사항:

• 다중 데이터베이스 구성(MySQL과 PostgreSQL)을 통한 확장성 향상
• 지도 기능 추가로 다이어리의 위치 기반 서비스 구현
• 다이어리 클러스터링 및 마커 기능 추가로 사용자 경험 개선

주요 이슈:

1. 데이터베이스 연결 구성의 중복

   • 제안: MySqlConfig와 PostgreSqlConfig 클래스의 중복 코드를 줄이기 위해 공통 설정을 추상 클래스로 분리

   public abstract class AbstractDatabaseConfig {
       protected LocalContainerEntityManagerFactoryBean createEntityManagerFactory(
           DataSource dataSource, String[] packagesToScan, String dialectClass) {
           // 공통 설정 로직
       }
   }

2. 지역 조회 전략의 중복

   • 제안: SidoRegionStrategy와 SiggRegionStrategy의 중복 로직을 템플릿 메서드 패턴을 사용하여 추상 클래스로 리팩토링

   public abstract class AbstractRegionStrategy<T extends Areas> implements AreaRegion<T> {
       protected abstract JpaRepository<T, Long> getRepository();
   
       @Override
       public List<T> findRegionsInBounds(double south, double north, double west, double east) {
           return getRepository().findWithinBoundingBox(south, north, west, east);
       }
   }

3. 예외 처리 개선

   • 제안: 맵 관련 예외들을 좀 더 세분화하고, 전역 예외 핸들러를 구현하여 일관된 에러 응답 제공

   @ControllerAdvice
   public class GlobalExceptionHandler {
       @ExceptionHandler(MapException.class)
       public ResponseEntity<ErrorResponse> handleMapException(MapException ex) {
           // 맵 관련 예외 처리 로직
       }
   }

관련 파일에 대한 영향 분석:

• 데이터베이스 구성 변경: JPA 리포지토리와 서비스 레이어의 트랜잭션 관리에 영향을 줄 수 있음. 특히 크로스 데이터베이스 트랜잭션 처리에 주의가 필요함.
• 지도 기능 추가: 다이어리 서비스와 밀접하게 연관되어 있어, 다이어리 생성/수정/삭제 시 지도 데이터도 함께 업데이트되어야 함. 성능 최적화를 위해 비동기 처리 고려 필요.
• 새로운 엔티티(SidoAreas, SiggAreas) 추가: 기존 다이어리 엔티티와의 관계 설정 및 조인 쿼리 최적화 필요.

전반적인 의견:
코드베이스가 기능적으로 확장되었으며, 다중 데이터베이스 지원과 지도 기능 추가로 애플리케이션의 복잡도가 증가했습니다. 코드 재사용과 확장성을 고려한 리팩토링이 필요하며, 특히 데이터베이스 연결 구성과 지역 조회 전략에서 중복을 제거하는 것이 중요합니다. 또한, 새로운 기능에 대한 철저한 테스트와 성능 모니터링이 필요할 것으로 보입니다.