[feat] 알림센터 조회 api 개발 #305
Conversation
- 알림 카테고리 컬럼 추가
- 적절한 notification category 값을 직접 주입하도록 수정
- jpa <-> domain 엔티티의 매핑과정에서 notification category 필드 값의 매핑 추가
- NotificationQueryDto <-> response 매퍼 추가
- application/port/in/dto 의 MyRoomType enum 을 메서드 파라미터로 설정함으로써 service 내부에서 MyRoomType 검증과정 삭제
Walkthrough알림 카테고리(NotificationCategory) 추가와 카테고리 기반 커서 페이징 알림 조회 기능이 도입되었고, 관련 포트/레포지토리/매퍼/서비스/컨트롤러/DTO 및 DB 마이그레이션과 테스트가 추가되었으며 일부 FCM 관련 타입과 서비스 패키지 위치가 재배치되었습니다. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor U as User
participant C as NotificationQueryController
participant S as NotificationShowService
participant P as NotificationQueryPort
participant R as NotificationQueryRepositoryImpl
participant M as NotificationQueryMapper
U->>C: GET /notifications?type={feed|room|feedAndRoom}&cursor=...
C->>S: showNotifications(userId, cursorStr, NotificationType)
S->>S: Cursor.from(cursorStr, PAGE_SIZE)
alt FEED | ROOM | FEED_AND_ROOM
S->>P: find{Category}NotificationsByUserId(userId, cursor)
end
P->>R: query(lastNotificationId, pageSize+1)
R-->>P: List<NotificationQueryDto>
P-->>S: CursorBasedList(contents,nextCursor,hasNext)
S->>M: toNotificationOfUsers(contents)
M-->>S: List<NotificationOfUser>
S-->>C: NotificationShowResponse(notifications,nextCursor,isLast)
C-->>U: 200 OK
sequenceDiagram
autonumber
actor U as User
participant RC as RoomQueryController
participant RS as RoomShowMineService
U->>RC: GET /rooms/mine?type={...}&cursor=...
RC->>RC: MyRoomType.from(type)
RC->>RS: getMyRooms(userId, MyRoomType, cursor)
RS->>RS: Cursor.from(cursor, PAGE_SIZE)
alt MyRoomType 분기
RS->>RS: 포트 호출 (recruiting/playing/playing+recruiting/expired)
end
RS-->>RC: RoomShowMineResponse
RC-->>U: 200 OK
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests
Tip 👮 Agentic pre-merge checks are now available in preview!Pro plan users can now enable pre-merge checks in their settings to enforce checklists before merging PRs.
Please see the documentation for more information. Example: reviews:
pre_merge_checks:
custom_checks:
- name: "Undocumented Breaking Changes"
mode: "warning"
instructions: |
Pass/fail criteria: All breaking changes to public APIs, CLI flags, environment variables, configuration keys, database schemas, or HTTP/GraphQL endpoints must be documented in the "Breaking Change" section of the PR description and in CHANGELOG.md. Exclude purely internal or private changes (e.g., code not exported from package entry points or explicitly marked as internal).Please share your feedback with us on this Discord post. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Test Results474 tests 474 ✅ 45s ⏱️ Results for commit a688492. ♻️ This comment has been updated with latest results. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/main/java/konkuk/thip/notification/application/service/template/room/RoomRecordCreatedTemplate.java (1)
11-11: 레코드 필드 접근 오타로 인한 컴파일 오류Java record 접근자는 메서드입니다.
args.roomTitle→args.roomTitle()로 수정 필요.아래 패치 적용:
- return NotificationCategory.ROOM.prefixedTitle(args.roomTitle); + return NotificationCategory.ROOM.prefixedTitle(args.roomTitle());
♻️ Duplicate comments (2)
src/test/java/konkuk/thip/notification/adapter/in/web/NotificationShowApiTest.java (2)
105-115: 동일: 마지막 페이지의 nextCursor 비노출 검증 추가feed 케이스와 동일하게 보강해 주세요.
result.andExpect(status().isOk()) .andExpect(jsonPath("$.data.notifications", hasSize(2))) .andExpect(jsonPath("$.data.isLast").value(true)) + .andExpect(jsonPath("$.data.nextCursor").doesNotExist())
151-167: 동일: 마지막 페이지의 nextCursor 비노출 검증 추가type=null 통합 목록도 동일 계약을 보장하는 것이 좋습니다.
result.andExpect(status().isOk()) .andExpect(jsonPath("$.data.notifications", hasSize(4))) .andExpect(jsonPath("$.data.isLast").value(true)) + .andExpect(jsonPath("$.data.nextCursor").doesNotExist())
🧹 Nitpick comments (50)
src/main/java/konkuk/thip/room/application/service/RoomShowMineService.java (1)
54-63: 시간 의존 로직의 테스트 결정성 확보 및 디버그 코드 정리
LocalDate.now()직접 호출은 테스트에서 비결정성을 유발합니다.Clock주입을 권장합니다.- 주석 처리된
System.out.println은 제거하세요.- 또한, startDate가 “오늘”인 경우를 PLAYING으로 분류(
isAfter(now)만 체크)하는 비즈니스 규칙이 맞는지 확인 바랍니다.적용 예시(diff):
package konkuk.thip.room.application.service; @@ import org.springframework.transaction.annotation.Transactional; -import java.time.LocalDate; +import java.time.Clock; +import java.time.LocalDate; @@ public class RoomShowMineService implements RoomShowMineUseCase { @@ private final RoomQueryPort roomQueryPort; private final RoomQueryMapper roomQueryMapper; + private final Clock clock; @@ - LocalDate now = LocalDate.now(); + LocalDate now = LocalDate.now(clock); -// System.out.println("dto.startDate() = " + dto.startDate()); -// System.out.println("dto.endDate() = " + dto.endDate()); - if (dto.startDate() != null && dto.startDate().isAfter(now)) { return roomQueryMapper.toShowMyRoomResponse(dto, MyRoomType.RECRUITING); // 모집중인 방 } else { return roomQueryMapper.toShowMyRoomResponse(dto, MyRoomType.PLAYING); // 진행중인 방 }
- Clock 주입 시 구성:
@Configuration에서@Bean Clock systemClock() { return Clock.systemDefaultZone(); }추가 여부 확인 부탁드립니다.src/main/java/konkuk/thip/room/application/port/in/RoomShowMineUseCase.java (1)
4-8: MyRoomType 도입으로 타입 안정성 향상 — null 방지 애노테이션 추가 권장
- enum 파라미터 도입은 👍. 다만 인터페이스 레벨에서
@NotNull로 계약을 명시해 두면 호출 측 실수 방지 및 정적 분석에 유리합니다.적용 예시(diff):
package konkuk.thip.room.application.port.in; import konkuk.thip.room.adapter.in.web.response.RoomShowMineResponse; import konkuk.thip.room.application.port.in.dto.MyRoomType; +import jakarta.validation.constraints.NotNull; public interface RoomShowMineUseCase { - RoomShowMineResponse getMyRooms(Long userId, MyRoomType myRoomType, String cursor); + RoomShowMineResponse getMyRooms(Long userId, @NotNull MyRoomType myRoomType, String cursor); }변경 시그니처가 전역에 반영됐는지 확인 스크립트:
#!/bin/bash # getMyRooms 호출부와 enum 전달 여부를 점검 rg -nP -C2 '\bgetMyRooms\s*\('src/main/java/konkuk/thip/room/adapter/in/web/RoomQueryController.java (1)
131-137: String→enum 수동 변환 대신, RequestParam을 MyRoomType으로 직접 바인딩 권장
- Spring이 enum 바인딩을 기본 지원하므로 수동
from()변환과 예외 처리를 없애 코드 단순화/문서화가 가능합니다.- 이 방식은 유효하지 않은 값에 대해 자동으로 400(Bad Request)을 리턴합니다.
적용 예시(diff):
@GetMapping("/rooms/my") public BaseResponse<RoomShowMineResponse> getMyRooms( @Parameter(hidden = true) @UserId final Long userId, - @Parameter(description = "조회할 방의 타입 (playingAndRecruiting: 진행중인 방과 모집중인 방, recruiting: 모집중인 방만, playing: 진행중인 방만, expired: 만료된 방만)", example = "playingAndRecruiting") - @RequestParam(value = "type", required = false, defaultValue = "playingAndRecruiting") final String type, + @Parameter(description = "조회할 방의 타입 (PLAYING_AND_RECRUITING | RECRUITING | PLAYING | EXPIRED)", example = "PLAYING_AND_RECRUITING") + @RequestParam(value = "type", required = false, defaultValue = "PLAYING_AND_RECRUITING") final MyRoomType myRoomType, @Parameter(description = "커서 (첫번째 요청시 : null, 다음 요청시 : 이전 요청에서 반환받은 nextCursor 값)") @RequestParam(value = "cursor", required = false) final String cursor) { - return BaseResponse.ok(roomShowMineUseCase.getMyRooms(userId, MyRoomType.from(type), cursor)); + return BaseResponse.ok(roomShowMineUseCase.getMyRooms(userId, myRoomType, cursor)); }
MyRoomType.from(String)를 유지해야 한다면, 잘못된 값 입력 시 어떤 예외/HTTP 상태를 내리는지 확인 부탁드립니다. from 구현 확인:#!/bin/bash fd MyRoomType.java | xargs -I{} sh -c 'echo "== {} =="; sed -n "1,200p" "{}" | nl | sed -n "1,200p" | rg -n "enum|from\\(" -n -C3'src/main/java/konkuk/thip/common/swagger/SwaggerResponseDescription.java (1)
376-378: 주석 오타 정정 제안Line 358의 주석 "Notiification" → "Notification".
src/main/java/konkuk/thip/notification/application/service/fcm/FcmRegisterService.java (1)
21-46: 동시 등록 경쟁 대비(유니크 제약 + 업서트/리트라이 권장)동일 deviceId로 동시 요청 시 else-브랜치 두 번 진입해 중복 insert 가능성이 있습니다. DB에 device_id 유니크 인덱스를 두고, save 시 제약 위반(DataIntegrityViolationException) 발생 시 find→update로 폴백하는 패턴을 권장합니다.
예시(diff):
@@ - public void registerToken(FcmTokenRegisterCommand command) { + public void registerToken(FcmTokenRegisterCommand command) { // 같은 디바이스로 등록된 토큰이 있는지 확인 fcmTokenPersistencePort.findByDeviceId(command.deviceId()).ifPresentOrElse( existingToken -> { @@ - () -> { - // 없으면 새로 등록 - fcmTokenPersistencePort.save(FcmToken.withoutId( + () -> { + // 없으면 새로 등록(동시성 대비: 유니크 제약 위반 시 갱신 폴백) + try { + fcmTokenPersistencePort.save(FcmToken.withoutId( command.fcmToken(), command.deviceId(), command.platformType(), - LocalDate.now(), + LocalDate.now(), true, command.userId() - )); + )); + } catch (org.springframework.dao.DataIntegrityViolationException e) { + fcmTokenPersistencePort.findByDeviceId(command.deviceId()) + .ifPresent(t -> { + t.updateToken(command.fcmToken(), command.platformType(), LocalDate.now(), command.userId()); + fcmTokenPersistencePort.update(t); + }); + } } ); }또한 테스트 가능성과 시간 정밀도를 위해 Clock 주입을 추천합니다.
@@ -import java.time.LocalDate; +import java.time.Clock; +import java.time.LocalDate; @@ -@RequiredArgsConstructor +@RequiredArgsConstructor public class FcmRegisterService implements FcmRegisterUseCase { @@ - private final FcmTokenPersistencePort fcmTokenPersistencePort; + private final FcmTokenPersistencePort fcmTokenPersistencePort; + private final Clock clock; @@ - LocalDate.now(), + LocalDate.now(clock), @@ - LocalDate.now(), + LocalDate.now(clock),src/main/java/konkuk/thip/common/exception/code/ErrorCode.java (1)
228-232: 커서 기반 조회의 입력 검증 코드도 별도 에러코드로 노출할지 검토현재 NOTIFICATION_SHOW는 타입 오류만 노출합니다. 필요 시 2050xx 대역에 INVALID_NOTIFICATION_CURSOR(예: 음수/0/비정상 포맷) 등을 두고 Swagger에 포함하면 클라이언트 디버깅이 수월합니다. 유지보수 단순화를 위해 현행(API_INVALID_PARAM 재사용) 유지도 괜찮습니다.
중복 코드값 존재 여부를 빠르게 점검하려면 아래 실행:
#!/bin/bash rg -nP '^\s*[A-Z0-9_]+\s*\(HttpStatus\.[A-Z_]+,\s*(\d{5}),\s*".*"\)' src/main/java/konkuk/thip/common/exception/code/ErrorCode.java \ | gawk '{print $0; match($0, /, ([0-9]{5}),/, m); if (m[1]!="") print m[1] > "/tmp/_codes"; } END { }' sort /tmp/_codes | uniq -d | sed 's/^/DUPLICATE_CODE: /'src/main/resources/db/migration/V250916__Add_notification_category.sql (1)
1-14: 카테고리 컬럼 추가 LGTM + 키셋 페이지네이션용 인덱스/제약 제안
- 현재 VARCHAR(16) NOT NULL 전략은 실용적입니다. 가능하면 카테고리 유효성 보강(체크 제약 또는 ENUM)과 조회 인덱스를 함께 추가하는 것을 권장합니다.
권장 DDL(후속 마이그레이션 권장):
-- 유효값 제약(MySQL 8.0.16+에서만 강제) ALTER TABLE notifications ADD CONSTRAINT chk_notifications_category CHECK (notification_category IN ('FEED','ROOM')); -- 키셋 페이지네이션 최적화: 사용자별/카테고리별 최신순 CREATE INDEX idx_notif_user_cat_id ON notifications (user_id, notification_category, notification_id);PK 커서를 쓰는 현재 설계는 최신순 안정성과 인덱스 효율 측면에서 적절합니다. 조건은 다음이 만족되어야 합니다:
- WHERE notification_id < :cursor
- ORDER BY notification_id DESC
- 필요 시 AND user_id = :uid [AND notification_category = :cat]
쿼리 구현을 빠르게 확인하려면:
#!/bin/bash rg -nP -C3 '(NotificationQueryRepositoryImpl|NotificationQueryRepository)' src/main/java rg -nP -C2 'ORDER\s+BY\s+.*notification_id\s+DESC' src/main/java rg -nP -C2 '\bnotification_id\s*<\s*:' src/main/javasrc/main/java/konkuk/thip/notification/application/service/template/room/RoomPostLikedTemplate.java (1)
19-22: 카테고리 메서드 구현 LGTM. Args 미사용 — 중복 제거 여지 있습니다.여기서는 Args를 사용하지 않으므로 공통 default 구현으로 중복 제거 가능해 보입니다. 인터페이스 측 리팩토링 제안을 NotificationTemplate 코멘트에 남겼습니다(선택).
src/main/java/konkuk/thip/notification/application/service/template/feed/FolloweeNewPostTemplate.java (1)
19-22: 카테고리 메서드 구현 LGTM. Args 미사용 — 공통화 고려 가능.반복되는 패턴이라 default 구현 혹은 보조 인터페이스로 흡수하면 템플릿 전반의 보일러플레이트를 줄일 수 있습니다(아래 NotificationTemplate 제안 참고).
src/main/java/konkuk/thip/notification/application/service/template/room/RoomVoteStartedTemplate.java (1)
19-22: 카테고리 지정 적절. Args 미사용 리팩토링 여지.동일 패턴 반복이므로 공통 인터페이스로의 추출을 권장합니다(선택).
src/main/java/konkuk/thip/notification/application/service/template/room/RoomJoinToHostTemplate.java (1)
19-22: LGTM.Args 파라미터를 사용하지 않는 동일 패턴이라 공통화로 보일러플레이트를 줄일 수 있습니다.
src/main/java/konkuk/thip/notification/application/service/template/feed/FeedLikedTemplate.java (1)
19-22: LGTM + 소폭 리팩토링 제안
- Args 미사용 패턴은 공통화 여지가 있습니다(인터페이스 코멘트 참고).
- 문구 톤/어미는 타 템플릿과의 일관성 점검을 가볍게 권장합니다(다음 PR에서도 OK).
src/main/java/konkuk/thip/notification/application/service/template/room/RoomActivityStartedTemplate.java (1)
19-22: 카테고리 지정 LGTM.Args 미사용이라 default 구현 도입 시 제거 대상입니다(선택).
src/main/java/konkuk/thip/notification/application/service/template/NotificationTemplate.java (1)
3-12: notificationCategory(T args) 설계: 파라미터 미사용 → 보일러플레이트 제거 가능한 보조 인터페이스 제안대부분의 템플릿에서 args를 사용하지 않고 상수 카테고리를 반환하므로, 아래와 같이 “고정 카테고리” 보조 인터페이스를 도입하면 각 템플릿의 중복 오버라이드를 제거할 수 있습니다(현재 API와 호환, 점진 도입 가능).
- 제안: FixedCategoryTemplate 추가 + default 구현 제공.
- 효과: 템플릿마다 notificationCategory 오버라이드 삭제 가능, 실수 여지 감소.
추가 파일(신규):
// src/main/java/konkuk/thip/notification/application/service/template/FixedCategoryTemplate.java package konkuk.thip.notification.application.service.template; import konkuk.thip.notification.domain.value.NotificationCategory; public interface FixedCategoryTemplate<T> extends NotificationTemplate<T> { NotificationCategory fixedCategory(); @Override default NotificationCategory notificationCategory(T args) { return fixedCategory(); } }적용 예시(한 템플릿 샘플):
- public enum FeedLikedTemplate implements NotificationTemplate<FeedLikedTemplate.Args> { + public enum FeedLikedTemplate implements FixedCategoryTemplate<FeedLikedTemplate.Args> { INSTANCE; @@ - @Override - public NotificationCategory notificationCategory(Args args) { - return NotificationCategory.FEED; - } + @Override + public NotificationCategory fixedCategory() { return NotificationCategory.FEED; }대안(차기 PR 고려): 메서드 시그니처에서 파라미터 제거
- NotificationCategory notificationCategory(T args); + NotificationCategory notificationCategory();(이는 파급면이 커서 보조 인터페이스 방식이 더 안전합니다.)
src/main/java/konkuk/thip/notification/application/service/template/room/RoomPostCommentRepliedTemplate.java (1)
19-22: ROOM 카테고리 매핑 OK템플릿 성격과 일치합니다. 추가 조치 없음.
작은 제안: args를 사용하지 않으므로 파라미터명을 관례적으로 ignored로 바꾸면 의도가 더 분명합니다.
적용 예:
- public NotificationCategory notificationCategory(Args args) { + public NotificationCategory notificationCategory(Args ignored) { return NotificationCategory.ROOM; }src/main/java/konkuk/thip/notification/application/service/template/room/RoomCommentLikedTemplate.java (1)
19-22: ROOM 카테고리 매핑 OK일관성 있게 ROOM을 반환합니다.
사소한 가독성: 사용하지 않는 파라미터명은 ignored로 변경 권장.
- public NotificationCategory notificationCategory(Args args) { + public NotificationCategory notificationCategory(Args ignored) { return NotificationCategory.ROOM; }src/main/java/konkuk/thip/notification/application/service/template/room/RoomPostCommentedTemplate.java (1)
19-22: ROOM 카테고리 매핑 OK구현 간결하고 일관적입니다.
사소 제안: 미사용 파라미터명을 ignored로.
- public NotificationCategory notificationCategory(Args args) { + public NotificationCategory notificationCategory(Args ignored) { return NotificationCategory.ROOM; }src/main/java/konkuk/thip/notification/application/service/template/feed/FollowedTemplate.java (1)
7-9: 불필요한 Lombok @Getter 제거 제안해당 enum에 필드가 없어 @Getter가 효과가 없습니다. 불필요 의존을 줄이기 위해 제거 권장.
-import lombok.Getter; - -@Getter +// @Getter 제거: 노출할 필드 없음src/main/java/konkuk/thip/notification/application/service/template/room/RoomRecruitClosedEarlyTemplate.java (1)
15-16: 템플릿명과 메시지 내용 불일치 가능성 확인 요청템플릿명은 "RecruitClosedEarly"인데 메시지는 "활동 시작" 알림입니다. 도메인 의도와 맞는지 확인 바랍니다. 만약 조기 마감 알림이라면 메시지/타이틀 문구 재검토 필요.
src/test/java/konkuk/thip/notification/application/service/NotificationSyncExecutorTest.java (1)
31-32: 테스트 템플릿의 카테고리 구현 추가 적절새 인터페이스 계약을 충족합니다.
보강 제안: 저장된 Notification에 카테고리가 정확히 반영됐는지도 단언문을 추가하면 회귀를 더 잘 잡을 수 있습니다(메서드명이
getNotificationCategory()또는getCategory()인지 코드베이스에 맞춰 사용).예시:
assertThat(saved.getNotificationCategory()).isEqualTo(NotificationCategory.FEED);또는
assertThat(saved.getCategory()).isEqualTo(NotificationCategory.FEED);src/main/java/konkuk/thip/notification/application/service/template/feed/FeedCommentedTemplate.java (1)
19-22: FEED 카테고리 매핑 OK다른 FEED 템플릿들과 일관적입니다.
사소 제안: 미사용 파라미터명은 ignored로 표현하면 의도 전달이 명확합니다.
- public NotificationCategory notificationCategory(Args args) { + public NotificationCategory notificationCategory(Args ignored) { return NotificationCategory.FEED; }src/main/java/konkuk/thip/notification/adapter/out/persistence/function/PrimaryKeyNotificationQueryFunction.java (1)
7-11: 초기 페이지(cursor null) 의미를 문서화하고 Nullable 명시 제안
lastNotificationId가 null이면 첫 페이지로 해석하는 계약을 자바독/애노테이션으로 명확히 해두면 유지보수성이 좋아집니다.적용 예시:
package konkuk.thip.notification.adapter.out.persistence.function; import konkuk.thip.notification.application.port.out.dto.NotificationQueryDto; +import org.springframework.lang.Nullable; import java.util.List; @FunctionalInterface public interface PrimaryKeyNotificationQueryFunction { - List<NotificationQueryDto> apply(Long lastNotificationId, int pageSize); + /** + * @param lastNotificationId 첫 페이지인 경우 null + * @param pageSize 페이지 크기(>0) + * @return 현재 페이지 결과(정렬: notification_id DESC 권장) + */ + List<NotificationQueryDto> apply(@Nullable Long lastNotificationId, int pageSize); }src/main/java/konkuk/thip/notification/application/port/in/NotificationShowUseCase.java (1)
8-9: 커서 타입을 Long으로 받는 오버로드(디폴트 메서드) 추가 제안파싱 책임을 컨트롤러/서비스에 분산시키지 않기 위해,
Long커서를 직접 받는 오버로드를 제공하면 내부 일관성이 좋아집니다. 기존 시그니처는 유지 가능합니다.다음과 같이 디폴트 메서드를 추가해 보세요:
public interface NotificationShowUseCase { - NotificationShowResponse showNotifications(Long userId, String cursorStr, NotificationType notificationType); + NotificationShowResponse showNotifications(Long userId, String cursorStr, NotificationType notificationType); + + default NotificationShowResponse showNotifications(Long userId, Long lastNotificationId, NotificationType notificationType) { + return showNotifications(userId, lastNotificationId == null ? null : String.valueOf(lastNotificationId), notificationType); + } }이 변경이 컨트롤러/테스트와 충돌 없는지 빌드 확인 부탁드립니다.
src/test/java/konkuk/thip/common/util/TestEntityFactory.java (1)
376-384: 테스트 페이징 안정성 확보를 위한 생성 유틸 보강 제안현재 생성 시
createdAt은 감사 필드로 자동 세팅되어, 다건 삽입 시 타임스탬프가 동일할 수 있습니다. 커서가 PK인데 정렬이createdAt DESC라면 테스트가 비결정적이 될 수 있습니다. 대안:
- 테스트 쿼리를
notification_id DESC정렬로 통일- 혹은 팩토리에서 알림 간 약간의 시차를 두거나(권장하지 않음), 생성 유틸에
isChecked/content등 커스터마이즈 오버로드를 추가하여 시나리오 다양화간단 오버로드 추가 예:
public static NotificationJpaEntity createNotification(UserJpaEntity user, String title, NotificationCategory category) { return NotificationJpaEntity.builder() .title(title) .content("알림 내용") .isChecked(false) .notificationCategory(category) .userJpaEntity(user) .build(); } +public static NotificationJpaEntity createNotification(UserJpaEntity user, String title, NotificationCategory category, boolean isChecked) { + return NotificationJpaEntity.builder() + .title(title) + .content("알림 내용") + .isChecked(isChecked) + .notificationCategory(category) + .userJpaEntity(user) + .build(); +}리포지토리 Impl 정렬 컬럼과 테스트 기대 정렬이 일치하는지 확인 부탁드립니다.
src/main/java/konkuk/thip/notification/adapter/out/jpa/NotificationJpaEntity.java (1)
30-33: 카테고리 필드 추가 LGTM + 운영 인덱스 제안
- Enum STRING 매핑/NotNull 제약 적절합니다.
- 운영 성능을 위해 다음 인덱스를 권장합니다(마이그레이션에서 처리 권장):
- (user_id, notification_id) 또는 (user_id, notification_category, notification_id)
- 정렬이
createdAt이면 (user_id, created_at DESC, notification_id DESC) 계열또한 기존 데이터에 대해
notification_category초기값 backfill이 되었는지 확인 바랍니다(Non‑Null 제약).마이그레이션에 인덱스/백필이 포함되어 있는지 확인할 수 있도록 스크립트 실행을 부탁드립니다(리포지토리 루트에서):
#!/bin/bash fd -t f -g 'V*__*.sql' | xargs -I{} sh -c "echo '--- {} ---'; rg -n -C2 'notifications|notification_category|INDEX|CONSTRAINT|DEFAULT|UPDATE' {}"src/main/java/konkuk/thip/notification/application/service/NotificationSyncExecutor.java (2)
26-30: 템플릿에서 반환하는 카테고리 Null 가드 필요DB/엔티티에서 NOT NULL을 강제하므로, 템플릿이 null을 돌려주면 런타임 오류/제약 위반이 납니다. 생성 이전에 즉시 검증하세요.
다음과 같이 선제 가드를 권장합니다:
@@ - NotificationCategory notificationCategory = template.notificationCategory(args); + NotificationCategory notificationCategory = java.util.Objects.requireNonNull( + template.notificationCategory(args), + "notificationCategory must not be null" + );
42-45: 저장 헬퍼에 불변식 검증 위임 고려saveNotification 진입부에서 title/content/category/userId에 대한 불변식 검증을 추가하면 이상 데이터 저장을 방지할 수 있습니다(템플릿·매퍼 경로 다양화 대비).
원하면 도메인 팩토리(withoutId) 쪽에서 일괄 검증하도록 이동시키겠습니다.
src/main/java/konkuk/thip/notification/domain/Notification.java (2)
24-31: 도메인 팩토리에서 필수값 선제 검증 추가title, content, notificationCategory, targetUserId는 필수입니다. 도메인 경계에서 fail‑fast가 안전합니다.
다음과 같이 간단히 보강하세요:
public static Notification withoutId (String title, String content, NotificationCategory notificationCategory, Long targetUserId) { - return Notification.builder() + java.util.Objects.requireNonNull(title, "title"); + java.util.Objects.requireNonNull(content, "content"); + java.util.Objects.requireNonNull(notificationCategory, "notificationCategory"); + java.util.Objects.requireNonNull(targetUserId, "targetUserId"); + return Notification.builder() .title(title) .content(content) .isChecked(false) .notificationCategory(notificationCategory) .targetUserId(targetUserId) .build(); }
24-24: 사소한 스타일: 메서드명 뒤 공백 제거
withoutId ( ... )→withoutId(... )로 공백 제거 시 일관성 향상.src/main/java/konkuk/thip/notification/application/port/out/NotificationQueryPort.java (1)
9-14: 중복 인터페이스 축소 제안세 메서드는 파라미터만 달라 동형입니다.
findByUserId(NotificationType type, Cursor cursor)하나로 통합하고 어댑터에서 분기하면 API 표면을 줄일 수 있습니다.src/main/java/konkuk/thip/notification/adapter/in/web/response/NotificationShowResponse.java (2)
5-9: nextCursor의 불변·불투명 토큰 보장String 토큰 채택은 향후 커서 스키마 변경에 유연합니다. 빈 문자열/NULL 케이스를 명확히(예: NULL이면 없음을 의미) 문서화해 주세요.
컨트롤러/서비스에서 마지막 페이지가 아니면 항상 nextCursor를 채우고(isLast=false), 마지막이면 null을 반환하는지 확인 부탁드립니다.
10-17: 시간대/표기 형식 고정
postDate가 사람이 읽는 문자열이라면 타임존(KST/UTC)과 형식(예: ISO-8601, 상대시간 규칙)을 고정·문서화하세요. 클라이언트 일관성 이슈 예방됩니다.가능하면 원본
createdAt(epoch ms/ISO)도 함께 내려 투트랙(머신·휴먼) 표기를 지원하는 것을 권장합니다.src/main/java/konkuk/thip/notification/application/port/out/dto/NotificationQueryDto.java (2)
24-24: 무의미한 null 검사 제거
isChecked는 primitive boolean이라 null일 수 없습니다. 해당 Assert는 항상 통과하며 노이즈입니다.다음과 같이 제거하세요:
- Assert.notNull(isChecked, "isChecked must not be null");
21-27: 필드 유효성 검증의 일관성title/content에 공백만 오는 경우까지 막으려면
Assert.hasText(...)가 더 적합합니다. 도메인 규칙에 따라 선택하세요.src/main/java/konkuk/thip/notification/adapter/out/persistence/repository/NotificationQueryRepository.java (1)
9-13: PK 커서 채택 자체는 적절함 + 페이지 경계 처리 체크PK 단일 커서는 심플하고 성능상 유리합니다. 다만 다음 두 점을 확인하세요.
- pageSize+1로 조회 후 hasNext/nextCursor 계산
- FEED_AND_ROOM의 IN 조건과
(userId, notificationCategory, id)복합 인덱스권장 인덱스(예시, DB에 맞게 변환 필요):
(user_id, id)— 전체/단일 카테고리 공통 경로(user_id, notification_category, id)— 카테고리 필터 경로src/main/java/konkuk/thip/notification/application/port/in/dto/NotificationType.java (1)
20-27: 기본값 및 대소문자 유연성 추가 제안API 요약에 따르면 기본은 “전체(FEED_AND_ROOM)”입니다. null/blank 입력 시 기본값을 반환하고, 대소문자/트리밍을 허용하면 클라이언트 친화적입니다.
다음과 같이 보강을 제안합니다:
- public static NotificationType from(String type) { - return Arrays.stream(NotificationType.values()) - .filter(param -> param.getType().equals(type)) + public static NotificationType from(String type) { + if (type == null || type.isBlank()) { + return FEED_AND_ROOM; + } + final String in = type.trim(); + return Arrays.stream(NotificationType.values()) + .filter(param -> param.getType().equalsIgnoreCase(in)) .findFirst() .orElseThrow( () -> new InvalidStateException(INVALID_NOTIFICATION_TYPE) ); }컨트롤러
@RequestParam에defaultValue = "feedAndRoom"가 이미 있다면, 중복 기본값이 되므로 하나만 유지하세요. 아래로 확인 가능합니다.#!/bin/bash rg -nP --type=java 'RequestParam\([^)]*type[^)]*defaultValue\s*=\s*"feedAndRoom"' -C2src/main/java/konkuk/thip/notification/application/service/NotificationShowService.java (2)
19-19: final static 순서 수정Java 컨벤션상
private static final순서가 일반적입니다.적용 diff:
- private final static int PAGE_SIZE = 10; + private static final int PAGE_SIZE = 10;
24-29: 페이지 사이즈 고정 전략, 향후 확장 고려현재 PAGE_SIZE=10 고정은 단순하고 안전합니다. 다만 기존 컨트롤러들(User 쪽)처럼 size 파라미터를 허용해 일관성을 맞출 여지가 있습니다(최대 10 제한 유지).
src/main/java/konkuk/thip/notification/adapter/in/web/NotificationQueryController.java (2)
51-51: Swagger에 userId 노출 숨김
@UserId파라미터는 문서화 대상이 아니므로 숨기는 것이 일관적입니다.적용 diff:
- @UserId final Long userId, + @Parameter(hidden = true) @UserId final Long userId,
55-56: type 파라미터 문구/예시와 실제 기본값 불일치설명은 null 시 동작을 언급하지만
defaultValue = "feedAndRoom"으로 null이 되지 않습니다. 지원 값도 명시해 주세요.적용 diff:
- @Parameter(description = "알림 타입. 해당 파라미터 값이 null인 경우에는 알림 타입을 구분하지 않고 조회합니다.", example = "feed or room") - @RequestParam(value = "type", required = false, defaultValue = "feedAndRoom") final String type + @Parameter(description = "알림 타입 (feed, room, feedAndRoom). 미지정(null/생략) 시 feedAndRoom으로 처리됩니다.", example = "feedAndRoom") + @RequestParam(value = "type", required = false, defaultValue = "feedAndRoom") final String typesrc/main/java/konkuk/thip/notification/adapter/out/persistence/repository/NotificationQueryRepositoryImpl.java (2)
21-30: 메서드명(…CreatedAtDesc)과 실제 정렬(PK desc) 불일치현재 주석/메서드명은 CreatedAt 기준 내림차순으로 보이지만, 실제 정렬은
notificationId.desc()입니다. 오해 소지가 큽니다. 두 가지 중 하나로 정리하세요.옵션 A(이 PR 의도 유지): 메서드명을
…OrderByIdDesc로 변경(인터페이스 포함 전체 일괄 반영).
옵션 B(메서드명 유지): 아래처럼createdAt.desc()로 정렬 변경 및 커서도 createdAt 기반으로 전환.- .orderBy(notification.notificationId.desc()) // PK 기준 내림차순 (= 최신순) + .orderBy(notification.createdAt.desc()) // 생성시각 기준 내림차순선택 시, 커서 비교도 동일 기준(
createdAt < lastCreatedAt)으로 일관되게 맞춰야 합니다.Also applies to: 32-41, 43-52, 72-73
61-75: 쿼리 성능용 인덱스 제안다음 복합 인덱스를 권장합니다.
- (user_id, notification_id DESC)
- (user_id, notification_category, notification_id DESC)
대량 데이터에서 where+정렬을 커버해 range scan이 용이합니다.src/main/java/konkuk/thip/notification/adapter/out/persistence/NotificationQueryPersistenceAdapter.java (1)
19-21: 불필요한 빈 주입 제거(NotificationMapper 미사용)
NotificationMapper가 본 클래스에서 사용되지 않습니다. 불필요한 의존성은 제거하세요.적용 diff:
-import konkuk.thip.notification.adapter.out.mapper.NotificationMapper; @@ - private final NotificationMapper notificationMapper;사용 여부 전체 확인 스크립트:
#!/bin/bash rg -nC2 '\bNotificationMapper\b'src/test/java/konkuk/thip/notification/adapter/in/web/NotificationShowApiTest.java (7)
52-60: 중복된 created_at 업데이트를 헬퍼로 추출하여 테스트 간 결합도/가독성 개선각 테스트마다 동일 SQL이 반복됩니다. 헬퍼 메서드로 감싸면 의도(clear ordering)만 남고 노이즈가 줄어듭니다.
적용 예시(해당 범위 치환):
- jdbcTemplate.update( - "UPDATE notifications SET created_at = ? WHERE notification_id = ?", - now.minusMinutes(30), feedN_1.getNotificationId() - ); - jdbcTemplate.update( - "UPDATE notifications SET created_at = ? WHERE notification_id = ?", - now.minusMinutes(10), feedN_2.getNotificationId() - ); + setCreatedAt(feedN_1.getNotificationId(), now.minusMinutes(30)); + setCreatedAt(feedN_2.getNotificationId(), now.minusMinutes(10));클래스 내 임의 위치(필드 아래)에 아래 유틸을 추가해 주세요:
private void setCreatedAt(long notificationId, LocalDateTime ts) { jdbcTemplate.update( "UPDATE notifications SET created_at = ? WHERE notification_id = ?", ts, notificationId ); }
68-78: isLast=true 시 nextCursor 비노출도 함께 검증해 주세요응답 계약을 명확히(마지막 페이지면 cursor 비노출) 해두면 클라이언트 처리 단순해집니다.
result.andExpect(status().isOk()) .andExpect(jsonPath("$.data.notifications", hasSize(2))) .andExpect(jsonPath("$.data.isLast").value(true)) + .andExpect(jsonPath("$.data.nextCursor").doesNotExist())
238-246: nextCursor 내용까지 검증해 커서-정렬 일관성 보장첫 페이지의 nextCursor가 첫 페이지 마지막 아이템의 PK와 동일함을 명시적으로 보장하면 계약이 더 견고해집니다.
.andExpect(jsonPath("$.data.isLast").value(false)) // 다음 페이지 존재 - .andExpect(jsonPath("$.data.nextCursor").isNotEmpty()) // nextCursor 존재 + .andExpect(jsonPath("$.data.nextCursor").isNotEmpty()) // nextCursor 존재 + .andExpect(jsonPath("$.data.nextCursor").value(String.valueOf(feedN_3.getNotificationId()))) // 커서=마지막 PK
269-271: JsonPath 반환 타입 안전화(String 캐스팅 위험)현재 구현은 서버가 숫자(Long)로 커서를 보내면 ClassCastException 위험이 있습니다. String.valueOf로 방어해 주세요.
- String responseBody = firstResult.getResponse().getContentAsString(); - String nextCursor = JsonPath.read(responseBody, "$.data.nextCursor"); + String responseBody = firstResult.getResponse().getContentAsString(); + String nextCursor = String.valueOf(JsonPath.read(responseBody, "$.data.nextCursor"));
277-284: 두 번째 페이지(마지막)에서도 nextCursor 비노출 확인마지막 페이지 계약 일관성을 보강합니다.
.andExpect(jsonPath("$.data.notifications", hasSize(2))) // 2개 조회 .andExpect(jsonPath("$.data.isLast").value(true)) // 마지막 페이지 + .andExpect(jsonPath("$.data.nextCursor").doesNotExist())
43-45: 잘못된 type 파라미터에 대한 400 검증 추가 제안컨트롤러가 NotificationType enum 바인딩으로 검증한다면, type=invalid 시 400을 명시적으로 확인해 두는 것이 안전합니다.
예시 테스트(추가):
@Test @DisplayName("type이 유효하지 않으면 400을 반환한다.") void show_notifications_invalid_type() throws Exception { mockMvc.perform(get("/notifications") .requestAttr("userId", 1L) .param("type", "invalid")) .andExpect(status().isBadRequest()); }원하시면 커서/limit 파라미터의 음수/비정상 값에 대한 400 케이스도 함께 작성해 드립니다.
121-127: 다른 사용자 데이터 누출 방지 테스트 추가 제안다른 사용자 알림이 섞이지 않음을 보장하는 케이스를 하나 추가해 주세요.
예시(추가):
@Test @DisplayName("다른 사용자의 알림은 포함되지 않는다.") void show_notifications_isolation_by_user() throws Exception { UserJpaEntity userA = userJpaRepository.save(TestEntityFactory.createUser(Alias.WRITER)); UserJpaEntity userB = userJpaRepository.save(TestEntityFactory.createUser(Alias.READER)); NotificationJpaEntity a1 = notificationJpaRepository.save(TestEntityFactory.createNotification(userA, "A1", NotificationCategory.FEED)); notificationJpaRepository.save(TestEntityFactory.createNotification(userB, "B1", NotificationCategory.FEED)); mockMvc.perform(get("/notifications") .requestAttr("userId", userA.getUserId()) .param("type", "feed")) .andExpect(status().isOk()) .andExpect(jsonPath("$.data.notifications[*].notificationId", everyItem(in(List.of(a1.getNotificationId()))))); }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Jira integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (49)
src/main/java/konkuk/thip/common/exception/code/ErrorCode.java(1 hunks)src/main/java/konkuk/thip/common/swagger/SwaggerResponseDescription.java(1 hunks)src/main/java/konkuk/thip/notification/adapter/in/web/NotificationCommandController.java(1 hunks)src/main/java/konkuk/thip/notification/adapter/in/web/NotificationQueryController.java(2 hunks)src/main/java/konkuk/thip/notification/adapter/in/web/response/NotificationShowResponse.java(1 hunks)src/main/java/konkuk/thip/notification/adapter/out/jpa/NotificationJpaEntity.java(2 hunks)src/main/java/konkuk/thip/notification/adapter/out/mapper/NotificationMapper.java(2 hunks)src/main/java/konkuk/thip/notification/adapter/out/persistence/NotificationQueryPersistenceAdapter.java(1 hunks)src/main/java/konkuk/thip/notification/adapter/out/persistence/function/PrimaryKeyNotificationQueryFunction.java(1 hunks)src/main/java/konkuk/thip/notification/adapter/out/persistence/repository/NotificationJpaRepository.java(1 hunks)src/main/java/konkuk/thip/notification/adapter/out/persistence/repository/NotificationQueryRepository.java(1 hunks)src/main/java/konkuk/thip/notification/adapter/out/persistence/repository/NotificationQueryRepositoryImpl.java(1 hunks)src/main/java/konkuk/thip/notification/application/mapper/NotificationQueryMapper.java(1 hunks)src/main/java/konkuk/thip/notification/application/port/in/NotificationShowUseCase.java(1 hunks)src/main/java/konkuk/thip/notification/application/port/in/dto/NotificationType.java(1 hunks)src/main/java/konkuk/thip/notification/application/port/in/fcm/FcmDeleteUseCase.java(1 hunks)src/main/java/konkuk/thip/notification/application/port/in/fcm/FcmEnableStateChangeUseCase.java(1 hunks)src/main/java/konkuk/thip/notification/application/port/in/fcm/FcmRegisterUseCase.java(1 hunks)src/main/java/konkuk/thip/notification/application/port/out/NotificationQueryPort.java(1 hunks)src/main/java/konkuk/thip/notification/application/port/out/dto/NotificationQueryDto.java(1 hunks)src/main/java/konkuk/thip/notification/application/service/NotificationShowService.java(1 hunks)src/main/java/konkuk/thip/notification/application/service/NotificationSyncExecutor.java(3 hunks)src/main/java/konkuk/thip/notification/application/service/fcm/FcmDeleteService.java(1 hunks)src/main/java/konkuk/thip/notification/application/service/fcm/FcmEnableStateChangeService.java(1 hunks)src/main/java/konkuk/thip/notification/application/service/fcm/FcmRegisterService.java(1 hunks)src/main/java/konkuk/thip/notification/application/service/template/NotificationTemplate.java(1 hunks)src/main/java/konkuk/thip/notification/application/service/template/feed/FeedCommentLikedTemplate.java(1 hunks)src/main/java/konkuk/thip/notification/application/service/template/feed/FeedCommentedTemplate.java(1 hunks)src/main/java/konkuk/thip/notification/application/service/template/feed/FeedLikedTemplate.java(1 hunks)src/main/java/konkuk/thip/notification/application/service/template/feed/FeedRepliedTemplate.java(1 hunks)src/main/java/konkuk/thip/notification/application/service/template/feed/FollowedTemplate.java(1 hunks)src/main/java/konkuk/thip/notification/application/service/template/feed/FolloweeNewPostTemplate.java(1 hunks)src/main/java/konkuk/thip/notification/application/service/template/room/RoomActivityStartedTemplate.java(1 hunks)src/main/java/konkuk/thip/notification/application/service/template/room/RoomCommentLikedTemplate.java(1 hunks)src/main/java/konkuk/thip/notification/application/service/template/room/RoomJoinToHostTemplate.java(1 hunks)src/main/java/konkuk/thip/notification/application/service/template/room/RoomPostCommentRepliedTemplate.java(1 hunks)src/main/java/konkuk/thip/notification/application/service/template/room/RoomPostCommentedTemplate.java(1 hunks)src/main/java/konkuk/thip/notification/application/service/template/room/RoomPostLikedTemplate.java(1 hunks)src/main/java/konkuk/thip/notification/application/service/template/room/RoomRecordCreatedTemplate.java(1 hunks)src/main/java/konkuk/thip/notification/application/service/template/room/RoomRecruitClosedEarlyTemplate.java(1 hunks)src/main/java/konkuk/thip/notification/application/service/template/room/RoomVoteStartedTemplate.java(1 hunks)src/main/java/konkuk/thip/notification/domain/Notification.java(2 hunks)src/main/java/konkuk/thip/room/adapter/in/web/RoomQueryController.java(2 hunks)src/main/java/konkuk/thip/room/application/port/in/RoomShowMineUseCase.java(1 hunks)src/main/java/konkuk/thip/room/application/service/RoomShowMineService.java(1 hunks)src/main/resources/db/migration/V250916__Add_notification_category.sql(1 hunks)src/test/java/konkuk/thip/common/util/TestEntityFactory.java(2 hunks)src/test/java/konkuk/thip/notification/adapter/in/web/NotificationShowApiTest.java(1 hunks)src/test/java/konkuk/thip/notification/application/service/NotificationSyncExecutorTest.java(2 hunks)
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
Learnt from: seongjunnoh
PR: THIP-TextHip/THIP-Server#113
File: src/main/java/konkuk/thip/recentSearch/adapter/out/persistence/RecentSearchCommandPersistenceAdapter.java:38-44
Timestamp: 2025-07-30T14:05:04.945Z
Learning: seongjunnoh는 코드 최적화 제안에 대해 구체적인 기술적 근거와 효율성 차이를 이해하고 싶어하며, 성능 개선 방식에 대한 상세한 설명을 선호한다.
Learnt from: seongjunnoh
PR: THIP-TextHip/THIP-Server#93
File: src/main/java/konkuk/thip/room/adapter/out/persistence/RoomQueryPersistenceAdapter.java:49-114
Timestamp: 2025-07-28T16:44:31.224Z
Learning: seongjunnoh는 코드 중복 문제에 대한 리팩토링 제안을 적극적으로 수용하고 함수형 인터페이스를 활용한 해결책을 선호한다.
Learnt from: seongjunnoh
PR: THIP-TextHip/THIP-Server#285
File: src/main/java/konkuk/thip/room/adapter/out/jpa/RoomStatus.java:1-7
Timestamp: 2025-08-31T05:25:14.845Z
Learning: seongjunnoh는 enum 의존성에 대해 유연한 접근을 선호하며, 도메인→어댑터 레이어 참조와 같은 아키텍처 layering 원칙보다 실용적인 구현을 우선시한다.
Learnt from: seongjunnoh
PR: THIP-TextHip/THIP-Server#195
File: src/main/java/konkuk/thip/feed/application/mapper/FeedQueryMapper.java:0-0
Timestamp: 2025-08-13T05:22:32.287Z
Learning: seongjunnoh는 데이터 무결성과 중복 방지에 대한 고민이 깊으며, LinkedHashSet을 활용한 중복 제거와 순서 보장을 동시에 달성하는 솔루션을 선호한다.
Learnt from: seongjunnoh
PR: THIP-TextHip/THIP-Server#278
File: src/main/java/konkuk/thip/TestTokenController.java:0-0
Timestamp: 2025-08-24T09:33:52.982Z
Learning: seongjunnoh는 Spring의 ConditionalOnProperty 동작 원리를 정확히 이해하고 있으며, 보안 이슈에 대해서도 실질적인 위험성을 기준으로 판단하는 실용적 접근을 선호한다.
Learnt from: seongjunnoh
PR: THIP-TextHip/THIP-Server#278
File: src/main/java/konkuk/thip/common/exception/code/ErrorCode.java:210-211
Timestamp: 2025-08-24T09:40:48.595Z
Learning: seongjunnoh는 HTTP 상태 코드 선택에 대해 기술적 근거와 코드베이스 내 일관성을 중요하게 생각하며, 구체적인 사례 분석을 통한 설명을 선호한다.
Learnt from: seongjunnoh
PR: THIP-TextHip/THIP-Server#180
File: src/main/java/konkuk/thip/room/application/service/AttendanceCheckCreateService.java:22-40
Timestamp: 2025-08-14T09:15:31.371Z
Learning: seongjunnoh는 기술적 완벽성보다 실제 비즈니스 시나리오와 사용자 행동 패턴을 우선 고려하며, 발생 가능성이 낮은 엣지 케이스보다는 실용적인 구현을 선호한다.
Learnt from: seongjunnoh
PR: THIP-TextHip/THIP-Server#112
File: src/main/java/konkuk/thip/feed/adapter/out/persistence/repository/FeedQueryRepositoryImpl.java:272-272
Timestamp: 2025-07-30T10:44:34.115Z
Learning: seongjunnoh는 피드 커서 페이지네이션에서 LocalDateTime 단일 커서 방식을 선호하며, 복합 키 기반 커서보다 구현 단순성과 성능을 우선시한다.
🧬 Code graph analysis (4)
src/main/java/konkuk/thip/notification/application/mapper/NotificationQueryMapper.java (1)
src/main/java/konkuk/thip/common/util/DateUtil.java (1)
DateUtil(12-108)
src/main/java/konkuk/thip/notification/adapter/in/web/NotificationQueryController.java (1)
src/main/java/konkuk/thip/user/adapter/in/web/UserQueryController.java (1)
Tag(33-171)
src/test/java/konkuk/thip/notification/adapter/in/web/NotificationShowApiTest.java (1)
src/test/java/konkuk/thip/common/util/TestEntityFactory.java (1)
TestEntityFactory(35-385)
src/main/java/konkuk/thip/notification/adapter/out/persistence/NotificationQueryPersistenceAdapter.java (1)
src/main/java/konkuk/thip/notification/adapter/out/persistence/NotificationCommandPersistenceAdapter.java (1)
Repository(14-31)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
🔇 Additional comments (31)
src/main/java/konkuk/thip/room/adapter/in/web/RoomQueryController.java (1)
13-13: LGTM: enum import 추가 적절컨트롤러에서 enum을 직접 다루기 위한 준비로 적절합니다.
src/main/java/konkuk/thip/room/application/service/RoomShowMineService.java (2)
28-28: 시그니처 변경 반영 OKUseCase와 일치하며, 호출부에서 enum을 강제해 타입 안정성이 확보됩니다.
32-42: 분기 로직 명확 — enum switch로 컴파일 타임 안전성 확보각 타입별 포트 호출이 분리되어 가독성과 유지보수성이 좋습니다. 이후 enum 상수 추가 시 컴파일러가 누락 분기를 잡아줄 수 있어 안전합니다.
src/main/java/konkuk/thip/common/exception/code/ErrorCode.java (1)
228-232: 알림 에러코드 추가 LGTM새 영역(205000)과 메시지/HttpStatus 선택 적절합니다. FCM 상수 끝 콤마 보정도 OK.
src/main/java/konkuk/thip/notification/application/port/in/fcm/FcmRegisterUseCase.java (1)
1-1: 패키지 이동 LGTM의존 업데이트만으로 의미 변화 없음. 컴파일/빈 스캔 영향 없음.
src/main/java/konkuk/thip/common/swagger/SwaggerResponseDescription.java (1)
376-378: NOTIFICATION_SHOW 추가 LGTMINVALID_NOTIFICATION_TYPE 노출로 요청 파라미터 오류가 명확합니다. 공통 API_* 에러는 생성자에서 이미 병합되니 충분합니다.
src/main/java/konkuk/thip/notification/application/port/in/fcm/FcmDeleteUseCase.java (1)
1-1: 패키지 정리 LGTM이동에 따른 동작 변화 없음.
src/main/java/konkuk/thip/notification/application/service/template/feed/FeedCommentLikedTemplate.java (1)
19-22: 카테고리 명시 구현 LGTM템플릿 계약 충족(NotificationCategory.FEED). 타 템플릿들과의 일관성 유지에 좋습니다.
src/main/java/konkuk/thip/notification/adapter/out/mapper/NotificationMapper.java (2)
16-16: toJpaEntity 카테고리 매핑 추가 LGTM도메인→JPA 누락 없이 반영되었습니다.
27-27: toDomainEntity 카테고리 매핑 추가 LGTM + enum 매핑 방식 확인 요청JPA 엔티티 필드가 @Enumerated(EnumType.STRING)인지 확인 부탁드립니다. 숫자 매핑이면 마이그레이션/리네이밍 시 깨질 수 있습니다.
빠른 확인:
#!/bin/bash rg -nP -C2 'class\s+NotificationJpaEntity\b' src/main/java rg -nP -C2 '@Enumerated\s*\(\s*EnumType\.STRING\s*\)\s*private\s+.*notificationCategory' src/main/javasrc/main/java/konkuk/thip/notification/adapter/in/web/NotificationCommandController.java (1)
14-16: FCM 포트 패키지 경로 이동 반영: OK. 구(舊) 경로 잔존 여부만 점검 부탁드립니다.동작 변화는 없고 import 경로만 변경된 것으로 보입니다. 레거시 경로 참조가 남아있지 않은지 한 번에 스캔해 주세요.
아래 스크립트로 기존 경로 사용 흔적을 점검할 수 있습니다.
#!/bin/bash set -euo pipefail # 1) 구경로(import) 잔존 탐지: application.port.in.(?!fcm.)Fcm* rg -nP --type=java 'notification\.application\.port\.in\.(?!(fcm\.))Fcm(?:Delete|EnableStateChange|Register)UseCase' # 2) 신경로(import) 확인(참고) rg -nP --type=java 'notification\.application\.port\.in\.fcm\.Fcm(?:Delete|EnableStateChange|Register)UseCase'src/main/java/konkuk/thip/notification/application/service/template/room/RoomRecordCreatedTemplate.java (1)
19-22: ROOM 카테고리 매핑 OK변경 의도에 부합합니다.
src/main/java/konkuk/thip/notification/application/service/template/feed/FollowedTemplate.java (1)
21-24: FEED 카테고리 매핑 OK문맥에 맞습니다.
src/main/java/konkuk/thip/notification/application/service/template/room/RoomRecruitClosedEarlyTemplate.java (1)
19-22: ROOM 카테고리 매핑 OK템플릿 의도와 일치.
src/test/java/konkuk/thip/notification/application/service/NotificationSyncExecutorTest.java (1)
6-6: 새로운 enum 의존성 import 추가 OK컴파일 요건 충족을 위한 합리적 변경입니다.
src/main/java/konkuk/thip/notification/application/service/template/feed/FeedRepliedTemplate.java (1)
19-22: 카테고리 노출 구현 LGTMFeed 템플릿에서 고정적으로 FEED 반환하는 구현이 명확합니다. Args를 사용하지 않도록 한 것도 적절합니다.
actorUsername가 null이 아닌 것이 상수로 보장되는지(템플릿 호출 전 검증) 확인 부탁드립니다. 필요하면Args에 null‑guard를 추가해도 됩니다.src/main/java/konkuk/thip/notification/adapter/out/persistence/function/PrimaryKeyNotificationQueryFunction.java (1)
7-11: 함수형 인터페이스 도입 좋습니다커서 기반 공통 로직에 주입하기 좋은 최소 표면적입니다. 도메인 가독성 측면에서
BiFunction<Long,Integer,List<...>>보다 명확합니다.src/main/java/konkuk/thip/notification/application/port/in/fcm/FcmEnableStateChangeUseCase.java (1)
1-1: 패키지 이동 LGTMFCM 유스케이스를 하위 패키지로 구분한 구조가 명확합니다. 컴포넌트 스캔 경로에 포함되는지만 확인해 주세요(현 패키지 구조면 기본 스캔에 포함될 가능성이 큽니다).
src/main/java/konkuk/thip/notification/application/service/fcm/FcmDeleteService.java (1)
1-3: 패키지/임포트 정리 OK구조 개편에 맞춘 패키지/임포트 변경 이상 없습니다.
src/main/java/konkuk/thip/notification/application/service/fcm/FcmEnableStateChangeService.java (1)
1-3: 패키지/의존 경로 재정렬 LGTMFCM 관련 컴포넌트 하위 패키지 분리는 응집도를 높입니다. 변경에 따른 빈 스캔/컴포넌트 스캔 경로만 재확인하면 됩니다.
@ComponentScan범위에.application.service.fcm이 포함되는지 한 번만 체크 부탁드립니다.src/main/java/konkuk/thip/notification/application/port/out/NotificationQueryPort.java (1)
9-14: PK 커서 기반 조회 방향성 👍유저별 최신순(내림차순)에서 PK(Long) 커서를 쓰는 선택은 단조·유일성 보장이 되어 중복/누락 방지에 유리합니다. 정렬 컬럼과 커서 컬럼을 반드시 동일하게 유지해주세요(id DESC + id < lastId).
아래 스크립트로 구현부에서 id DESC 정렬과
id < :lastId조건이 함께 쓰였는지 확인 부탁드립니다.#!/bin/bash # NotificationQueryRepositoryImpl에서 id 기반 정렬/커서 사용 확인 fd -a 'NotificationQueryRepositoryImpl.java' | while read f; do echo ">> $f" rg -n -C3 -e 'orderBy\(.*\bid\b.*desc\(\)\)' -e '\bid\b\s*\.lt\(' "$f" done # nextCursor 계산 시 pageSize+1 페치 여부도 확인 rg -n -C2 'fetch\(\s*pageSize\s*\+\s*1\s*\)' $(fd -a 'NotificationQueryRepositoryImpl.java')src/main/java/konkuk/thip/notification/application/service/NotificationShowService.java (2)
31-35: 타입 분기 명확하고 컴파일 타임 안전
switch표현식으로 FEED/ROOM/FEED_AND_ROOM 분기 처리 좋습니다. 변경에 취약하지 않고 가독성도 좋습니다.
40-41: 커서 반환/마지막 페이지 판별 로직 적절
result.nextCursor()와!result.hasNext()로 응답 구성한 부분 적절합니다.src/main/java/konkuk/thip/notification/application/mapper/NotificationQueryMapper.java (2)
12-16: MapStruct 설정 적절
componentModel=spring,imports=DateUtil,unmappedTargetPolicy=IGNORE구성 적절합니다.
20-24: Null-안전성 확인(카테고리/생성시각)
dto.notificationCategory().getDisplay()와dto.createdAt()가 null일 경우 NPE 위험이 있습니다. 마이그레이션으로 NOT NULL 제약이 있는지 재확인 부탁드립니다. 없다면 널 가드 또는 DB 제약 추가를 권장합니다.src/main/java/konkuk/thip/notification/adapter/out/persistence/repository/NotificationQueryRepositoryImpl.java (1)
54-59: PK 커서 비교 로직은 일관적
notificationId.lt(lastNotificationId)는 PK 내림차순 정렬과 일관됩니다. 커서/정렬 기준을 바꿀 경우 이 부분도 함께 조정 필요합니다.운영 데이터에서 PK≒생성시각 단조 증가 가정이 항상 성립하는지(지연/백필/마이그레이션 시나리오) 확인 부탁드립니다.
src/main/java/konkuk/thip/notification/adapter/out/persistence/NotificationQueryPersistenceAdapter.java (2)
22-41: 중복 제거를 위한 함수형 인터페이스 활용 좋음
PrimaryKeyNotificationQueryFunction으로 공통 커서 로직을 수렴한 점 👍. 유지보수성/재사용성 측면에서 적절합니다.
43-55: nextCursor 생성 로직 타당마지막 요소의 PK를 다음 커서로 인코딩하는 전략이 정렬/커서 비교와 일관됩니다.
src/main/java/konkuk/thip/notification/adapter/in/web/NotificationQueryController.java (1)
49-58: 기본 동작은 적절, 매개변수 검증(from) 확인 필요컨트롤러→UseCase 연결은 적절합니다. 다만
NotificationType.from(type)이 대소문자/별칭(feedAndRoom)을 안정적으로 수용하는지 확인 부탁드립니다.다음 스크립트로 enum과
from구현/허용 토큰을 빠르게 점검할 수 있습니다.#!/bin/bash # NotificationType 정의/from 메서드 검색 fd -a 'NotificationType.java' || true rg -nP -C3 '\benum\s+NotificationType\b' rg -nP -C3 '\bstatic\b.*\bfrom\s*\(' # 허용 문자열 비교: feed, room, feedAndRoom 케이스 불변 매핑 여부 rg -nP -C2 'feedAndRoom|FEED_AND_ROOM|feed|room|FEED|ROOM'src/test/java/konkuk/thip/notification/adapter/in/web/NotificationShowApiTest.java (2)
169-171: PK 커서 사용 방향성 적합 — 정렬/조건 일치 여부만 재확인 요청auto‑increment PK를 커서로 쓰고 ORDER BY notification_id DESC, WHERE notification_id < :cursor 패턴이면 역시간 정렬과 동일한 단조성이 보장되어 페이징 안정성이 높습니다. 현재 테스트 의도와 잘 맞습니다. 다만 실제 구현이 created_at DESC 정렬과 혼재되지 않았는지만 한 번만 확인 부탁드립니다(혼재 시 커서 조건이 (id)만으로는 누락/중복 발생).
추천 쿼리 형태:
- type=feed/room: WHERE user_id=:uid AND category=:c AND notification_id < :cursor ORDER BY notification_id DESC LIMIT :limit
- type=null: WHERE user_id=:uid AND notification_id < :cursor ORDER BY notification_id DESC LIMIT :limit
동일 created_at 시에도 결정론이 유지됩니다.
31-36: MockMvc + @transactional 전파 확인테스트 메서드에 걸린 @transactional에 컨트롤러/서비스 트랜잭션이 자연스럽게 참여하면 현재 방식이 안전합니다. 다만 내부에 Propagation.REQUIRES_NEW가 섞여 있으면 테스트에서 저장한 데이터/직접 SQL 업데이트가 보이지 않아 간헐 실패가 납니다. 알림 관련 서비스에 REQUIRES_NEW 사용 여부 한 번만 스캔해 주세요.
다음 스크립트로 빠르게 점검 가능합니다.
#!/bin/bash # REQUIRES_NEW 사용 위치 검색 rg -n --type=java -C2 '@Transactional\([^)]*REQUIRES_NEW' src/main/java
...a/konkuk/thip/notification/adapter/out/persistence/repository/NotificationJpaRepository.java
Show resolved
Hide resolved
| List<NotificationQueryDto> findFeedNotificationsOrderByCreatedAtDesc(Long userId, Long lastNotificationId, int pageSize); | ||
|
|
||
| List<NotificationQueryDto> findRoomNotificationsOrderByCreatedAtDesc(Long userId, Long lastNotificationId, int pageSize); | ||
|
|
||
| List<NotificationQueryDto> findFeedAndRoomNotificationsOrderByCreatedAtDesc(Long userId, Long lastNotificationId, int pageSize); |
There was a problem hiding this comment.
커서(id)와 정렬(createdAt) 불일치 가능성 — 누락/중복 위험
메서드명이 CreatedAt DESC 정렬을 시사하지만 커서는 lastNotificationId(PK)입니다. 구현도 createdAt 기준이면, id < lastId 커서와 정렬 기준이 달라 페이징 오류가 발생할 수 있습니다. 커서 컬럼과 정렬 컬럼을 일치시키거나(권장: id DESC) 동률 처리(createdAt DESC, id DESC + 복합 커서)로 보완하세요.
정렬 기준을 id DESC로 통일하는 경우 시그니처/구현/쿼리 모두를 다음처럼 정리하세요:
- List<NotificationQueryDto> findFeedNotificationsOrderByCreatedAtDesc(Long userId, Long lastNotificationId, int pageSize);
- List<NotificationQueryDto> findRoomNotificationsOrderByCreatedAtDesc(Long userId, Long lastNotificationId, int pageSize);
- List<NotificationQueryDto> findFeedAndRoomNotificationsOrderByCreatedAtDesc(Long userId, Long lastNotificationId, int pageSize);
+ List<NotificationQueryDto> findFeedNotificationsOrderByIdDesc(Long userId, Long lastNotificationId, int pageSize);
+ List<NotificationQueryDto> findRoomNotificationsOrderByIdDesc(Long userId, Long lastNotificationId, int pageSize);
+ List<NotificationQueryDto> findFeedAndRoomNotificationsOrderByIdDesc(Long userId, Long lastNotificationId, int pageSize);대안으로 createdAt 기반을 유지한다면, 조건을 (createdAt < :lastCreatedAt) OR (createdAt = :lastCreatedAt AND id < :lastId)로 구성하고 정렬을 createdAt DESC, id DESC로 맞춰야 합니다.
구현부에서 실제 정렬/조건을 확인해 주세요:
#!/bin/bash
fd -a 'NotificationQueryRepositoryImpl.java' | while read f; do
echo ">> $f"
rg -n -C3 'orderBy\(' "$f"
rg -n -C3 -e '\.lt\(|<\s*:' "$f"
done🤖 Prompt for AI Agents
In
src/main/java/konkuk/thip/notification/adapter/out/persistence/repository/NotificationQueryRepository.java
around lines 9-13: the methods use lastNotificationId as a cursor but their
names/intent imply ordering by createdAt DESC which can cause missing/duplicate
items; either make the cursor and ordering consistent by switching to id DESC
(update method names/signatures, repository implementation and queries to use id
DESC and id < :lastId paging) or keep createdAt-based paging and implement a
composite cursor/condition and ordering (WHERE (createdAt < :lastCreatedAt) OR
(createdAt = :lastCreatedAt AND id < :lastId) with ORDER BY createdAt DESC, id
DESC), and update DTO/parameters accordingly so signature, query and
implementation match; after changes, run the suggested check to confirm
implementation uses the same columns for cursor and ordering.
There was a problem hiding this comment.
현재 id 는 MySQL DB 의 auto increment 정책에 의해 insert 되는 시점에 자동으로 부여되는 PK 값이야. 따라서 최신순 정렬 조회시 id 값을 커서로 잡아도 문제없이 동작한다고 생각해.
그리고 '최신순 정렬하여 조회한다' 라는 동작을 단지 id값을 커서로 잡아서 구현한 것이므로 메서드 네이밍 또한 최신순 정렬 조회를 잘 드러낼 수 있도록 find,,,OrderByCreatedAtDesc() 로 정의하는게 가독성이 좋다고 생각해
또한 추후에 DB 마이그레이션, 분산 DB 등의 이슈로 인해 id 값이 크지만 생성시점은 이전인 데이터가 있을 수 있는데, 이때는 최신순 정렬 조회를 위해 커서를 id 가 아닌 다른 값으로 수정해야해. 이때 QueryRepository 에 정의한 메서드의 네이밍을 find,,,OrderByCreatedAtDesc() 로 정의하면 커서값이 바뀌더라도 '최신순 조회 정렬' 이라는 동작은 유지되는 것이므로 추가적인 수정이 필요없다는 장점이 있을 거 같아. 어떻게 생각해? @coderabbitai
There was a problem hiding this comment.
🧩 Analysis chain
@seongjunnoh 말씀하신 점들이 모두 합리적입니다!
특히 다음 세 가지 관점에서 좋은 설계라고 생각합니다:
-
실용적 접근: 현재 MySQL auto increment 환경에서는 id 순서 = 생성 시간 순서가 보장되므로 성능상 유리합니다.
-
비즈니스 의도 중심 네이밍:
OrderByCreatedAtDesc라는 네이밍이 "최신순 조회"라는 비즈니스 의도를 명확히 드러내는 것이 맞습니다. -
미래 확장성 고려: DB 분산화나 마이그레이션 시나리오를 미리 고려한 설계 철학이 인상적입니다. 구현은 바뀔 수 있지만 비즈니스 의도는 유지되죠.
구현부 확인 후 일관성이 보장되고 있다면 현재 접근 방식이 적절하다고 생각합니다.
🏁 Script executed:
#!/bin/bash
# 실제 구현부를 확인해서 정렬과 커서 조건이 일치하는지 확인해보겠습니다
echo "=== NotificationQueryRepositoryImpl 구현 확인 ==="
fd 'NotificationQueryRepositoryImpl.java' --exec cat {}
echo -e "\n=== 정렬 조건 확인 ==="
fd 'NotificationQueryRepositoryImpl.java' --exec rg -n -C2 'orderBy' {}
echo -e "\n=== 커서 조건 확인 ==="
fd 'NotificationQueryRepositoryImpl.java' --exec rg -n -C2 'lastNotificationId' {}
Length of output: 5778
완벽하게 구현되어 있네요! 실제 코드를 확인해보니 제가 처음에 우려했던 부분이 전혀 문제가 없었습니다.
구현 분석 결과:
- 정렬:
notification.notificationId.desc()(Line 72) - 커서 조건:
notification.notificationId.lt(lastNotificationId)(Line 56) - 일관성: ✅ 커서와 정렬이 모두 동일한 컬럼(
notificationId) 사용
코드 Line 72의 주석도 // PK 기준 내림차순 (= 최신순)로 명확히 의도를 표현하고 있어서, 구현과 비즈니스 의도가 완벽히 일치합니다.
말씀하신 설계 철학이 정말 훌륭합니다:
- 현재 환경 최적화: MySQL auto increment로
id = 최신순보장 - 비즈니스 중심 네이밍: 구현보다 의도(
OrderByCreatedAtDesc)를 드러냄 - 미래 확장성: DB 분산화 시나리오까지 고려한 인터페이스 설계
처음 메서드명만 보고 성급하게 우려를 표했는데, 실제로는 완벽하게 설계되고 구현된 코드였네요. 이런 사려 깊은 아키텍처 접근 방식에서 배울 점이 많습니다!
✏️ Learnings added
Learnt from: seongjunnoh
PR: THIP-TextHip/THIP-Server#305
File: src/main/java/konkuk/thip/notification/adapter/out/persistence/repository/NotificationQueryRepository.java:9-13
Timestamp: 2025-09-17T06:40:49.829Z
Learning: seongjunnoh는 메서드 네이밍 시 구현 세부사항보다 비즈니스 의도를 반영하는 것을 선호하며, 미래 확장성과 아키텍처 변화를 고려한 설계 철학을 가지고 있다.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
🧠 Learnings used
Learnt from: seongjunnoh
PR: THIP-TextHip/THIP-Server#113
File: src/main/java/konkuk/thip/recentSearch/adapter/out/persistence/RecentSearchCommandPersistenceAdapter.java:38-44
Timestamp: 2025-07-30T14:05:04.945Z
Learning: seongjunnoh는 코드 최적화 제안에 대해 구체적인 기술적 근거와 효율성 차이를 이해하고 싶어하며, 성능 개선 방식에 대한 상세한 설명을 선호한다.
Learnt from: seongjunnoh
PR: THIP-TextHip/THIP-Server#93
File: src/main/java/konkuk/thip/room/adapter/out/persistence/RoomQueryPersistenceAdapter.java:49-114
Timestamp: 2025-07-28T16:44:31.224Z
Learning: seongjunnoh는 코드 중복 문제에 대한 리팩토링 제안을 적극적으로 수용하고 함수형 인터페이스를 활용한 해결책을 선호한다.
Learnt from: seongjunnoh
PR: THIP-TextHip/THIP-Server#285
File: src/main/java/konkuk/thip/room/adapter/out/jpa/RoomStatus.java:1-7
Timestamp: 2025-08-31T05:25:14.845Z
Learning: seongjunnoh는 enum 의존성에 대해 유연한 접근을 선호하며, 도메인→어댑터 레이어 참조와 같은 아키텍처 layering 원칙보다 실용적인 구현을 우선시한다.
Learnt from: seongjunnoh
PR: THIP-TextHip/THIP-Server#195
File: src/main/java/konkuk/thip/feed/application/mapper/FeedQueryMapper.java:0-0
Timestamp: 2025-08-13T05:22:32.287Z
Learning: seongjunnoh는 데이터 무결성과 중복 방지에 대한 고민이 깊으며, LinkedHashSet을 활용한 중복 제거와 순서 보장을 동시에 달성하는 솔루션을 선호한다.
Learnt from: seongjunnoh
PR: THIP-TextHip/THIP-Server#278
File: src/main/java/konkuk/thip/TestTokenController.java:0-0
Timestamp: 2025-08-24T09:33:52.982Z
Learning: seongjunnoh는 Spring의 ConditionalOnProperty 동작 원리를 정확히 이해하고 있으며, 보안 이슈에 대해서도 실질적인 위험성을 기준으로 판단하는 실용적 접근을 선호한다.
Learnt from: seongjunnoh
PR: THIP-TextHip/THIP-Server#278
File: src/main/java/konkuk/thip/common/exception/code/ErrorCode.java:210-211
Timestamp: 2025-08-24T09:40:48.595Z
Learning: seongjunnoh는 HTTP 상태 코드 선택에 대해 기술적 근거와 코드베이스 내 일관성을 중요하게 생각하며, 구체적인 사례 분석을 통한 설명을 선호한다.
Learnt from: seongjunnoh
PR: THIP-TextHip/THIP-Server#180
File: src/main/java/konkuk/thip/room/application/service/AttendanceCheckCreateService.java:22-40
Timestamp: 2025-08-14T09:15:31.371Z
Learning: seongjunnoh는 기술적 완벽성보다 실제 비즈니스 시나리오와 사용자 행동 패턴을 우선 고려하며, 발생 가능성이 낮은 엣지 케이스보다는 실용적인 구현을 선호한다.
Learnt from: seongjunnoh
PR: THIP-TextHip/THIP-Server#112
File: src/main/java/konkuk/thip/feed/adapter/out/persistence/repository/FeedQueryRepositoryImpl.java:272-272
Timestamp: 2025-07-30T10:44:34.115Z
Learning: seongjunnoh는 피드 커서 페이지네이션에서 LocalDateTime 단일 커서 방식을 선호하며, 복합 키 기반 커서보다 구현 단순성과 성능을 우선시한다.
If you found this review helpful, would you consider giving us a shout-out on X?
Thank you for using CodeRabbit!
hd0rable
left a comment
hd0rable
left a comment
There was a problem hiding this comment.
수고하셨습니다!! 간단한 리뷰 남겨보았는데 확인해주시면 감사하겠습니다 !! 👍🏻💯
| import konkuk.thip.notification.application.port.in.FcmDeleteUseCase; | ||
| import konkuk.thip.notification.application.port.in.FcmEnableStateChangeUseCase; | ||
| import konkuk.thip.notification.application.port.in.FcmRegisterUseCase; | ||
| import konkuk.thip.notification.application.port.in.fcm.FcmDeleteUseCase; |
| @ExceptionDescription(NOTIFICATION_SHOW) | ||
| @GetMapping("/notifications") | ||
| public BaseResponse<NotificationShowResponse> showNotifications( | ||
| @UserId final Long userId, |
There was a problem hiding this comment.
엇 빼먹었네요 추가하겠습니다!
|
|
||
| @Enumerated(EnumType.STRING) | ||
| @Column(name = "notification_category", length = 16, nullable = false) | ||
| private NotificationCategory notificationCategory; |
|
|
||
| @Override | ||
| public List<NotificationQueryDto> findFeedNotificationsOrderByCreatedAtDesc(Long userId, Long lastNotificationId, int pageSize) { | ||
| QNotificationJpaEntity notification = QNotificationJpaEntity.notificationJpaEntity; |
There was a problem hiding this comment.
p3:RepositoryImpl 클래스에서 기본적으로 사용되는 Q엔티티(NotificationQueryRepositoryImpl에서는 QNotificationJpaEntity 등)를 클래스 단위로 변수로 선언하는 방식은 어떨까요?
이렇게 하면 중복 코드가 줄어들 뿐만 아니라, 해당 Repository가 어떤 엔티티를 다루는지 더 명확하게 드러나 가독성도 향상될 것 같습니다!
There was a problem hiding this comment.
음 각 메서드 별로 의존하는 코드가 없도록 하기위해서 Q클래스를 모두 분리하였는데, QNotificationJpaEntity 정도는 공유해도 문제 없을 것 같네요!
반영해서 수정하겠습니다
| )) | ||
| .from(notification) | ||
| .where(where) | ||
| .orderBy(notification.notificationId.desc()) // PK 기준 내림차순 (= 최신순) |
| Cursor cursor = Cursor.from(cursorStr, PAGE_SIZE); | ||
|
|
||
| // 2. 커서 기반 조회 | ||
| CursorBasedList<NotificationQueryDto> result = switch (notificationType) { |
|
|
||
| // 1. DB 저장 | ||
| saveNotification(title, content, targetUserId); | ||
| saveNotification(title, content, notificationCategory, targetUserId); |
| @Parameter(description = "커서 (첫번째 요청시 : null, 다음 요청시 : 이전 요청에서 반환받은 nextCursor 값)") | ||
| @RequestParam(value = "cursor", required = false) final String cursor) { | ||
| return BaseResponse.ok(roomShowMineUseCase.getMyRooms(userId, type, cursor)); | ||
| return BaseResponse.ok(roomShowMineUseCase.getMyRooms(userId, MyRoomType.from(type), cursor)); |
|
|
||
| -- 2단계: 기존 데이터 update | ||
| UPDATE notifications | ||
| SET notification_category = 'FEED' |
There was a problem hiding this comment.
엇 혹시 지금 개발서버에 있는 알림이 다 FEED라 의도하시고 모두 FEED로 업데이트하시는걸까요??
There was a problem hiding this comment.
음 일단은 FEED 로 해놓고, 기존 데이터에 다른 부분이 있다면 sql문으로 직접 수정할 생각입니다
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
src/main/java/konkuk/thip/notification/adapter/out/persistence/repository/NotificationQueryRepositoryImpl.java (1)
20-21: Q 엔티티 클래스 레벨 공유 반영 👍 + static final 권장클래스 단위로
QNotificationJpaEntity를 공유하신 점 좋습니다. 필드 특성상 불변이라static final로 두면 의도도 더 명확합니다.- private final QNotificationJpaEntity notification = QNotificationJpaEntity.notificationJpaEntity; + private static final QNotificationJpaEntity notification = QNotificationJpaEntity.notificationJpaEntity;
🧹 Nitpick comments (3)
src/main/java/konkuk/thip/notification/adapter/out/persistence/repository/NotificationQueryRepositoryImpl.java (3)
68-69: PK 커서 전략 합리적입니다. 인덱스 설계만 보강하세요.
WHERE user_id=? AND category {= or IN (...)} AND notification_id < ? ORDER BY notification_id DESC LIMIT ?+1패턴에 최적화된 인덱스를 권장합니다. 대량 트래픽에서도 정렬·페이지 탈락 없이 인덱스 range-scan으로 끝납니다.
- 단일 카테고리 조회 최적화:
- Postgres:
CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_n_user_cat_id_desc ON notifications (user_id, notification_category, notification_id DESC);- MySQL:
CREATE INDEX idx_n_user_cat_id_desc ON notifications (user_id, notification_category, notification_id DESC);- 다중 카테고리(IN) 조회도 위 인덱스로 카테고리별 짧은 range-scan 후 merge가 가능합니다.
- 추가로 user 단독 인덱스가 이미 강한 경우:
(user_id, notification_id DESC)보조 인덱스를 고려(카테고리 다양화 대비).전제:
- PK가 생성 시각 증가성과 강하게 상관(역삽입/백필 없음)해야 “최신순=ID 내림차순”이 성립합니다. 운영 상 역삽입 가능성이 있다면 createdAt+id 복합 정렬/커서로의 전환이 필요합니다.
50-55: applyCursor 간결화(파라미터 축소)
불변 클래스 필드를 사용하면 시그니처를 단순화할 수 있습니다.- private static BooleanExpression applyCursor(Long lastNotificationId, BooleanExpression where, QNotificationJpaEntity notification) { + private static BooleanExpression applyCursor(Long lastNotificationId, BooleanExpression where) { if (lastNotificationId != null) { where = where.and(notification.notificationId.lt(lastNotificationId)); } return where; }호출부:
- where = applyCursor(lastNotificationId, where, notification); + where = applyCursor(lastNotificationId, where);Also applies to: 27-27, 36-36, 45-45
23-30: 메서드명(…CreatedAtDesc)과 정렬 기준 불일치 가능 — 네이밍을 ID 기준으로 정리 권장메서드명이 OrderByCreatedAtDesc인데, 커서 전략이 PK(notificationId) 기준이면 혼동이 발생합니다. PK 기준을 유지할 경우 메서드명을 ID 기준으로 변경(권장)하거나, 실제로 createdAt 기준 정렬을 적용하세요. 호출부·인터페이스도 함께 갱신해야 합니다.
영향 범위(검색 결과):
- src/main/java/konkuk/thip/notification/adapter/out/persistence/repository/NotificationQueryRepository.java — 선언(라인 9,11,13)
- src/main/java/konkuk/thip/notification/adapter/out/persistence/repository/NotificationQueryRepositoryImpl.java — 구현(라인 23,33,42)
- src/main/java/konkuk/thip/notification/adapter/out/persistence/NotificationQueryPersistenceAdapter.java — 호출부(라인 25,32,39)
제안된 변경(diff 예시):
- public List<NotificationQueryDto> findFeedNotificationsOrderByCreatedAtDesc(Long userId, Long lastNotificationId, int pageSize) { + public List<NotificationQueryDto> findFeedNotificationsOrderByIdDesc(Long userId, Long lastNotificationId, int pageSize) { ... - public List<NotificationQueryDto> findRoomNotificationsOrderByCreatedAtDesc(Long userId, Long lastNotificationId, int pageSize) { + public List<NotificationQueryDto> findRoomNotificationsOrderByIdDesc(Long userId, Long lastNotificationId, int pageSize) { ... - public List<NotificationQueryDto> findFeedAndRoomNotificationsOrderByCreatedAtDesc(Long userId, Long lastNotificationId, int pageSize) { + public List<NotificationQueryDto> findFeedAndRoomNotificationsOrderByIdDesc(Long userId, Long lastNotificationId, int pageSize) {호출부·인터페이스 모두 함께 수정 필요.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Jira integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (2)
src/main/java/konkuk/thip/notification/adapter/in/web/NotificationQueryController.java(2 hunks)src/main/java/konkuk/thip/notification/adapter/out/persistence/repository/NotificationQueryRepositoryImpl.java(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- src/main/java/konkuk/thip/notification/adapter/in/web/NotificationQueryController.java
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
Learnt from: seongjunnoh
PR: THIP-TextHip/THIP-Server#113
File: src/main/java/konkuk/thip/recentSearch/adapter/out/persistence/RecentSearchCommandPersistenceAdapter.java:38-44
Timestamp: 2025-07-30T14:05:04.945Z
Learning: seongjunnoh는 코드 최적화 제안에 대해 구체적인 기술적 근거와 효율성 차이를 이해하고 싶어하며, 성능 개선 방식에 대한 상세한 설명을 선호한다.
Learnt from: seongjunnoh
PR: THIP-TextHip/THIP-Server#93
File: src/main/java/konkuk/thip/room/adapter/out/persistence/RoomQueryPersistenceAdapter.java:49-114
Timestamp: 2025-07-28T16:44:31.224Z
Learning: seongjunnoh는 코드 중복 문제에 대한 리팩토링 제안을 적극적으로 수용하고 함수형 인터페이스를 활용한 해결책을 선호한다.
Learnt from: seongjunnoh
PR: THIP-TextHip/THIP-Server#285
File: src/main/java/konkuk/thip/room/adapter/out/jpa/RoomStatus.java:1-7
Timestamp: 2025-08-31T05:25:14.845Z
Learning: seongjunnoh는 enum 의존성에 대해 유연한 접근을 선호하며, 도메인→어댑터 레이어 참조와 같은 아키텍처 layering 원칙보다 실용적인 구현을 우선시한다.
Learnt from: seongjunnoh
PR: THIP-TextHip/THIP-Server#195
File: src/main/java/konkuk/thip/feed/application/mapper/FeedQueryMapper.java:0-0
Timestamp: 2025-08-13T05:22:32.287Z
Learning: seongjunnoh는 데이터 무결성과 중복 방지에 대한 고민이 깊으며, LinkedHashSet을 활용한 중복 제거와 순서 보장을 동시에 달성하는 솔루션을 선호한다.
Learnt from: seongjunnoh
PR: THIP-TextHip/THIP-Server#305
File: src/main/java/konkuk/thip/notification/adapter/out/persistence/repository/NotificationQueryRepository.java:9-13
Timestamp: 2025-09-17T06:40:49.829Z
Learning: seongjunnoh는 메서드 네이밍 시 구현 세부사항보다 비즈니스 의도를 반영하는 것을 선호하며, 미래 확장성과 아키텍처 변화를 고려한 설계 철학을 가지고 있다.
Learnt from: seongjunnoh
PR: THIP-TextHip/THIP-Server#278
File: src/main/java/konkuk/thip/TestTokenController.java:0-0
Timestamp: 2025-08-24T09:33:52.982Z
Learning: seongjunnoh는 Spring의 ConditionalOnProperty 동작 원리를 정확히 이해하고 있으며, 보안 이슈에 대해서도 실질적인 위험성을 기준으로 판단하는 실용적 접근을 선호한다.
Learnt from: seongjunnoh
PR: THIP-TextHip/THIP-Server#278
File: src/main/java/konkuk/thip/common/exception/code/ErrorCode.java:210-211
Timestamp: 2025-08-24T09:40:48.595Z
Learning: seongjunnoh는 HTTP 상태 코드 선택에 대해 기술적 근거와 코드베이스 내 일관성을 중요하게 생각하며, 구체적인 사례 분석을 통한 설명을 선호한다.
Learnt from: seongjunnoh
PR: THIP-TextHip/THIP-Server#180
File: src/main/java/konkuk/thip/room/application/service/AttendanceCheckCreateService.java:22-40
Timestamp: 2025-08-14T09:15:31.371Z
Learning: seongjunnoh는 기술적 완벽성보다 실제 비즈니스 시나리오와 사용자 행동 패턴을 우선 고려하며, 발생 가능성이 낮은 엣지 케이스보다는 실용적인 구현을 선호한다.
Learnt from: seongjunnoh
PR: THIP-TextHip/THIP-Server#112
File: src/main/java/konkuk/thip/feed/adapter/out/persistence/repository/FeedQueryRepositoryImpl.java:272-272
Timestamp: 2025-07-30T10:44:34.115Z
Learning: seongjunnoh는 피드 커서 페이지네이션에서 LocalDateTime 단일 커서 방식을 선호하며, 복합 키 기반 커서보다 구현 단순성과 성능을 우선시한다.
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
🔇 Additional comments (1)
src/main/java/konkuk/thip/notification/adapter/out/persistence/repository/NotificationQueryRepositoryImpl.java (1)
58-65: 확인: QNotificationQueryDto 생성자 시그니처 일치NotificationQueryDto 레코드의 필드(순서·타입: Long, String, String, boolean, NotificationCategory, LocalDateTime)가 프로젝션에서 사용한 인자와 일치합니다.
| private List<NotificationQueryDto> getNotificationQueryDtos(int pageSize, QNotificationJpaEntity notification, BooleanExpression where) { | ||
| return queryFactory.select(new QNotificationQueryDto( | ||
| notification.notificationId, | ||
| notification.title, | ||
| notification.content, | ||
| notification.isChecked, | ||
| notification.notificationCategory, | ||
| notification.createdAt | ||
| )) | ||
| .from(notification) | ||
| .where(where) | ||
| .orderBy(notification.notificationId.desc()) // PK 기준 내림차순 (= 최신순) | ||
| .limit(pageSize + 1) | ||
| .fetch(); | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
pageSize 유효성 검사 및 +1 over-fetch 후처리 확인 필요
- pageSize가 0/음수일 때 방어 로직이 없습니다. 즉시 예외로 막는 편이 안전합니다.
limit(pageSize + 1)을 반환 그대로 노출하면 상위 계층에서 trim/hasNext 계산이 필요합니다. 어댑터/서비스에서 잘라내기와hasNext플래그 계산이 이루어지는지 확인 부탁드립니다.
+ private static int requirePositivePageSize(int pageSize) {
+ if (pageSize <= 0) throw new IllegalArgumentException("pageSize must be positive");
+ return pageSize;
+ }
...
- return getNotificationQueryDtos(pageSize, notification, where);
+ return getNotificationQueryDtos(requirePositivePageSize(pageSize), notification, where);상위 계층 검증/후처리 확인용:
🏁 Script executed:
#!/bin/bash
# pageSize 검증/hasNext 트리밍 구현 존재 여부 점검
rg -n 'hasNext|pageSize \+ 1|lastNotificationId|trim|subList' -C3 src/main/java/konkuk/thip/notification --type=javaLength of output: 14649
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# search for CursorBasedList and Cursor-related code in the repository
echo "Searching for CursorBasedList..."
rg -n "CursorBasedList" -S src || true
echo
echo "Searching for usages: CursorBasedList.of(...)"
rg -n "CursorBasedList.of\(" -S src || true
echo
echo "Searching for Cursor class inside notification package..."
rg -n "class Cursor" -S src/main/java/konkuk/thip/notification || true
echo
echo "Searching for getPageSize(...) in notification package..."
rg -n "getPageSize\(" -S src/main/java/konkuk/thip/notification || true
# show NotificationQueryPersistenceAdapter for context
echo
echo "=== src/main/java/konkuk/thip/notification/adapter/out/persistence/NotificationQueryPersistenceAdapter.java ==="
sed -n '1,240p' src/main/java/konkuk/thip/notification/adapter/out/persistence/NotificationQueryPersistenceAdapter.java || true
# try to locate and print CursorBasedList implementation if it exists
cb_file=$(rg -n --hidden "class CursorBasedList" -S src --files | head -n1 || true)
if [ -n "$cb_file" ]; then
echo
echo "=== $cb_file ==="
sed -n '1,240p' "$cb_file" || true
else
echo
echo "CursorBasedList implementation not found by name search."
fi
# try to locate a Cursor/domain Cursor class used by adapter
cursor_file=$(rg -n --hidden "class Cursor" -S src --files | rg "konkuk/thip/notification" -n || true)
if [ -n "$cursor_file" ]; then
echo
echo "=== First Cursor class under konkuk/thip/notification ==="
echo "$cursor_file"
sed -n '1,240p' "$(echo "$cursor_file" | sed -E 's/:.*//')" || true
else
echo
echo "No Cursor class file found under konkuk/thip/notification by name search."
fiLength of output: 46306
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "---- src/main/java/konkuk/thip/common/util/CursorBasedList.java ----"
sed -n '1,240p' src/main/java/konkuk/thip/common/util/CursorBasedList.java || true
echo
echo "---- src/main/java/konkuk/thip/common/util/Cursor.java ----"
sed -n '1,240p' src/main/java/konkuk/thip/common/util/Cursor.java || trueLength of output: 3828
pageSize는 양수여야 합니다 — Cursor 생성/처리 지점에서 검증 추가 필요
- 확인: over-fetch/hasNext 처리는 CursorBasedList.of(...)에서 이미 수행됨(contents는 subList로 trim, hasNext 계산, nextCursor는 contents.get(size - 1)).
- 문제: pageSize가 0 또는 음수이면 CursorBasedList.of(...)에서 contents.get(size - 1) 호출로 IndexOutOfBoundsException 발생 가능.
- 권장 조치: src/main/java/konkuk/thip/common/util/Cursor.java 의 from(...)에서 pageSize <= 0 검증(IllegalArgumentException) 추가. 추가 방어로 src/main/java/konkuk/thip/common/util/CursorBasedList.java 의 of(...) 시작부에서 size <= 0 검사 후 명확한 예외를 던지도록 변경.
🤖 Prompt for AI Agents
In src/main/java/konkuk/thip/common/util/Cursor.java around the from(...) method
and in src/main/java/konkuk/thip/common/util/CursorBasedList.java around the
of(...) method: validate that pageSize is strictly positive to prevent
downstream IndexOutOfBoundsException when over-fetch logic calls
contents.get(size - 1). Add a guard in Cursor.from(...) that throws
IllegalArgumentException if pageSize <= 0 with a clear message (e.g. "pageSize
must be > 0"), and add a defensive check at the start of CursorBasedList.of(...)
that throws IllegalArgumentException if the provided size or contents length is
<= 0 (or if after trimming there are no items) with a similarly clear message so
callers fail fast and avoid leaving IndexOutOfBounds for nextCursor calculation.
buzz0331
left a comment
buzz0331
left a comment
There was a problem hiding this comment.
확인했습니다! 리뷰라기보단 리팩토링 이슈에 가까운 얘기인 것 같네요,, 코드는 흠잡을데 없이 완벽한 것 같슴다~ 추가적으로 클라이언트 (푸쉬알림/알림 클릭시) 리다이렉트에 대한 부분은 어떻게 생각하고 계신지?
| @Parameter(hidden = true) @UserId final Long userId, | ||
| @Parameter(description = "커서 (첫번째 요청시 : null, 다음 요청시 : 이전 요청에서 반환받은 nextCursor 값)") | ||
| @RequestParam(value = "cursor", required = false) final String cursor, | ||
| @Parameter(description = "알림 타입. 해당 파라미터 값이 null인 경우에는 알림 타입을 구분하지 않고 조회합니다.", example = "feed or room") | ||
| @RequestParam(value = "type", required = false, defaultValue = "feedAndRoom") final String type |
There was a problem hiding this comment.
이것 제가 @ParameterObject 어노테이션을 활용하면 쿼리 파라미터도 dto로 관리할 수 있더라구요! PagingRequest 같은 dto로 페이징 관련 파라미터들을 정의해두면 편할 것 같아요!
나중에 리팩 포인트로 좋을 것 같아서 말해봅니다~
There was a problem hiding this comment.
좋은 아이디어 인것 같습니다!!
현준님 제안은 특정 api 의 request param 들을 dto 로 묶어서 관리하자 라는 건가요??
페이징 관련 파라미터는 cursor 하나만 있지 않나? 라는 생각이 들어서 여쭤봅니다!
There was a problem hiding this comment.
아 그렇네요! 저는 페이징 처리시에 단일 페이지 사이즈도 클라이언트로부터 받고있어서 세트로 착각했습니다! 네넵 request param을 dto로 묶어서 관리하자는 얘기였습니다~
| private static BooleanExpression applyCursor(Long lastNotificationId, BooleanExpression where, QNotificationJpaEntity notification) { | ||
| if (lastNotificationId != null) { | ||
| where = where.and(notification.notificationId.lt(lastNotificationId)); | ||
| } | ||
| return where; | ||
| } |
There was a problem hiding this comment.
최신순 정렬 커서를 id로 잡으셨군요! 굿굿 좋습니다. 현재 createdAt으로 잡혀있는 커서들도 Id로 리팩하는게 좋을 것 같네요,, 😟
| Cursor cursor = Cursor.from(cursorStr, PAGE_SIZE); | ||
|
|
||
| // 2. 커서 기반 조회 | ||
| CursorBasedList<NotificationQueryDto> result = switch (notificationType) { |
저는 알림센터 조회 response에 리다이렉트를 위한 데이터들까지 같이 포함하는것보다는 '알림 isChecked 값을 true로 만들기 + 리다이렉트를 위한 데이터 반환' 을 위한 api 를 추가적으로 구현하는게 더 좋다고 생각합니다!! 알림센터 조회 response에 데이터들을 포함하더라도 해당 알림을 클릭했는지 여부를 update하기 위해 어차피 클라이언트 <-> 서버간의 추가적인 api가 필요하므로 리다이렉트를 위한 데이터를 이 api 의 응답으로 반환하는게 더 맞는것 같습니다 또한 푸시알림을 유저가 바로 눌렀을 경우에도 마찬가지로 해당 api 를 호출함으로써 알림 isChecked 값을 true 로 만들도록 하면 될것 같습니다 저번에 현준님이랑 카톡나눈내용이랑 동일하기는 한데 관련해서 어떻게 생각하시나요? @buzz0331 @hd0rable |
저도 알림센터 조회 시에 바로 리다이렉트 정보를 포함하기보다는 실제 수신 확인(isChecked)을 했을 때 리다이렉트에 필요한 데이터를 분리해서 전달하는 구조가 더 명확하다고 생각합니다!! 단일 조회 API에서는 불필요하게 리다이렉트 데이터를 포함하지 않고, 실제로 유저가 알림을 눌러서 읽음 처리(isChecked=true)를 할 때만 리다이렉트 정보를 전달하는 게 구조적으로도 역할이 명확히 분리될 것 같아요. 그리고 말씀해주신 대로, 푸시알림 바로 클릭시에도 동일한 API를 통해 isChecked 값을 갱신하고, |
|
|
||
| private final JPAQueryFactory queryFactory; | ||
|
|
||
| private final QNotificationJpaEntity notification = QNotificationJpaEntity.notificationJpaEntity; |
엇 저도 성준님 말처럼 알림을 눌렀을 때 '읽음 표시 = true + 리다이렉트를 위한 데이터를 반환'하는 api를 호출해야 하는 것에 동의합니다! 다만, 제가 여쭤본 질문의 의도는 그 리다이렉트를 위한 데이터를 어떻게 저장할지에 대한 것이였습니다! 카톡에서 이 세 가지 방향을 고려하셨던 것으로 기억하는데, 현재 어떤 방식을 염두에 두고 계신지 궁금합니다! |
앗 이 부분은 아직 미정입니다ㅎ 빠른 구현을 위해서는 일단 2번으로 구현한 후 추후 리펙토링 하는 방식이 좋을 것 같지만, 일정에 여유가 있다면 좀 더 고민해볼 부분이라고 생각합니더(PM 님과도 얘기가 필요해보이네요) |
#️⃣ 연관된 이슈
📝 작업 내용
[주요 코드 설명]
📸 스크린샷
💬 리뷰 요구사항
PK 를 페이지네이션 커서로 설정한 부분을 확인해주세요!
알림센터 조회 api 의 응답에 특정 알림 클릭 시 해당 페이지로의 리다이렉트를 위해 필요한 데이터를 추가할지 말지는 아직 결정되지 않은 사항이어서 일단 알림센터 조회 기능에만 집중하여 구현하였습니다! 이 부분 참고해서 리뷰해주시면 감사하겠습니다
📌 PR 진행 시 이러한 점들을 참고해 주세요
Summary by CodeRabbit