Develop

[HyunWoo9930]

• 🔀 PR 제목의 형식을 잘 작성했나요? e.g. [feat] PR을 등록한다.
• 💯 테스트는 잘 통과했나요?
• 🏗️ 빌드는 성공했나요?
• 🧹 불필요한 코드는 제거했나요?
• 💭 이슈는 등록했나요?
• 🏷️ 라벨은 등록했나요?

작업 내용

주의사항

Summary by CodeRabbit

• 새로운 기능

  • 추가 매장 정보 저장을 위한 새로운 엔드포인트 생성.
  • 매장 정보 조회 로직 간소화: 이제 인증된 사용자 정보를 기반으로 매장 정보를 가져옵니다.
  • 매장 예약 설정 및 결제 세부정보 업데이트를 위한 새로운 메서드 추가.
  • 팀 등록 기능 추가: 사용자가 팀을 생성할 수 있는 기능 제공.

• 변경 사항

  • 매장 운영 시간 및 요일의 데이터 구조 개선.
  • DTO 클래스에서 예약 관련 필드 제거 및 데이터 타입 변경.
  • 팀 관련 데이터 구조 개선: 팀과 사용자 간의 관계를 명확히 하기 위한 구조 변경.
  • 인증 파서에서 사용자 ID 처리 방식 변경: 사용자 ID를 문자열로 반환하도록 수정.

[coderabbitai]

Caution

Review failed

The pull request is closed.

Walkthrough

이 변경 사항은 OAuthUserService, Store, StoreCreateRequestDTO, StoreGetResponseDTO, StoreUpdateRequestDTO, StoreAdditionalInfoCreateRequestDTO, StoreController, 및 StoreService 클래스의 여러 메서드와 속성에 대한 수정으로 구성됩니다. OAuthUserService는 사용자 생성 및 역할 할당 로직을 업데이트했으며, Store 클래스는 여러 요일을 저장할 수 있도록 속성을 변경했습니다. 새로운 DTO 클래스가 추가되었고, 기존 DTO 클래스의 필드 타입이 변경되었습니다. 또한, 새로운 엔드포인트 및 메서드가 추가되어 저장소 정보 처리 방식이 개선되었습니다.

Changes

파일 경로	변경 요약
src/main/java/com/jangburich/domain/oauth/domain/service/OAuthUserService.java	loadUser 메서드에서 사용자 존재 여부와 역할을 확인하는 조건을 수정하여 새로운 소유자 사용자를 생성하도록 변경.
src/main/java/com/jangburich/domain/store/domain/Store.java	dayOfWeek 속성을 List<DayOfWeek>로 변경하고, openTime 및 closeTime을 LocalTime으로 변경. 관련 애너테이션 추가.
src/main/java/com/jangburich/domain/store/domain/StoreCreateRequestDTO.java	reservationAvailable, maxReservation, minPrepayment, prepaymentDuration 필드를 제거하고, dayOfWeek를 List<DayOfWeek>로, openTime 및 closeTime을 LocalTime으로 변경.
src/main/java/com/jangburich/domain/store/domain/StoreGetResponseDTO.java	dayOfWeek, openTime, closeTime 필드를 List<DayOfWeek>, LocalTime으로 변경. 생성자 및 of 메서드 수정.
src/main/java/com/jangburich/domain/store/domain/StoreUpdateRequestDTO.java	dayOfWeek를 List<DayOfWeek>로, openTime 및 closeTime을 LocalTime으로 변경.
src/main/java/com/jangburich/domain/store/domain/StoreAdditionalInfoCreateRequestDTO.java	새로운 DTO 클래스 추가, 예약 관련 정보를 담는 필드 포함.
src/main/java/com/jangburich/domain/store/domain/controller/StoreController.java	새로운 메서드 createAdditionalInfo 추가 및 getStoreInfo 메서드에서 storeId를 제거하고 인증된 사용자 정보를 사용하여 저장소 정보를 가져오도록 변경.
src/main/java/com/jangburich/domain/store/domain/service/StoreService.java	새로운 메서드 CreateAdditionalInfo 추가 및 getStoreInfo 메서드에서 storeId 제거, 인증된 사용자와 연결된 저장소를 직접 가져오도록 변경.

Poem

🐰 새로운 변화가 왔어요,
저장소의 정보가 밝아졌죠.
요일과 시간, 더 명확하게,
사용자 역할도 잘 정리되었죠.
함께 뛰어놀며 기뻐해요,
변화의 순간을 축하해요! 🌼

---

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[coderabbitai]

Actionable comments posted: 5

🧹 Outside diff range and nitpick comments (9)

src/main/java/com/jangburich/domain/store/domain/StoreAdditionalInfoCreateRequestDTO.java (1)

1-15: 클래스 문서화가 필요합니다.

클래스의 목적과 각 필드에 대한 설명이 없어 코드의 가독성과 유지보수성이 떨어집니다.

Javadoc 추가를 제안드립니다:

+/**
+ * 매장의 추가 정보를 생성하기 위한 DTO 클래스입니다.
+ */
public class StoreAdditionalInfoCreateRequestDTO {
+    /** 예약 가능 여부 */
     private Boolean reservationAvailable;
+    /** 최대 예약 가능 인원 */
     private Long maxReservation;
+    /** 최소 선결제 금액 (원) */
     private Long minPrepayment;
+    /** 선결제 유효 기간 (분) */
     private Long prepaymentDuration;

src/main/java/com/jangburich/domain/store/domain/StoreCreateRequestDTO.java (1)

34-36: 필드 타입 변경이 적절하나, 추가적인 개선사항이 있습니다.

타입 변경은 데이터의 정확성과 안정성을 향상시켰습니다. 다만 다음 사항들을 고려해주시기 바랍니다:

1. dayOfWeek 리스트에 대한 유효성 검증이 필요합니다 (중복된 요일, 빈 리스트 등).
2. openTime과 closeTime에 대한 비즈니스 규칙 검증이 필요합니다 (예: closeTime이 openTime보다 늦은 시간인지).
3. 각 필드의 용도와 제약사항을 설명하는 JavaDoc 주석 추가를 권장합니다.

다음과 같이 개선하실 것을 제안드립니다:

 // business hour
+/**
+ * 영업일 목록
+ * 중복된 요일은 허용되지 않습니다.
+ */
 private List<DayOfWeek> dayOfWeek;
 
+/**
+ * 영업 시작 시간
+ * closeTime보다 이른 시간이어야 합니다.
+ */
 private LocalTime openTime;
 
+/**
+ * 영업 종료 시간
+ * openTime보다 늦은 시간이어야 합니다.
+ */
 private LocalTime closeTime;

src/main/java/com/jangburich/domain/store/domain/controller/StoreController.java (1)

66-69: 엔드포인트 경로 설계를 검토해 주세요.

빈 문자열("")을 경로로 사용하는 것은 다른 엔드포인트와 충돌할 수 있습니다. 명시적인 경로를 사용하는 것이 좋습니다.

다음과 같이 수정을 제안드립니다:

- @GetMapping("")
+ @GetMapping("/info")

또한, Swagger 문서에 응답 예시와 가능한 오류 상황을 추가하면 좋을 것 같습니다:

@Operation(
    summary = "가게 정보 조회",
    description = "가게 상세 정보를 조회합니다.",
    responses = {
        @ApiResponse(
            responseCode = "200",
            description = "조회 성공",
            content = @Content(schema = @Schema(implementation = StoreGetResponseDTO.class))
        ),
        @ApiResponse(
            responseCode = "404",
            description = "가게 정보를 찾을 수 없음"
        )
    }
)

src/main/java/com/jangburich/domain/store/domain/Store.java (2)

79-91: 시간 형식에 대한 타임존 고려가 필요할 수 있습니다.

@JsonFormat 패턴이 "HH:mm:ss"로 지정되어 있지만, 타임존에 대한 처리가 명시되어 있지 않습니다. 글로벌 서비스를 고려하고 있다면 타임존 처리를 추가하는 것이 좋습니다.

다음과 같이 timezone을 명시적으로 지정하는 것을 고려해보세요:

-@JsonFormat(shape = JsonFormat.Shape.STRING, pattern = "HH:mm:ss")
+@JsonFormat(shape = JsonFormat.Shape.STRING, pattern = "HH:mm:ss", timezone = "Asia/Seoul")

---

Line range hint 96-113: 중복된 setAddress() 호출을 제거해야 합니다.

of() 메소드에서 setAddress()가 두 번 호출되고 있습니다.

다음과 같이 수정해주세요:

 newStore.setLongitude(storeCreateRequestDTO.getLongitude());
 newStore.setAddress(storeCreateRequestDTO.getAddress());
-newStore.setAddress(storeCreateRequestDTO.getAddress());
 newStore.setLocation(storeCreateRequestDTO.getLocation());

src/main/java/com/jangburich/domain/oauth/domain/service/OAuthUserService.java (1)

79-79: 역할 검증 로직이 개선되었습니다만, 주석이 필요합니다.

역할 검증 로직이 적절하게 구현되었습니다. 하지만 이 조건문의 의도를 명확히 하기 위해 주석을 추가하는 것이 좋겠습니다.

다음과 같이 주석을 추가하는 것을 제안합니다:

+  // 사용자가 존재하지 않거나 ROLE_OWNER 권한이 없는 경우 새로운 소유자 계정을 생성
   if (existUser == null || !existUser.getRole().equals("ROLE_OWNER")) {

src/main/java/com/jangburich/domain/store/domain/service/StoreService.java (3)

32-36: 사용자 및 소유자 조회 로직을 메서드로 추출하여 코드 중복을 줄이세요

여러 메서드에서 동일한 사용자 및 소유자 조회 로직이 반복되고 있습니다. 이 로직을 별도의 private 메서드로 추출하면 코드 중복을 줄이고 유지보수를 용이하게 할 수 있습니다.

예를 들어, 다음과 같이 getAuthenticatedOwner 메서드를 추가할 수 있습니다:

private Owner getAuthenticatedOwner(CustomOAuthUser customOAuthUser) {
    User user = userRepository.findByProviderId(customOAuthUser.getUserId())
        .orElseThrow(() -> new DefaultNullPointerException(ErrorCode.INVALID_AUTHENTICATION));

    return ownerRepository.findByUser(user)
        .orElseThrow(() -> new DefaultNullPointerException(ErrorCode.INVALID_AUTHENTICATION));
}

그리고 각 메서드에서 다음과 같이 변경할 수 있습니다:

- User user = userRepository.findByProviderId(customOAuthUser.getUserId())
-     .orElseThrow(() -> new DefaultNullPointerException(ErrorCode.INVALID_AUTHENTICATION));
-
- Owner owner = ownerRepository.findByUser(user)
-     .orElseThrow(() -> new DefaultNullPointerException(ErrorCode.INVALID_AUTHENTICATION));
+ Owner owner = getAuthenticatedOwner(customOAuthUser);

Also applies to: 44-48, 121-125

---

66-68: 소유자 인증 체크 로직을 메서드로 추출하여 중복을 제거하세요

updateStore와 getStoreInfo 메서드에서 소유자 인증을 확인하는 로직이 반복되고 있습니다. 이 부분을 별도의 메서드로 추출하여 코드 중복을 줄이고 유지보수를 용이하게 할 수 있습니다.

예를 들어, 다음과 같이 validateOwner 메서드를 추가할 수 있습니다:

private void validateOwner(Store store, CustomOAuthUser customOAuthUser) {
    if (!store.getOwner().getUser().getProviderId().equals(customOAuthUser.getUserId())) {
        throw new DefaultNullPointerException(ErrorCode.INVALID_AUTHENTICATION);
    }
}

그리고 해당 메서드들에서 인증 체크 코드를 다음과 같이 수정할 수 있습니다:

- if (!store.getOwner().getUser().getProviderId().equals(customOAuthUser.getUserId())) {
-     throw new DefaultNullPointerException(ErrorCode.INVALID_AUTHENTICATION);
- }
+ validateOwner(store, customOAuthUser);

Also applies to: 130-132

---

74-118: updateStore 메서드를 리팩토링하여 가독성을 향상시키세요

updateStore 메서드는 많은 if 문으로 구성되어 코드가 길고 읽기 어려울 수 있습니다. 이를 리팩토링하여 가독성을 높일 수 있습니다. 예를 들어, 업데이트 로직을 필드별로 별도의 메서드로 분리하거나 맵을 활용하여 동적으로 필드를 업데이트하는 방법을 고려해 볼 수 있습니다.

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 4b95a7a and 2c51360.

📒 Files selected for processing (8)

• src/main/java/com/jangburich/domain/oauth/domain/service/OAuthUserService.java (1 hunks)
• src/main/java/com/jangburich/domain/store/domain/Store.java (3 hunks)
• src/main/java/com/jangburich/domain/store/domain/StoreAdditionalInfoCreateRequestDTO.java (1 hunks)
• src/main/java/com/jangburich/domain/store/domain/StoreCreateRequestDTO.java (2 hunks)
• src/main/java/com/jangburich/domain/store/domain/StoreGetResponseDTO.java (3 hunks)
• src/main/java/com/jangburich/domain/store/domain/StoreUpdateRequestDTO.java (2 hunks)
• src/main/java/com/jangburich/domain/store/domain/controller/StoreController.java (3 hunks)
• src/main/java/com/jangburich/domain/store/domain/service/StoreService.java (2 hunks)

🔇 Additional comments (10)

src/main/java/com/jangburich/domain/store/domain/StoreCreateRequestDTO.java (1)

3-5: 필요한 임포트가 올바르게 추가되었습니다!

시간과 요일을 더 정확하게 표현하기 위한 적절한 타입들이 임포트되었습니다.

src/main/java/com/jangburich/domain/store/domain/StoreUpdateRequestDTO.java (2)

3-5: 필요한 임포트문이 모두 추가되었습니다.

새로운 타입 DayOfWeek, LocalTime, List를 위한 임포트문이 적절히 추가되었습니다.

---

Line range hint 1-31: 전체적인 구조가 깔끔합니다.

• Lombok 어노테이션을 적절히 사용하여 보일러플레이트 코드를 줄였습니다.
• JPA 관련 어노테이션도 올바르게 사용되었습니다.
• 필드명이 명확하고 이해하기 쉽습니다.

src/main/java/com/jangburich/domain/store/domain/StoreGetResponseDTO.java (4)

3-5: 필요한 임포트가 잘 추가되었습니다.

시간과 요일 관련 데이터 타입 변경에 따른 적절한 임포트가 추가되었습니다.

---

41-43: 생성자 매개변수 타입이 올바르게 업데이트되었습니다.

필드 타입 변경사항이 생성자 매개변수에도 정확히 반영되었습니다.

---

34-36: 데이터 타입 변경이 적절합니다.

• dayOfWeek를 List<DayOfWeek>로 변경하여 여러 영업일을 저장할 수 있게 되었습니다.
• openTime과 closeTime을 LocalTime으로 변경하여 시간 데이터를 더 정확하게 다룰 수 있게 되었습니다.

데이터 타입 변경에 따른 영향을 확인하기 위해 다음 스크립트를 실행합니다:

✅ Verification successful

데이터 타입 변경이 일관되게 적용되었습니다.

Store 엔티티와 관련 DTO들에서 영업 시간과 요일 관련 필드들이 모두 동일한 타입으로 일관되게 구현되어 있습니다:

• List<DayOfWeek> 타입이 Store 엔티티(workDays)와 모든 DTO들(dayOfWeek)에서 사용됨
• LocalTime 타입이 Store 엔티티와 모든 DTO들의 openTime, closeTime 필드에서 사용됨
• Store 엔티티에서는 추가로 @JsonFormat 어노테이션을 통해 시간 포맷도 적절히 지정되어 있음

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Store 엔티티와 관련 DTO들에서 시간과 요일 관련 필드의 타입이 일관되게 변경되었는지 확인

# Store 엔티티 확인
rg "class Store" -A 20

# 관련 DTO 클래스들 확인
fd -e java -x rg "class.*RequestDTO|class.*ResponseDTO" -A 20 {}

Length of output: 16856

---

Script:

#!/bin/bash
# Store 엔티티에서 영업 시간과 요일 관련 필드 확인
rg "class Store" -A 50 src/main/java/com/jangburich/domain/store/domain/Store.java

# Store 엔티티의 메서드에서 DayOfWeek와 LocalTime 사용 확인
ast-grep --pattern 'class Store {
  $$$
  private List<DayOfWeek> $_ = $$$;
  $$$
}'

ast-grep --pattern 'class Store {
  $$$
  private LocalTime $_ = $$$;
  $$$
}'

Length of output: 1416

---

Script:

#!/bin/bash
# Store 엔티티의 전체 내용 확인
cat src/main/java/com/jangburich/domain/store/domain/Store.java

# Store 엔티티의 영업시간 관련 필드 검색
rg "openTime|closeTime|dayOfWeek" src/main/java/com/jangburich/domain/store/domain/Store.java

Length of output: 3641

---

79-81: of 메서드의 매핑이 적절히 수정되었습니다.

store.getWorkDays()를 사용하여 영업일 정보를 가져오도록 변경된 것이 적절합니다.

Store 클래스에 getWorkDays 메서드가 올바르게 구현되어 있는지 확인하기 위해 다음 스크립트를 실행합니다:

✅ Verification successful

Let me search for the implementation of the getter method for work days in the Store class. The previous search didn't show the complete Store class implementation.

---

이전 검색에서 setWorkDays 메서드는 발견했지만, 해당하는 getter 메서드와 필드 선언을 확인하기 위해 Store 클래스의 더 많은 부분을 살펴보겠습니다.

---

@ElementCollection으로 work_days 테이블과 매핑된 필드를 발견했습니다. 이제 해당 필드의 getter 메서드 구현을 확인하겠습니다.

---

필드는 존재하지만 getter 메서드가 명시적으로 보이지 않습니다. Lombok 어노테이션을 통해 자동 생성되었을 수 있으므로 확인해보겠습니다.

---

Store 클래스의 getWorkDays() 메서드가 올바르게 구현되어 있습니다.

Store 클래스에 @Getter 어노테이션이 적용되어 있고, private List<DayOfWeek> workDays 필드가 정의되어 있어 Lombok에 의해 getWorkDays() 메서드가 자동으로 생성됩니다. 따라서 StoreGetResponseDTO에서 store.getWorkDays()를 호출하는 것이 적절합니다.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Store 클래스에서 getWorkDays 메서드 구현 확인
ast-grep --pattern 'class Store {
  $$$
  getWorkDays() {
    $$$
  }
  $$$
}'

Length of output: 16856

---

Script:

#!/bin/bash
# Store 클래스에서 getWorkDays 메서드 구현 확인
rg "getWorkDays|getDayOfWeek" -A 3 src/main/java/com/jangburich/domain/store/domain/Store.java

Length of output: 353

---

Script:

#!/bin/bash
# Store 클래스의 전체 필드와 메서드 확인
rg "class Store" -A 50 src/main/java/com/jangburich/domain/store/domain/Store.java

Length of output: 1248

---

Script:

#!/bin/bash
# Store 클래스의 workDays 필드와 getter 메서드 확인
rg "@ElementCollection.*work_days" -A 5 src/main/java/com/jangburich/domain/store/domain/Store.java

# getter 메서드 확인
rg "get.*WorkDays|get.*DayOfWeek" src/main/java/com/jangburich/domain/store/domain/Store.java

Length of output: 310

---

Script:

#!/bin/bash
# Store 클래스의 workDays 관련 모든 코드 확인
rg "workDays|dayOfWeek" -B 2 -A 2 src/main/java/com/jangburich/domain/store/domain/Store.java

# Lombok 어노테이션 확인
rg "@Getter|@Data|@Accessors" src/main/java/com/jangburich/domain/store/domain/Store.java

Length of output: 422

src/main/java/com/jangburich/domain/store/domain/controller/StoreController.java (1)

13-13: 새로운 DTO 임포트가 적절히 추가되었습니다.

새로운 기능을 위한 StoreAdditionalInfoCreateRequestDTO 임포트가 올바르게 추가되었습니다.

src/main/java/com/jangburich/domain/store/domain/Store.java (1)

3-6: 필요한 import 문이 적절히 추가되었습니다.

시간 및 컬렉션 처리를 위한 import 문이 올바르게 추가되었습니다.

src/main/java/com/jangburich/domain/oauth/domain/service/OAuthUserService.java (1)

Line range hint 79-109: 기존 사용자에 대한 영향을 확인해주세요.

역할 검증 로직이 변경됨에 따라 기존 사용자들의 권한 전환 시나리오에 대한 검증이 필요합니다.

다음 스크립트를 실행하여 기존 사용자들의 권한 상태를 확인해주세요:

✅ Verification successful

권한 전환 로직이 안전하게 구현되어 있습니다.

코드베이스 분석 결과, 다음과 같은 이유로 기존 사용자들의 권한 전환이 안전하게 처리되고 있습니다:

• 사용자가 존재하지 않거나 ROLE_OWNER 권한이 없는 경우에만 새로운 Owner 계정이 생성됩니다.
• 기존 Owner 사용자의 경우 프로필 정보만 업데이트되며 권한은 변경되지 않습니다.
• Owner와 User 엔티티 간의 관계가 명확하게 정의되어 있어 데이터 일관성이 보장됩니다.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: 기존 사용자들의 권한 상태 확인

# User 엔티티에서 ROLE_OWNER 권한을 가진 사용자 조회
ast-grep --pattern 'class User {
  $$$
  private String role;
  $$$
}'

# Owner 엔티티와 User 엔티티의 연관관계 확인
ast-grep --pattern 'class Owner {
  $$$
  private User user;
  $$$
}'

Length of output: 144

---

Script:

#!/bin/bash
# Search for User class implementation
rg -U "class User" -A 20

# Search for Owner class implementation
rg -U "class Owner" -A 20

# Search for role-related methods in User class
rg -U "getRole|setRole" -A 3

# Search for user relationship methods in Owner class
rg -U "getUser|setUser" -A 3

# Search for role-related database operations
rg -U "ROLE_OWNER" -A 3

Length of output: 28244

[coderabbitai]

🛠️ Refactor suggestion

Lombok 어노테이션 개선이 필요합니다.

@RequiredArgsConstructor는 final 필드나 @NonNull이 지정된 필드에 대해서만 생성자를 생성합니다. 현재 클래스에는 해당되는 필드가 없으므로 @NoArgsConstructor나 @AllArgsConstructor를 사용하는 것이 더 적절할 것 같습니다.

다음과 같이 수정을 제안드립니다:

@Getter
@Setter
-@RequiredArgsConstructor
+@AllArgsConstructor
+@NoArgsConstructor

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	@Getter
	@Setter
	@RequiredArgsConstructor
	@Getter
	@Setter
	@AllArgsConstructor
	@NoArgsConstructor

[coderabbitai]

⚠️ Potential issue

필드 유효성 검증이 필요합니다.

예약 및 결제 관련 필드에 대한 유효성 검증이 없습니다. 잘못된 데이터가 입력될 수 있는 위험이 있습니다.

다음과 같은 제약조건 추가를 제안드립니다:

+import javax.validation.constraints.Min;
+import javax.validation.constraints.NotNull;

public class StoreAdditionalInfoCreateRequestDTO {
-    private Boolean reservationAvailable;
-    private Long maxReservation;
-    private Long minPrepayment;
-    private Long prepaymentDuration;
+    @NotNull(message = "예약 가능 여부는 필수 입력값입니다")
+    private Boolean reservationAvailable;
+    
+    @Min(value = 1, message = "최대 예약 가능 인원은 1명 이상이어야 합니다")
+    private Long maxReservation;
+    
+    @Min(value = 0, message = "최소 선결제 금액은 0원 이상이어야 합니다")
+    private Long minPrepayment;
+    
+    @Min(value = 0, message = "선결제 유효 기간은 0분 이상이어야 합니다")
+    private Long prepaymentDuration;

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	private Boolean reservationAvailable;
	private Long maxReservation;
	private Long minPrepayment;
	private Long prepaymentDuration;
	import javax.validation.constraints.Min;
	import javax.validation.constraints.NotNull;
	public class StoreAdditionalInfoCreateRequestDTO {
	@NotNull(message = "예약 가능 여부는 필수 입력값입니다")
	private Boolean reservationAvailable;
	@Min(value = 1, message = "최대 예약 가능 인원은 1명 이상이어야 합니다")
	private Long maxReservation;
	@Min(value = 0, message = "최소 선결제 금액은 0원 이상이어야 합니다")
	private Long minPrepayment;
	@Min(value = 0, message = "선결제 유효 기간은 0분 이상이어야 합니다")
	private Long prepaymentDuration;

[coderabbitai]

💡 Codebase verification

유효성 검증 로직 추가가 필요합니다.

현재 코드베이스에서 StoreUpdateRequestDTO의 시간과 요일 데이터에 대한 유효성 검증이 누락되어 있습니다. 다음 사항들의 구현이 필요합니다:

• @NotNull, @Valid 등의 Bean Validation 어노테이션 추가
• dayOfWeek 리스트의 중복 및 null 체크
• openTime이 closeTime보다 이후인 경우에 대한 비즈니스 로직 검증

🔗 Analysis chain

필드 타입 변경이 적절하나 유효성 검증이 필요합니다.

시간과 요일 데이터를 더 적절한 타입으로 변경한 것은 좋은 개선입니다. 다만 다음 사항들을 고려해주세요:

1. dayOfWeek 리스트가 비어있거나 중복된 요일이 있는 경우 처리
2. openTime이 closeTime보다 이후인 경우 처리

---

Let me gather more information about validation annotations and service layer validation.

---

Let me try one more search to find validation-related code in the repository structure:

---

Let me check the StoreService implementation for any validation logic:

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: 유효성 검증 로직 확인

# Store 엔티티나 서비스 레이어에서 유효성 검증 확인
rg -A 10 "dayOfWeek|openTime|closeTime.*valid"

# Bean Validation 어노테이션 사용 확인
ast-grep --pattern 'class StoreUpdateRequestDTO {
  $$$
  @NotNull
  $$$
}'

Length of output: 5343

---

Script:

#!/bin/bash
# Check for validation annotations in StoreUpdateRequestDTO
rg -B 2 -A 2 "@.*null|@Size|@Valid|@Pattern|@Min|@Max" src/main/java/com/jangburich/domain/store/domain/StoreUpdateRequestDTO.java

# Check service layer validation for store times
rg -A 10 "update.*Store|save.*Store" src/main/java/com/jangburich/domain/store/service/

# Check if there's any custom validation for business hours
rg -A 5 "validateBusinessHours|validateDayOfWeek|validate.*Time" 

Length of output: 380

---

Script:

#!/bin/bash
# Find all service and validator files
fd -e java service
fd -e java validator

# Check for any validation annotations in Store related files
rg -B 2 -A 2 "@.*null|@Size|@Valid|@Pattern|@Min|@Max" $(fd -e java store)

Length of output: 1581

---

Script:

#!/bin/bash
# Check StoreService implementation
cat src/main/java/com/jangburich/domain/store/domain/service/StoreService.java

# Check StoreController for any validation annotations
cat src/main/java/com/jangburich/domain/store/domain/controller/StoreController.java

Length of output: 9286

[coderabbitai]

🛠️ Refactor suggestion

메서드 네이밍 컨벤션 및 유효성 검사 개선이 필요합니다.

다음 사항들을 개선해 주시기 바랍니다:

1. CreateAdditionalInfo 메서드명이 Java 네이밍 컨벤션을 따르지 않습니다. 메서드명은 소문자로 시작해야 합니다.
2. DTO에 유효성 검사 어노테이션이 누락되었습니다.

다음과 같이 수정을 제안드립니다:

- storeService.CreateAdditionalInfo(customOAuthUser, storeAdditionalInfoCreateRequestDTO);
+ storeService.createAdditionalInfo(customOAuthUser, storeAdditionalInfoCreateRequestDTO);

그리고 DTO 클래스에 다음과 같은 유효성 검사를 추가해 주세요:

public class StoreAdditionalInfoCreateRequestDTO {
    @NotNull(message = "예약 가능 여부는 필수입니다")
    private Boolean reservationAvailable;
    
    @Min(value = 0, message = "최소 선결제 금액은 0 이상이어야 합니다")
    private Integer minPrepayment;
    
    // 기타 필드에 대한 유효성 검사 추가
}

[coderabbitai]

🛠️ Refactor suggestion

메서드 명명 규칙을 일관성 있게 적용하세요

Java에서는 메서드 이름을 소문자로 시작하는 카멜 케이스를 사용하는 것이 관례입니다. CreateStore와 CreateAdditionalInfo 메서드를 각각 createStore와 createAdditionalInfo로 변경하여 다른 메서드들과 명명 규칙을 일관성 있게 유지하는 것이 좋습니다.

Also applies to: 42-43