Hotfix/mateboard: 게시글 좋아요, 댓글 좋아요 배열 반영#179
Conversation
| @RestController | ||
| @RequiredArgsConstructor | ||
| @RequestMapping("/api/v1/mates/comments") | ||
| @RequestMapping("/api/v1/mateposts/comments") |
There was a problem hiding this comment.
API 경로가 /api/v1/mates/comments 에서 /api/v1/mateposts/comments 로 변경되었습니다. /mateposts 라는 용어가 더 적절한지 확인하고, 변경 이유를 명시적으로 commit message에 추가해주세요. 다른 부분과의 일관성도 확인해야 합니다.
| @@ -0,0 +1,16 @@ | |||
| package com.frend.planit.domain.mateboard.comment.dto.response; | |||
There was a problem hiding this comment.
새로운 DTO CommentLikeInfo가 추가되었습니다. authorId와 commentId를 사용하는 목적을 명확히 주석으로 설명해주세요. javadoc 스타일 주석을 사용하는 것이 좋습니다.
|
|
||
| private final String content; | ||
|
|
||
| private final List<CommentLikeInfo> commentLike; |
There was a problem hiding this comment.
MateCommentResponseDto에 commentLike 필드가 추가되었습니다. List<CommentLikeInfo> 타입을 사용하는 이유와 null 가능성 처리에 대한 고려사항을 추가해주세요. 필요하다면 @NotNull과 같은 어노테이션을 사용하는 것도 고려해보세요.
| @Column(nullable = false) | ||
| private String content; | ||
|
|
||
| @OneToMany(mappedBy = "mateComment", cascade = CascadeType.ALL, orphanRemoval = true) |
There was a problem hiding this comment.
MateComment 엔티티에 commentLikes 필드가 추가되었습니다. CascadeType.ALL과 orphanRemoval = true를 사용하는 이유를 명확히 설명해주세요. 관계 설정의 의도와 잠재적인 문제점(예: 무한 루프, 성능 저하)에 대한 고려사항을 추가하는 것이 좋습니다.
| public class MateCommentMapper { | ||
|
|
||
| public static MateCommentResponseDto toResponseDto(MateComment comment) { | ||
| public static MateCommentResponseDto toResponseDto(MateComment comment, |
There was a problem hiding this comment.
MateCommentMapper의 toResponseDto 메서드가 수정되었습니다. 기존 메서드가 삭제되고, commentLike 리스트를 파라미터로 받는 새로운 메서드가 추가되었습니다. 기존의 // TODO: 좋아요 수 추가 부분은 제거되었는데, 좋아요 수를 추가할 필요가 없어진 이유를 설명해주세요. 또한, 기본값으로 빈 리스트를 전달하는 오버로딩 메서드를 추가한 부분은 필요성을 재고해볼 필요가 있습니다. 빈 리스트를 전달하는 경우와 실제 데이터가 있는 경우의 차이점을 고려하여 더 효율적인 방법을 찾아보는 것이 좋습니다.
| Page<MateComment> comments = mateCommentRepository.findAllByMate(mate, pageable); | ||
| // 3. Entity -> DTO 변환 | ||
| Page<MateCommentResponseDto> dtoPage = comments.map(MateCommentMapper::toResponseDto); | ||
| // 3. Entity -> DTO 변환 (commentLike 포함) |
There was a problem hiding this comment.
MateCommentService의 comments를 MateCommentResponseDto로 변환하는 부분이 수정되었습니다. 이제 commentLikes 정보를 포함하여 변환하는데, 이 변경으로 인해 성능에 미치는 영향을 고려해보아야 합니다. 필요하다면 stream().parallel()을 사용하여 병렬 처리를 고려해 볼 수 있지만, 그로 인한 잠재적인 문제점(예: race condition)도 함께 고려해야 합니다. 또한, commentLikes를 매핑하는 부분을 더 효율적으로 개선할 수 있는지 확인해주세요.
| @@ -0,0 +1,16 @@ | |||
| package com.frend.planit.domain.mateboard.post.dto.response; | |||
There was a problem hiding this comment.
댓글 좋아요 정보를 담는 DTO인 CommentLikeInfo가 추가되었지만, 이미 com.frend.planit.domain.mateboard.comment.dto.response.CommentLikeInfo가 존재합니다. 중복 정의인지, 의도적으로 다른 패키지에 동일한 이름의 DTO를 생성한 것인지 확인해야 합니다. 만약 중복이라면, 하나로 통합하거나 이름을 변경하는 것을 고려해야 합니다. 주석에서 '댓글' 과 '게시글' 용어의 혼용을 정리해야 합니다.
| @@ -0,0 +1,16 @@ | |||
| package com.frend.planit.domain.mateboard.post.dto.response; | |||
There was a problem hiding this comment.
새로운 DTO MateApplicationInfo가 추가되었습니다. authorId와 applicationId의 의미를 명확하게 주석으로 설명하고, javadoc 스타일 주석을 사용하는 것이 좋습니다.
| private final int likeCount; | ||
| private final LocalDateTime createdAt; | ||
| private boolean isApplied; | ||
| private final boolean isApplied; |
There was a problem hiding this comment.
MateResponseDto에 isApplied, postLike, mateApplications 필드가 추가되었습니다. final 키워드를 사용하여 변경 불가능하게 만든 이유와 각 필드의 null 가능성 처리에 대한 고려사항을 추가해주세요. 필요에 따라 @NotNull 등의 어노테이션을 사용할 수 있습니다. 또한 Builder 패턴을 사용하는 이유도 명시적으로 설명하는 것이 좋습니다.
| @@ -0,0 +1,16 @@ | |||
| package com.frend.planit.domain.mateboard.post.dto.response; | |||
There was a problem hiding this comment.
새로운 DTO PostLikeInfo가 추가되었습니다. authorId와 matePostId의 의미를 명확하게 주석으로 설명하고, javadoc 스타일 주석을 사용하는 것이 좋습니다.
| @OneToMany(mappedBy = "mate", cascade = CascadeType.ALL, orphanRemoval = true) | ||
| private List<MateApplication> applications = new ArrayList<>(); | ||
|
|
||
| @OneToMany(mappedBy = "matePost", fetch = FetchType.LAZY) |
There was a problem hiding this comment.
Mate 엔티티에 postLikes 필드가 추가되었습니다. FetchType.LAZY를 사용한 이유와 postLikes 리스트의 관리에 대한 고려사항(예: CascadeType 설정)을 명확히 주석으로 설명해주세요. lazy loading으로 인한 N+1 문제 발생 가능성을 고려하고, 필요하다면 @Fetch 어노테이션 사용 또는 JPQL 쿼리 최적화를 고려해야 합니다.
| * @return MateResponseDto 변환 결과 | ||
| */ | ||
| public static MateResponseDto toResponseDto(Mate mate, String imageUrl, boolean isApplied) { | ||
| public static MateResponseDto toResponseDto(Mate mate, String imageUrl) { |
There was a problem hiding this comment.
MateMapper의 toResponseDto 메서드가 수정되었습니다. 기존 메서드가 오버로딩 되어, isApplied, postLike, mateApplications 파라미터를 받는 새로운 메서드가 추가되었습니다. isApplied의 기본값을 false로 설정한 이유와 postLike, mateApplications를 추가한 이유를 명확히 설명해야 합니다. 메서드 내 로직이 복잡해졌으므로, 가독성을 높이기 위해 코드를 더 작은 함수로 분해하는 것을 고려해보세요.
|
|
||
| boolean isApplied = mateApplicationRepository.existsByMateIdAndApplicantId(id, userId); | ||
|
|
||
| // 1. 게시글 좋아요 정보 → PostLikeInfo 리스트 생성 |
There was a problem hiding this comment.
MateService에서 MateResponseDto를 생성하는 로직이 변경되었습니다. postLike와 mateApplications 정보를 추가하여 MateMapper에 전달하는데, 이 부분의 성능에 대한 고려가 필요합니다. stream() 연산의 효율성을 확인하고, 필요하다면 최적화 방안을 강구해야 합니다. 또한, 변경 전과 변경 후의 성능 차이를 측정하고 비교하는 것이 좋습니다. 각 리스트 생성 부분에 대한 주석을 더 자세히 추가하는 것을 추천합니다.
Hotfix/mateboard: 게시글 좋아요, 댓글 좋아요 배열 반영
🔘 Part
🔎 PR Type
🔧 작업 내용 상세 작성
[레포 이름 #이슈번호](이슈 주소)
작업 내용을 상세하게 작성해 주세요!
✔️ PR Checklist
커밋 메세지를 컨벤션에 맞게 잘 적용 하였나요?
테스트 코드 작성 / 단위 테스트 or 통합 테스트 진행 하셨나요?