나는 너무 앞만 보고 달리는 것 같다
개발을 진행하면서 현재 코드의 불편한 점을 알아채고
개선할 방법을 찾아야되는데
불편한대로 쓰고 있다
좋지 않은 방법인것 같다
프로젝트의 목적은 취업인데
면접 때 질문이 들어왔을 때 대답할 것들이 있어야 한다
내가 말할 거리를 만들어내야 한다
시야를 넓히자
이미지 파일을 포함해서 게시물을 수정하는 로직에서
값을 못 받아온다
평소 값을 받는 대로 @Getter, @NoArgsConstructor, @AllArgsConstructor를 사용했다
이것이 문제가 되는 것 같다
@Data로 바꾸고 다시 실행했더니 정상적으로 작동한다
하지만 @Data는 @Getter, @Setter, @ToString, @EqualsANdHashCode, @RequiredArgsConstructor를 합쳐놓은 어노테이션이기 때문에 불필요한 메소드들이 생긴다고 한다 (https://devlog-wjdrbs96.tistory.com/401)
그래서 사용을 지양하라고 한다
그래서 실험을 해봤다
PutBoardRequestDto에서 @AllArgsConstructor를 빼봤다
즉, @Getter와 @NoArgsConstructor만 써두고 실행했더니 500 Internal Error가 났다
그다음, 기존에 써놨던 어노테이션에 @Setter를 추가했다
즉, @Getter와 @Setter, @NoArgsConstructor, @AllArgsConstructor를 적어두고 실행했더니 정상적으로 수정이 되었다
로직에 Setter 함수는 쓴 적이 없는데 왜 @Setter를 추가해야하는 지 아직은 모르겠다
@AllArgsConstructor와 @NoArgsConstructor를 빼도 되는지도 확인해봤다
@Getter와 @Setter 만 썼는데도 정상적으로 작동한다
[해야되는 것]
게시물 작성 시 사진 최대 5장 첨부하기로 결정.
-> 지금까지는 한 게시물에 한 장의 이미지만 첨부한다고 가정하고 로직을 짜왔지만
모두 수정이 들어가야 한다
수정 로직 게시물 올릴 때 첨부했던 사진들을 모두 삭제하고 제목, 내용만 적어두고 수정을 한다면?
게시물을 쓸 때 5장의 사진을 올리고
수정할 때 2번째로 올린 사진만 변경한다면?
게시물 수정 시 사진도 같이 수정해야 하는가?
-> requestDto에 이미지Url 변수 5개, MultipartFile 변수 5개를 만들기로 했다
여러가지 경우의 수를 해결할 수 있는 최선의 방법인것 같다
일단 게시물 작성 시 최대 5장까지 올릴 수 있도록 프론트에서부터 제한시킬 것이다
경우 1) 사용자가 게시물 작성 시 5개의 사진을 올리고, 두번째 사진과 네번째 사진을 수정을 할 경우
-> imageUrl2와 imageUrl4는 null이고, image2와 image4는 이미지 파일을 담고 있게 된다
imageUrl1, imageUrl3, imageUrl5은 게시물 작성 시 올렸던 이미지 URL이 담기게 되고,
image1, image3, image5는 null이 담기게 된다
경우 2) 사용자가 게시물 작성 시 5개의 사진을 올리고, 게시물 수정 시 다섯번째 사진만 삭제하는 경우
-> imageUrl1, imageUrl1, imageUrl1, imageUrl4는 기존의 이미지 URL이 담겨있고,
imageUrl5는 null이 담기게 된다
image1, image2, image3, image4, image5는 수정할 이미지가 없기 때문에 모두 null이 담긴다
여러가지 경우의 수가 더 있겠지만, 이 정도로 하겠다
왜 이러한 방법을 생각하게 되었냐면
나는 처음에 order 컬럼을 추가했다
게시물 작성 시 이미지 URL과 이미지의 순서를 넣고,
게시물 수정 시 int array를 선언해 프론트에서 수정이 일어난 이미지의 순서를 담는다
또한, MultipartFile array를 선언해 수정해야하는 이미지 파일들을 순서에 맞춰 담는다
수정하는 이미지들을 S3에 모두 올려 각각의 이미지 URL을 얻어내고,
board_image의 image컬럼을 update 시키는데
order 컬럼의 데이터와 order 배열의 값과 비교해서 일치한다면 일치하는 image 컬럼을 update시키도록 로직을 짰다
위의 경우 1)을 해결할 수 있지만, 경우 2)는 해결할 수 없었다
모두의 경우의 수를 생각해서 각각 로직을 짜줘야 하는 것이었다
그래서 requestDto에 배열이 아닌 각각의 변수들을 선언하는 방법은 이상한 것 같지만,
현재 상황에서 가장 최선의 방법이라고 생각한다
(갈아 엎어야되는데 아까우니 짜놨던 로직 첨부해놔야지)
일단은 Junit 버전 4로 학습하는게 좋다네요
아직은 현업에서 대부분 4버전을 써서
+ mockito
심화 강의 중 테스트코드 부분 다시 보기
'항해99 3기' 카테고리의 다른 글
[TIL] 2021.11.06 최종 프로젝트 진행중 (0) | 2021.11.06 |
---|---|
[TIL] 2021.11.04 최종 프로젝트 진행중 (0) | 2021.11.04 |
[TIL] 2021.11.02 최종 프로젝트 진행중 (0) | 2021.11.03 |
[TIL] 2021.11.01 파이널 프로젝트 진행중 (0) | 2021.11.01 |
[TIL] 2021.10.29 파이널 프로젝트 진행중 (0) | 2021.10.29 |