[hotfix] 개발된 모든 api의 response inner class 네이밍 수정#239
Conversation
Walkthrough여러 API 응답 DTO의 내부 레코드 이름이 고유하도록 전반적으로 재명명되었고, 이에 맞춰 매퍼 및 서비스 반환/파라미터 타입이 변경되었습니다. 일부 DTO는 필드가 추가되어 스키마가 확장되었습니다. 로직 흐름 변경은 없고, 타입/시그니처 정합성 수정이 중심입니다. Changes
Sequence Diagram(s)Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Assessment against linked issues
Assessment against linked issues: Out-of-scope changes
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. ✨ Finishing Touches
🧪 Generate unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
Test Results399 tests 399 ✅ 30s ⏱️ Results for commit 890edbd. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (16)
src/main/java/konkuk/thip/user/adapter/in/web/response/UserSearchResponse.java (2)
8-16: Swagger 스키마 네이밍을 명시적으로 고정 권장 (@Schema 활용)이번 PR은 네이밍 충돌을 제거하지만, 향후 유사한 중첩 DTO가 생기면 다시 충돌 가능성이 있습니다. 스키마 이름을 명시적으로 고정해 Swagger 스키마 안정성을 높이는 것을 권장합니다.
다음과 같이 클래스(레코드) 레벨에 @Schema를 부여해 스키마 이름을 고정할 수 있습니다.
@@ - public record UserSearchDto( + @Schema(name = "UserSearchDto") + public record UserSearchDto( Long userId, String nickname, String profileImageUrl, String aliasName, String aliasColor, Integer followerCount ) { }파일 상단에 import 추가가 필요합니다(선택 적용):
import io.swagger.v3.oas.annotations.media.Schema;
18-20: 팩토리 메서드 시그니처 업데이트 일관성 확보 — LGTM외부 노출 타입 변경과 정합성이 맞춰졌습니다. 컬렉션 불변성 보장이 필요하다면 추후 Collections.unmodifiableList 적용을 고려할 수 있습니다(선택).
src/main/java/konkuk/thip/room/application/mapper/RoomQueryMapper.java (1)
31-33: MapStruct 레코드 매핑 검증 완료 — 문제 없음(단, null-safe 개선 권장)간단검증 결과:
- src/main/java/konkuk/thip/room/application/port/out/dto/RoomQueryDto.java 에 roomId, bookImageUrl, roomName, recruitCount(Integer), memberCount(Integer), endDate(LocalDate)가 동일 명칭으로 존재합니다.
- 타겟 레코드 src/main/java/konkuk/thip/room/adapter/in/web/response/RoomGetDeadlinePopularResponse.java::RoomGetDeadlinePopularDto는 recruitCount, memberCount를 primitive int로 선언합니다.
- 매퍼(src/main/java/konkuk/thip/room/application/mapper/RoomQueryMapper.java)는 deadlineDate만 expression으로 처리하고 나머지는 동일명 매핑에 의존합니다.
- 빌드파일(build.gradle)에서 MapStruct 버전은 org.mapstruct:mapstruct:1.5.5.Final로 확인되었습니다.
결론: RoomQueryDto의 canonical constructor에서 recruitCount/memberCount/endDate에 대해 Assert.notNull(...)로 null 불가를 보장하므로 Integer→int unboxing으로 인한 런타임 NPE 발생 가능성은 낮습니다. 따라서 치명적 오류는 아닙니다.
권장(선택적 리팩토링):
- deadlineDate를 더 안전하게 처리 (방어적 코딩):
@mapping(target = "deadlineDate", expression = "java(dto.endDate() == null ? null : DateUtil.formatAfterTime(dto.endDate()))")- 전체 매핑에 대해 널 체크를 강화하려면 Mapper에 nullValueCheckStrategy 추가:
@Mapper(componentModel = "spring", imports = DateUtil.class, unmappedTargetPolicy = ReportingPolicy.IGNORE, nullValueCheckStrategy = NullValueCheckStrategy.ALWAYS)- 필드명이 달라지거나 의도를 명시적으로 드러내고 싶다면 recruitCount/memberCount 등도 명시적 @mapping 추가 (현재는 불필요).
수정이 필요하거나 의심되는 부분:
- src/main/java/konkuk/thip/room/application/mapper/RoomQueryMapper.java — toDeadlinePopularRoomDto 메서드 (deadlineDate 표현식에 대한 방어적 처리 검토)
요약: 확인 결과 즉각적인 수정은 필요하지 않으나, 방어적 null 체크(특히 DateUtil.formatAfterTime 호출부)는 권장됩니다. [optional_refactors_recommended]
src/main/java/konkuk/thip/feed/adapter/in/web/response/FeedShowAllResponse.java (1)
5-6: Swagger 스키마 이름을 명시적으로 고정해 주세요 (@Schema 추가 권장)FeedShowByUserResponse와의 문서화 일관성 및 미래 충돌 방지를 위해, 응답 레코드/내부 레코드/필드에 @Schema를 부여해 스키마 이름과 설명을 명시적으로 고정하는 것을 권장합니다.
적용 제안(diff):
- public record FeedShowAllResponse( - List<FeedShowAllDto> feedList, +@Schema(description = "전체 피드 목록 조회 응답 DTO") +public record FeedShowAllResponse( + @Schema(description = "조회된 피드 목록") + List<FeedShowAllDto> feedList, String nextCursor, boolean isLast ) { - public record FeedShowAllDto( + @Schema(name = "FeedShowAllDto", description = "피드 단일 항목 정보") + public record FeedShowAllDto( Long feedId, Long creatorId, String creatorNickname, String creatorProfileImageUrl, String aliasName, String aliasColor, String postDate, String isbn, String bookTitle, String bookAuthor, String contentBody, String[] contentUrls, int likeCount, int commentCount, boolean isSaved, boolean isLiked, boolean isWriter ) { } }추가: import 문이 필요합니다.
import io.swagger.v3.oas.annotations.media.Schema;Also applies to: 10-10
src/main/java/konkuk/thip/feed/adapter/in/web/response/FeedShowByUserResponse.java (1)
19-20: 스키마 명 고정으로 Swagger 충돌 가능성 추가 차단이미 @Schema가 있으므로 name 속성을 추가해 스키마 이름을 명시적으로 고정하는 것을 권장합니다.
적용 제안(diff):
- @Schema(description = "피드 단일 항목 정보") - public record FeedShowByUserDto( + @Schema(name = "FeedShowByUserDto", description = "피드 단일 항목 정보") + public record FeedShowByUserDto(src/main/java/konkuk/thip/feed/application/mapper/FeedQueryMapper.java (2)
35-41: 반환 타입 교체 OK, 메서드 네이밍만 미세 조정 제안
FeedShowAllResponse.FeedShowAllDto로의 전환은 네이밍 충돌 해소 목적에 부합합니다. 메서드명이toFeedShowAllResponse인 반면 반환은 단일 아이템 DTO이므로, 추후 혼동 방지를 위해toFeedShowAllDto등으로의 네이밍 정리를 고려할 수 있습니다. (선택)
46-47: 메서드 명이 반환물과 더 잘 매치되도록 경량 네이밍 제안
toFeedShowMineResponse는 실제로 DTO 리스트를 반환합니다.toFeedShowMineDtos또는toFeedShowMineList등으로의 네이밍 변경을 고려해 보세요. (코드 독해성 관점, 기능 영향 없음)src/main/java/konkuk/thip/book/adapter/in/web/response/BookRecruitingRoomsResponse.java (2)
5-10: 불리언 필드 네이밍 일관성 권고: isLast → last로 노출동일 리소스 계열의 응답에서 불리언 필드가 BookSearchListResponse는 last/first, 본 타입은 isLast로 혼재되어 있습니다. Swagger/클라이언트 스키마 일관성을 위해 JSON 프로퍼티는 last로 통일하는 것을 권장합니다. 내부 필드명은 유지하되 직렬화 이름만 맞추려면 @JsonProperty 사용이 안전합니다.
다음 변경을 적용하면 JSON 키를 "last"로 고정할 수 있습니다:
- public record BookRecruitingRoomsResponse( - List<BookRecruitingRoomDto> recruitingRoomList, - Integer totalRoomCount, - String nextCursor, - boolean isLast - ) { + public record BookRecruitingRoomsResponse( + List<BookRecruitingRoomDto> recruitingRoomList, + Integer totalRoomCount, + String nextCursor, + @JsonProperty("last") boolean isLast + ) {또한 import를 추가해야 합니다(파일 상단):
import com.fasterxml.jackson.annotation.JsonProperty;기존 클라이언트가 "isLast"를 파싱하고 있다면 영향 범위를 꼭 확인해 주세요.
원한다면 양쪽 키("isLast"와 "last")를 동시에 지원하는 백워드 호환 전략도 제안드릴 수 있습니다.
15-23: Swagger 스키마 이름 명시적 고정 제안레코드 이름 변경이나 리팩토링과 무관하게 OpenAPI 스키마 이름을 안정적으로 유지하려면
@Schema(name=…)어노테이션을 추가하는 것을 권장합니다.
- 적용 대상:
- src/main/java/konkuk/thip/book/adapter/in/web/response/BookRecruitingRoomsResponse.java
변경 예시:
--- a/src/main/java/konkuk/thip/book/adapter/in/web/response/BookRecruitingRoomsResponse.java +++ b/src/main/java/konkuk/thip/book/adapter/in/web/response/BookRecruitingRoomsResponse.java @@ + import io.swagger.v3.oas.annotations.media.Schema; import com.fasterxml.jackson.annotation.JsonProperty; - public record BookRecruitingRoomsResponse( + @Schema(name = "BookRecruitingRoomsResponse") + public record BookRecruitingRoomsResponse( List<BookRecruitingRoomDto> recruitingRoomList, Integer totalRoomCount, String nextCursor, @JsonProperty("last") boolean isLast ) { @@ - public record BookRecruitingRoomDto( + @Schema(name = "BookRecruitingRoomDto") + public record BookRecruitingRoomDto( Long roomId, String bookImageUrl, String roomName, int memberCount, int recruitCount, String deadlineEndDate ) {검증 결과, 레거시 타입명
RecruitingRoomDto에 대한 잔여 참조는 코드베이스에 존재하지 않습니다.
위 어노테이션 추가로 Swagger 스키마 이름을 명시적으로 고정해 주세요.
[optional_refactors_recommended]src/main/java/konkuk/thip/book/adapter/in/web/response/BookSearchListResponse.java (3)
18-23: 빈 결과 페이지 처리 가독성 개선 제안(경미)현재 구현은 totalElements가 0일 때도 last가 true가 되지만, 의도를 드러내면 이해가 쉬워집니다.
- boolean last = (page >= totalPages); + boolean last = (totalPages == 0) || (page >= totalPages);기능적 차이는 없고 의사 표현만 명확해집니다.
38-54: Swagger 스키마 이름 고정 권고: @Schema(name=…) 애노테이션 추가레거시
BookDto참조는 검색 결과 남아있지 않습니다.다음과 같이 스키마 이름을 명시적으로 고정해 충돌을 예방하세요:
• 파일:
src/main/java/konkuk/thip/book/adapter/in/web/response/BookSearchListResponse.java@@ - public record BookSearchListResponse( + @Schema(name = "BookSearchListResponse") + public record BookSearchListResponse( List<BookSearchDto> searchResult, int page, int size, long totalElements, int totalPages, boolean last, boolean first ) { @@ - public record BookSearchDto( + @Schema(name = "BookSearchDto") + public record BookSearchDto( String title, String imageUrl, String authorName, String publisher, String isbn ) {• 필요한 import:
import io.swagger.v3.oas.annotations.media.Schema;[optional_refactors_recommended]
9-17: 페이지네이션 Boolean 키 네이밍 일관화 검토 필요응답 DTO 전반에 last/first와 isLast/isFirst가 혼재되어 있어 JSON 스펙 관점에서 혼선을 야기할 수 있습니다. 아래 대표 사례를 참고해 필드명 또는 @JsonProperty 노출명을 일관화해 주세요.
- src/main/java/konkuk/thip/book/adapter/in/web/response/BookSearchListResponse.java — boolean last, first
- src/main/java/konkuk/thip/room/adapter/in/web/response/RoomGetHomeJoinedListResponse.java — boolean last, first
- src/main/java/konkuk/thip/user/adapter/in/web/response/UserFollowingResponse.java — boolean isLast
- src/main/java/konkuk/thip/room/adapter/in/web/response/RoomShowMineResponse.java — boolean isLast
- src/main/java/konkuk/thip/comment/adapter/in/web/response/CommentForSinglePostResponse.java — boolean isLast
또한 BookSearchListResponse는 size가 PAGE_SIZE 상수로 고정되어 있으므로, 호출부에서 가변 페이지 크기를 지원해야 하는 경우 of(...) 시 size 파라미터를 함께 전달하도록 확장할지 검토 부탁드립니다.
src/main/java/konkuk/thip/roompost/application/mapper/RoomPostQueryMapper.java (1)
30-30: 메서드명도 의미 반영: toRoomPostSearchDto로 rename 제안리턴 타입이 명확히 ‘검색 DTO’이므로 메서드명을 toRoomPostSearchDto로 바꾸면 호출부 가독성이 좋아집니다. 변경 영향이 넓다면 이번 PR에 묶지 않고 후속 리팩토링으로도 충분합니다.
src/main/java/konkuk/thip/roompost/adapter/in/web/response/RoomPostSearchResponse.java (1)
17-17: Swagger 스키마 이름을 고정해 중복 가능성 추가 차단 (@Schema 권장)리네이밍만으로도 충분할 수 있으나, 스키마 명을 명시해두면 향후 동일/유사 이름 충돌을 구조적으로 방지할 수 있습니다. springdoc-openapi 사용 시 아래처럼 @Schema로 명시 이름을 부여하는 것을 권장합니다.
적용 예시 (변경 라인 내 diff):
- public record RoomPostSearchDto( + @Schema(name = "RoomPostSearchItem") + public record RoomPostSearchDto(추가 import (파일 상단에 추가):
import io.swagger.v3.oas.annotations.media.Schema;중첩 DTO에도 명시 이름 부여 권장 (선택):
@Schema(name = "RoomPostSearchItemVote") public record VoteItemDto( Long voteItemId, String itemName, int percentage, boolean isVoted ) { ... }src/main/java/konkuk/thip/roompost/application/service/RoomPostSearchService.java (2)
145-147: 주석 최신화 필요 (참조 대상 클래스명 변경 반영)구 주석이 RecordSearchResponse를 가리킵니다. 최신 타입명으로 맞춰 주세요.
적용 diff:
- // VoteItemQueryDto 목록을 RecordSearchResponse.PostDto.VoteItemDto 목록으로 변환하는 메서드 + // VoteItemQueryDto 목록을 RoomPostSearchResponse.RoomPostSearchDto.VoteItemDto 목록으로 변환하는 메서드 private List<RoomPostSearchResponse.RoomPostSearchDto.VoteItemDto> mapToVoteItemDtos(List<VoteItemQueryDto> items, boolean isLocked) {
89-99: 미세 성능 개선: VOTE 게시물이 없을 때 불필요한 조회 스킵현재 voteQueryPort.findVoteItemsByVoteIds(...)는 빈 Set에 대해서도 호출됩니다. 데이터소스에서 IN () 형태 최적화가 되지 않는 경우 불필요한 round-trip이 발생할 수 있습니다. VOTE 게시물이 없을 때는 맵 생성 자체를 생략하는 단순 가드로 비용을 줄일 수 있습니다.
예시 리팩터링(개념 코드):
var votePostIds = cursorBasedList.contents().stream() .filter(p -> VOTE.getType().equals(p.postType())) .map(RoomPostQueryDto::postId) .collect(Collectors.toSet()); Map<Long, List<VoteItemQueryDto>> voteItemQueryMap = votePostIds.isEmpty() ? Map.of() : voteQueryPort.findVoteItemsByVoteIds(votePostIds, userId);Also applies to: 108-111
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (18)
src/main/java/konkuk/thip/book/adapter/in/web/response/BookRecruitingRoomsResponse.java(1 hunks)src/main/java/konkuk/thip/book/adapter/in/web/response/BookSearchListResponse.java(3 hunks)src/main/java/konkuk/thip/book/application/mapper/BookQueryMapper.java(1 hunks)src/main/java/konkuk/thip/feed/adapter/in/web/response/FeedShowAllResponse.java(1 hunks)src/main/java/konkuk/thip/feed/adapter/in/web/response/FeedShowByUserResponse.java(2 hunks)src/main/java/konkuk/thip/feed/adapter/in/web/response/FeedShowMineResponse.java(1 hunks)src/main/java/konkuk/thip/feed/application/mapper/FeedQueryMapper.java(3 hunks)src/main/java/konkuk/thip/feed/application/service/BasicFeedShowAllService.java(1 hunks)src/main/java/konkuk/thip/feed/application/service/FeedShowAllOfUserService.java(1 hunks)src/main/java/konkuk/thip/feed/application/service/FollowingPriorityFeedShowAllService.java(1 hunks)src/main/java/konkuk/thip/room/adapter/in/web/response/RoomGetDeadlinePopularResponse.java(2 hunks)src/main/java/konkuk/thip/room/application/mapper/RoomQueryMapper.java(1 hunks)src/main/java/konkuk/thip/roompost/adapter/in/web/response/RoomPostSearchResponse.java(1 hunks)src/main/java/konkuk/thip/roompost/application/mapper/RoomPostQueryMapper.java(1 hunks)src/main/java/konkuk/thip/roompost/application/service/RoomPostSearchService.java(4 hunks)src/main/java/konkuk/thip/user/adapter/in/web/response/UserSearchResponse.java(2 hunks)src/main/java/konkuk/thip/user/adapter/in/web/response/UserSignupResponse.java(1 hunks)src/main/java/konkuk/thip/user/application/mapper/UserQueryMapper.java(1 hunks)
🧰 Additional context used
🧠 Learnings (2)
📓 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#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#180
File: src/main/java/konkuk/thip/room/application/service/AttendanceCheckCreateService.java:22-40
Timestamp: 2025-08-14T09:15:31.332Z
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 단일 커서 방식을 선호하며, 복합 키 기반 커서보다 구현 단순성과 성능을 우선시한다.
📚 Learning: 2025-07-14T14:19:38.796Z
Learnt from: buzz0331
PR: THIP-TextHip/THIP-Server#75
File: src/main/java/konkuk/thip/vote/adapter/out/persistence/VoteQueryRepositoryImpl.java:50-83
Timestamp: 2025-07-14T14:19:38.796Z
Learning: Vote와 VoteItem 엔티티는 자주 함께 사용되므로, N+1 문제를 방지하기 위해 양방향 매핑과 fetch join을 고려하는 것이 좋습니다. 특히 기록장 조회 API 등에서도 함께 사용될 가능성이 높습니다.
Applied to files:
src/main/java/konkuk/thip/roompost/application/service/RoomPostSearchService.java
⏰ 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 (26)
src/main/java/konkuk/thip/user/adapter/in/web/response/UserSignupResponse.java (1)
5-11: 포맷팅 변경만 존재 — 기능적 변화 없음, LGTM외부 API 시그니처나 팩토리 메서드는 그대로입니다. 변경 의도와 무해성 측면에서 문제 없습니다.
src/main/java/konkuk/thip/user/adapter/in/web/response/UserSearchResponse.java (1)
6-7: 중첩 DTO를 UserSearchDto로 명확히 분리 — 네이밍 충돌 방지에 부합, LGTMPR 목적(중복 inner class 네이밍 제거)에 정확히 부합합니다. 외부 스키마도 더 의미 있는 이름으로 노출됩니다.
src/main/java/konkuk/thip/user/application/mapper/UserQueryMapper.java (1)
13-15: MapStruct 매핑 정합성 확인 완료
- 기존
UserSearchResponse.UserDto잔존 참조 없음UserQueryDto에aliasName,aliasColor,followerCount필드 모두 존재필드명이 DTO와 정확히 일치하므로 MapStruct가 자동으로 매핑하며 컴파일 오류가 발생하지 않습니다.
추가적으로 단건 매핑 메서드UserSearchResponse.UserSearchDto toUserSearchDto(UserQueryDto dto);를 정의하면 리스트 매핑 자동 생성 시 가독성·유연성이 향상될 수 있습니다(선택 사항).
src/main/java/konkuk/thip/room/adapter/in/web/response/RoomGetDeadlinePopularResponse.java (3)
6-7: 중복 네이밍 충돌 해소에 적절한 변경리스트 항목 타입을
RoomGetDeadlinePopularDto로 명확히 분리해 Swagger 스키마 충돌 가능성을 줄였습니다. PR 목적과 일치합니다.
19-21: 팩토리 메서드 시그니처 갱신 적절
of(...)가 새 DTO 리스트를 그대로 위임 생성하여 호출부 영향 최소화. 문제 없습니다.
9-16: primitive int 사용은 안전합니다
현재recruitCount·memberCount는
- JPA 엔티티(
RoomJpaEntity)에서@Column(nullable = false)로 선언된int필드- QueryDSL 조회 시
count()나 DB 컬럼(Non‐NULL)에서 가져오는 값으로 매핑- Out DTO(
RoomQueryDto)에서는Integer로 받고Assert.notNull()으로 null 방지
과정에서 null이 허용되지 않으므로 primitiveint언박싱 NPE 발생 가능성이 없습니다.
기존int타입을 유지하셔도 좋습니다.Likely an incorrect or invalid review comment.
src/main/java/konkuk/thip/feed/adapter/in/web/response/FeedShowAllResponse.java (1)
6-6: LGTM: 중복 방지 목적의 DTO 이름 변경이 잘 반영되었습니다feedList 제네릭 타입을 FeedShowAllDto로 변경해 Swagger 스키마 충돌 가능성을 줄였습니다.
src/main/java/konkuk/thip/feed/adapter/in/web/response/FeedShowByUserResponse.java (2)
10-10: LGTM: 고유 DTO 타입으로의 변경이 목적에 부합합니다feedList 타입을 FeedShowByUserDto로 교체하여 Swagger 상의 중복 스키마 문제를 해소합니다.
19-33: 매퍼 구현체에서 확장 필드 매핑 누락 여부 확인 요청
MapStruct가 생성한FeedQueryMapperImpl(자동 생성된 매퍼 구현체)에서 다음 필드가 모두FeedShowByUserDto에 매핑되었는지 직접 검증해 주세요:
- isbn
- bookTitle
- bookAuthor
- contentBody
- contentUrls
- likeCount
- commentCount
- isPublic
- isSaved
- isLiked
- isWriter
src/main/java/konkuk/thip/feed/application/service/FollowingPriorityFeedShowAllService.java (1)
54-56: LGTM: 내부 DTO 타입 변경 반영 완료스트림 매핑 결과 타입을 FeedShowAllDto로 맞춰 응답 스키마와 정합성이 확보되었습니다.
src/main/java/konkuk/thip/feed/application/service/FeedShowAllOfUserService.java (1)
62-64: LGTM: 타입 교체로 스키마 중복 해소FeedShowByUserDto 사용으로 응답 구조가 최신 스키마와 일치합니다.
src/main/java/konkuk/thip/feed/application/service/BasicFeedShowAllService.java (1)
55-57: LGTM: 기본 전략 서비스도 일관되게 타입 변경 적용FeedShowAllDto로의 교체가 잘 반영되어 API 간 응답 DTO 네이밍 일관성이 확보되었습니다.
src/main/java/konkuk/thip/feed/adapter/in/web/response/FeedShowMineResponse.java (2)
6-6: LGTM — 네이밍 충돌 해소를 위한 타입 변경이 목적에 정확히 부합합니다
feedList의 제네릭을FeedShowMineDto로 변경하여 Swagger 스키마 충돌 가능성을 제거했습니다. 변경 자체는 문제없습니다.
10-22: FeedShowMineDto 매핑 누락 이슈 없음 확인 완료
FeedQueryDto에 아래 필드가 모두 존재하며 타입도 일치합니다
• isbn (String)
• bookTitle (String)
• bookAuthor (String)
• contentBody (String)
• contentUrls (String[])
• likeCount (int)
• commentCount (int)
• isPublic (boolean)toFeedShowMineDto 매핑에서는
• postDate:@Mapping(..., expression = "java(DateUtil.formatBeforeTime(dto.createdAt()))")
• isWriter:@Mapping(target = "isWriter", source = "dto.creatorId", qualifiedByName = "isWriter")
나머지 필드는 이름·타입 일치에 따라 자동 매핑되므로 누락될 걱정이 없습니다.src/main/java/konkuk/thip/feed/application/mapper/FeedQueryMapper.java (2)
55-60: 확인 완료 — 옛 타입 참조 없음, 새 DTO 일관성 유지됨
FeedShowByUserResponse.FeedDto에 대한 잔여 참조가 발견되지 않았으며, 모든 매퍼 및 서비스 계층에서 새 타입인FeedShowByUserResponse.FeedShowByUserDto를 일관되게 사용하고 있음을 확인했습니다.
42-45: 검증 완료 — FeedQueryDto와 자동 매핑에 문제 없음간단 검증 결과: toFeedShowMineDto에서 수동 매핑한 postDate/isWriter 외의 필드는 FeedQueryDto에 동일한 이름·타입으로 존재하고, FeedQueryRepositoryImpl.toDto(...)에서 모두 채워지고 있습니다. 따라서 현재 자동 매핑으로 인한 누락 위험은 없습니다.
주의/참고 사항:
- 확인된 위치
- src/main/java/konkuk/thip/feed/application/port/out/dto/FeedQueryDto.java — feedId, createdAt, isbn, bookTitle, bookAuthor, contentBody, String[] contentUrls, int likeCount, int commentCount, boolean isPublic 등 선언됨.
- src/main/java/konkuk/thip/feed/adapter/out/persistence/repository/FeedQueryRepositoryImpl.java — toDto(...)에서 모든 해당 필드(contentUrls, contentBody, likeCount, commentCount, isbn 등)를 채워서 FeedQueryDto.builder(...)로 빌드(약식: 268~).
- src/main/java/konkuk/thip/feed/application/mapper/FeedQueryMapper.java — toFeedShowMineDto는 postDate와 isWriter만 명시 매핑(원본 위치: 해당 매퍼의 매핑 선언).
- src/main/java/konkuk/thip/post/domain/service/PostCountService.java 및 Post/Feed 엔티티들 — likeCount/commentCount는 현재 int/Integer 계열로 사용됨(오버플로우 위험은 현재 구조상 낮음).
권고(선택): 향후 데이터 규모(매우 큰 DB 집계 등)가 커질 가능성이 있다면 likeCount/commentCount를 int → long로 변경하는 것을 검토하세요(단기적으로는 불필요).
src/main/java/konkuk/thip/book/adapter/in/web/response/BookRecruitingRoomsResponse.java (1)
11-13: 정적 팩토리 시그니처 변경 LGTM리스트 제네릭 타입을 BookRecruitingRoomDto로 교체한 변경과 반환 생성은 일관적입니다.
src/main/java/konkuk/thip/book/application/mapper/BookQueryMapper.java (2)
27-28: 리스트 매핑 메서드 시그니처 정합성 LGTM요소 타입 변경과 메서드 시그니처는 상위 변경과 일치합니다. MapStruct가 요소 매핑을 자동 위임하므로 추가 설정 없이 동작합니다.
21-25: 암묵적 매핑 검증 완료: 누락된 필드 없음RoomQueryDto(record)와 BookRecruitingRoomDto(record)의 컴포넌트 이름·타입이 완전히 일치해, 현재 @mapping(expression)으로 설정된
deadlineEndDate외 나머지 필드는 implicit 매핑만으로도 모두 정상적으로 채워집니다.
명시적 @mapping 추가는 향후 리네이밍 시 안전을 높이는 권장 사항일 뿐, 현 단계에서는 필수 변경이 아닙니다.
unmappedTargetPolicy=IGNORE 설정 상태에서 문제없이 동작하며, 필요 시 WARN/ERROR로 격상해 검증 강도를 높이는 것도 고려 가능합니다.src/main/java/konkuk/thip/book/adapter/in/web/response/BookSearchListResponse.java (1)
24-30: 스트림 매핑 및 변수명 변경 LGTMBookSearchDto::of 매핑과 변수명(bookSearchDtos) 정합성이 좋습니다. toList() 사용도 적절합니다.
src/main/java/konkuk/thip/roompost/application/mapper/RoomPostQueryMapper.java (1)
30-36: 타입 리네이밍 반영 적절. MapStruct 설정과 함께 컴파일 타임 정합성 보장됨반환/파라미터 타입을 RoomPostSearchDto 계열로 일관되게 치환했고, unmappedTargetPolicy = ERROR 덕분에 누락 매핑은 컴파일 타임에 잡힙니다. DateUtil 표현식도 기존과 동일하게 동작합니다. LGTM.
src/main/java/konkuk/thip/roompost/adapter/in/web/response/RoomPostSearchResponse.java (1)
9-9: 내부 DTO 리네이밍으로 Swagger 충돌 해소 기대postList 요소 타입을 RoomPostSearchDto로 명시하여 스키마 네이밍 충돌 가능성을 낮췄습니다. 의도에 부합합니다. LGTM.
src/main/java/konkuk/thip/roompost/application/service/RoomPostSearchService.java (4)
108-111: 타입 치환 적절. 매퍼/DTO 일관성 유지됨변수 및 호출부 타입을 RoomPostSearchDto.VoteItemDto로 치환한 부분 문제없습니다. 매퍼 시그니처와도 일치합니다.
136-143: 시그니처 타입 치환 문제없음getVoteItemDtosIfApplicable의 반환 타입을 새 DTO로 치환한 부분 이상 없습니다.
157-163: of(...) 사용처 타입 치환 적절RoomPostSearchResponse.RoomPostSearchDto.VoteItemDto.of(...)로 변경되어 일관성 유지됩니다. 비즈니스 로직 변경 없음 확인.
108-111: 검증 완료: 구형 타입 참조 및 중복 record 네이밍 없음 ✅
–RoomPostSearchResponse.RoomPostDto등 구형 타입 참조가 전혀 없습니다.
– 모든*Response.java파일에서 record 이름 중복이 발견되지 않았습니다.이상 없으므로 해당 검증을 종료합니다.
seongjunnoh
deleted the
hotfix/#237-all-api-response-inner-class-naming
branch
1 participant
#️⃣ 연관된 이슈
📝 작업 내용
api response의 inner class 의 이름이 같을 경우, 스웨거가 이를 제대로 구분하지 못하여 FE분들에게 혼동을 드리는 일이 계속 발생하고 있었습니다.
따라서 지금까지 개발된 모든 api들의 response에 대해서 이름이 동일한 inner class의 네이밍을 수정하였습니다
📸 스크린샷
💬 리뷰 요구사항
📌 PR 진행 시 이러한 점들을 참고해 주세요
Summary by CodeRabbit