Closed HongYeseul closed 1 week ago
Review the provided code changes and provide feedback.
Good points:
deleteImage
method in DiaryImageService.java
now correctly deletes the image associated with a diary.sendImage
method in ImageController.java
has been improved to handle cases where the main banner URL does not exist.Improvement suggestions:
deleteImage
and deleteImageAndMapping
methods from DiaryImageService.java
to a separate service class, e.g., ImageService.java
. This would improve code organization and make it easier to manage image-related logic.ImageController.java
, add comments to explain the purpose of each method and any complex logic involved.sendImage
method, consider adding a try-catch block to handle cases where the main banner URL does not exist.Proposed changes:
deleteImage
and deleteImageAndMapping
methods from DiaryImageService.java
to ImageService.java
.ImageController.java
to explain the purpose of each method.sendImage
method.Here is an example of how the refactored code could look like:
// ImageService.java
public class ImageService {
public void deleteImage(Long imageId) {
// implementation details...
}
public void deleteImageAndMapping(Diary diary) {
// implementation details...
}
}
// ImageController.java
@RestController
@RequestMapping("/api")
public class ImageController {
@Autowired
private ImageService imageService;
@PostMapping("/diary/{diaryId}")
public ResponseEntity<?> sendImage(@PathVariable Long diaryId, @RequestPart("image") MultipartFile image) throws IOException {
// implementation details...
}
@DeleteMapping("/diary/{diaryId}")
public ResponseEntity<?> deleteDiaryImage(@PathVariable Long diaryId) {
imageService.deleteImageAndMapping(diaryToImageDAO.findByDiaryId(diaryId).orElseThrow());
return ResponseEntity.ok().build();
}
}
Note that this is just a suggestion, and the actual implementation may vary depending on the specific requirements of your project.
안녕하세요, 리뷰봇입니다. 댓글 기능 PR 주신 것을 확인하고 몇 가지의 사항을 리뷰 해보았습니다.
좋은 점:
CommentDeleteResponseDTO
클래스가 필요하지 않다는 점을 검토했습니다.개선할 점:
CommentService
클래스 내에서 변수명 일치 문제: update
와 delete
메서드에서 첫 번째 매개변수 CommentId
가 대문자로 시작하고 있습니다. 이를 소문자로 변경하여 일관성을 유지해야 합니다.CommentService
클래스 내 로직 제안: mapToDTO
를 CommentResponseDTO::from
으로 코드 재사용을 가능하게 할 수 있습니다.제안 사항:
DiaryImageService
클래스의 deleteImageAndMapping
메서드에서 imageService.deleteImage(diaryImage.getImage().getId());
부분을 수정하여 더 명확하고 일관된 코드로 변경할 수 있습니다.deploy
노드를 code_review
노드로 변경하여, 코드 리뷰가 더 철저하게 이루어지도록 제안합니다.수고하셨습니다! 👍
안녕하세요! 리뷰봇입니다.
좋은 점:
개선할 점:
CommentResponseDTO
클래스의 필요성을 다시 검토해 보아야 할 수도 있습니다. 만약 isDeleted
, createdDate
, createdAt
, depth
, childComments
모두가 필수적이지 않다면, 선택적으로 사용하는 것이 좋습니다.
예를 들어, comment.getDepth()
가 null일 수 있기 때문에, 이를 처리하는 로직을 추가해야 할 수도 있습니다.
CommentService
클래스의 update
메서드에서 parentCommentId
매개변수가 필요하지만, 이를 생략해도 큰 문제는 없을 것 같습니다. 따라서 선택적 매개변수로 변경하여 옵션으로 처리할 수 있게 해보세요.
public Comment update(String content, Long parentCommentId) {
return requestDTO.toEntity(member, diary, parentComment, content);
}
DiaryService
클래스의 makeRewardPoint
메서드에서 정수값을 고정하지 않고, 랜덤하게 생성하도록 변경할 수 있습니다. 이를 통해 보다 다양한 포인트를 제공할 수 있을 것입니다.
private int makeRewardPoint() {
return new Random().nextInt(100);
}
제안 사항:
CommentResponseDTO
클래스에서 depth
필드를 제거하고, 필요에 따라 선택적으로 사용하도록 변경할 수 있습니다.
public record CommentResponseDTO(
boolean deleted,
String createdDate,
String createdAt,
List<CommentResponseDTO> childComments
) {
public static CommentResponseDTO from(Comment comment) {
return new CommentResponseDTO(comment.isDeleted(), comment.getCreatedAt().format(DateTimeFormatter.ofPattern("yy년 MM월 dd일")), comment.getCreatedAt().format(DateTimeFormatter.ofPattern("HH:mm")), comment.getChildComments().stream().map(CommentResponseDTO::from).collect(Collectors.toList()));
}
}
DiaryService
클래스의 removeDiaryLikes
메서드에서 삭제 로직을 분리하여 보다 명확하게 작성할 수 있습니다.
private void removeDiaryLikes(Long diaryId) {
List<DiaryLike> diaryLikes = diaryLikeDAO.findAllByDiaryId(diaryId);
for (DiaryLike like : diaryLikes) {
imageService.deleteImage(like.getImage().getId());
}
diaryLikeDAO.deleteAll(diaryLikes);
}
CommentService
클래스의 toEntity
메서드에서 parentCommentDepth
매개변수를 추가하여, comment depth를 계산하고 validate할 수 있습니다.
public Comment toEntity(Member member, Diary diary, Comment parentComment, int depth) {
return Comment.builder()
.member(member)
.diary(diary)
.content(content)
.parentComment(parentComment)
.depth(depth)
.build();
}
ImageController
클래스에서 deleteDiaryImage
메서드를 제거하고, 대신 deleteImageAndMapping
메서드에 로직을 통합할 수 있습니다.
@PostMapping("/diary/{diaryId}")
public ResponseEntity<?> deleteDiaryImage(
@PathVariable Long diaryId
) {
imageService.deleteImage(diaryId);
return ResponseEntity.ok().build();
}
ClientErrorCode
클래스에서 새로운 에러 코드를 추가하여, 댓글의 깊이 제한에 대한 메시지를 제공할 수 있습니다.
public enum ClientErrorCode implements ErrorCodeModel {
IMAGE_MAPPING_NOT_FOUND_ERR(400, "IMAGE_MAPPING_NOT_FOUND_ERR", "해당 이미지를 찾을 수 없습니다.(이미지 등록 값 없음)"),
AUTHOR_MISMATCH_ERR(403, "AUTHOR_MISMATCH_ERR", "작성자가 아닙니다."),
COMMENT_ALREADY_DELETED_ERR(400, "COMMENT_ALREADY_DELETED_ERR", "이미 삭제된 댓글입니다."),
COMMENT_DEPTH_EXCEEDED_ERR(400, "COMMENT_DEPTH_EXCEEDED_ERR", "댓글은 대댓글까지만 허용합니다."),
// 추가 에러 코드
}
수고하셨습니다! 코드 리뷰를 통해 개선할 수 있는 부분이 있으니, 이를 참고하여 더욱 나은 코드로 발전시켜 주시기 바랍니다.👍
안녕하세요! 리뷰봇으로서 이 코드를 검토하면서 몇 가지 의견을 드리려고 합니다.
CommentResponseDTO 클래스의 필요성
현재 CommentResponseDTO
클래스에서 isDeleted
필드가 추가되었습니다. 이는 프론트에서 댓글이 삭제되었는지 여부를 나타내는 데 사용될 수 있습니다. 그러나, 이미 CommentDAO
에서 deleted
상태를 관리하고 있으며, 이 필드는 중복된 정보일 수 있습니다. 따라서, CommentResponseDTO
의 필요성에 대해 다시 고려해 볼 필요가 있습니다.
CommentSaveRequestDTO 클래스 내 메서드 수정
toEntity
메서드에서 parentComment
과 함께 depth
를 인자로 받아 처리하는 것을 확인했습니다. 이는 댓글 트리 구조를 관리하기 위한 중요한 변경입니다. 그러나, Comment
엔티티의 depth
필드는 CommentResponseDTO
에서도 사용되는지, 아니면 단순히 서비스 내에서만 사용되는지는 확인해 보아야 합니다.
CommentService 클래스 내 로직 제안
calculateCommentDepth
메서드와 validateCommentDepth
메서드를 추가하여 댓글의 깊이를 관리하고 있습니다. 이는 댓글 트리 구조를 유지하기 위한 중요한 구현입니다. 그러나, depth
값을 계산할 때 부모 댓글의 depth
값을 참조하는 방식이 올바른지 여부에 대해 다시 생각해 볼 필요가 있습니다.
DiaryService 클래스 내 메서드 수정
makeRewardPoint
메서드에서 랜덤 값 생성 방법을 변경하여 보다 일관된 포인트를 제공하도록 했습니다. 이는 사용자 경험 개선에 기여할 수 있습니다. 그러나, 이 메서드가 실제로 어떤 계산을 수행하는지에 대한 설명이 필요합니다.
ImageController 클래스 내 메서드 수정
deleteDiaryImage
메서드는 삭제된 이미지를 처리하는 데 사용되는 것으로 보입니다. 이는 이미지 관리 시스템의 일관성을 유지하기 위해 중요한 구현입니다. 그러나, 이 메서드를 호출할 때 발생할 수 있는 예외 상황을 고려한 에러 처리가 필요합니다.
ClientErrorCode 클래스 내 새로운 코드 추가
COMMENT_DEPTH_EXCEEDED_ERR
코드는 댓글 트리 구조를 관리하는 데 사용되는 것으로 보입니다. 이는 프론트에서 댓글 입력 시 오류 메시지를 표시하기 위해 유용할 것입니다. 그러나, 이 에러 코드가 실제로 어디서 사용되는지에 대한 설명이 필요합니다.
이러한 점들을 검토하여 개선할 수 있는 방법을 제안드린 것으로, 코드의 일관성과 유지 보수성을 높일 수 있을 것이라 생각합니다.
감사합니다! 👍
기존 이미지가 있는 일기의 경우 PATCH 되지 않는 버그가 수정되었습니다.
그 외: code-review Action의 경우 가독성을 위해 job 이름이 변경되었습니다.