20240828 본캠프 33일차 TIL

본캠프 33일차 내용 간단요약

• 09:00 ~ 10:00 : 코드카타
• 10:00 ~ 10:10 : 팀 회의
• 10:10 ~ 11:00 : 튜터님 인터뷰
• 11:00 ~ 12:00 : api명세 erd명세 수정
• 12:00 ~ 13:00 : 점심시간
• 13:00 ~ 14:00 : cs공부
• 14:00 ~ 15:00 : TIL 작성
• 15:00 ~ 17:00 : 과제 리팩토링
• 17:00 ~ 18:00 : 튜터님 강의
• 18:00 ~ 19:00 : 저녁시간
• 19:00 ~ 20:00 : 과제 리팩토링
• 20:00 ~ 21:00 : TIL작성

---

오늘 해야할 일 ✔️ 🔺 ❌

 

✔️개인과제 리팩토링

✔️어제 날라가버린 TIL 작성하기

---

....

 

---

 

코딩테스트 준비

인프런 강의라 공유금지..!

비밀글에 올릴예정

---

과제 리팩토링

 

1. 과제를 제출하기전 N+1문제를 확인하기위해 확인해보았다.

 

2. 과제4 - 영속성 전이를 위해 hard delete로 바꿨다

@OneToMany(mappedBy = "member", cascade = CascadeType.REMOVE)
private List<Reply> replies = new ArrayList<>();

@OneToMany(mappedBy = "member", orphanRemoval = true)
private List<Manager> managers = new ArrayList<>();

@OneToMany(mappedBy = "member", cascade = CascadeType.REMOVE)
private List<Task> tasks = new ArrayList<>();

 

cascade 타입을 remove로 하여서 

멤버가 삭제되면 주루룩 삭제 되게 하였고

@OneToMany(mappedBy = "task", cascade = CascadeType.REMOVE)
private List<Reply> replyList = new ArrayList<>();

 

task도 삭제되면 reply가 삭제되도록 구성하였다

 

 

task가 삭제되면 reply도 삭제 되는것을 볼 수 있다

 

3. 10단계

기존에 돌던 코드는 TASK를 만드는 과정에서

서버에서 받아온 파일 DTO에 저장 (365회)

그다음 오늘 날짜를 자바에서 설정해서 오늘 날짜에 맞는 LIST를 조회한다.

즉 12월 31일은 TASK를 등록하는데 365 +365 거의 700번을 저기서 돌게된다

 

O(N)으로 작동하지만 솔직히 비효율적인거 같은느낌이..

 

그래서 이리저리 묻고 다녔다

팀원분의 의견에는 MAP으로 하라 였고, 다른분은 이분탐색을 하라였다

둘다 좋은 구현이었지만 MAP으로 구현하기로 했다.

 

또 생성자에다가 서버에서 데이터를 불러오면 한번만 실행되니 좋지않을까 생각했다

 

 

기존 버전에서 걸린시간 552ms

개선된 버전에서 걸린 시간 52ms

 

10배나 개선된 시간을 얻을 수 있었다.

---

과제 후기 - 과제를 제출하며, 배운점, 느낀점.

과제를 제출하며

0단계 ~ 10단계 중 몇 단계까지 과제를 완성했나요?
10
[참고] 브랜치가 나뉘어져 있습니다
main브랜치는 soft delete를 구현하여 4단계 과제(영속성 전이) 가 빠져있습니다
feature/hrdDelete브랜치는 repository의 delete를 사용하여 영속성 전이 기능을 넣었습니다.

 

기술 질문 1. 처음 설계한 API 명세서에 변경 사항이 있었나요? 변경 되었다면 어떤 점 때문 일까요?
변경이 되었습니다.
일단 api설계와 erd가 파트별로 4개가 되어 깊게 생각하지 않은채 작성을 하였습니다 추후 수정작업을 거쳤습니다

 

기술 질문 2. ERD를 먼저 설계한 후 Entity를 개발했을 때 어떤 점이 도움이 되셨나요?
필드를 어떤것을 작성해야할지 미리 알고있으니 작성의 편리함이 있습니다 연관관계도 erd매핑에따라 처리를하면됩니다.

 

기술 질문 3. JWT를 사용하여 인증/인가를 구현 했을 때의 장점은 무엇일까요?
stateless에 걸맞게 서버는 클라이언트의 상태를 가지고 있지 않습니다 또한 토큰을 검증하기때문에 암호화된 정보를 확인 할 수 있습니다 또한 확장성이라고 생각합니다. 7단계를 할때는 권한을 넣지않았지만 9단계에서 권한 기능을 동적으로 추가를 하여도 코드 한줄로만 정보를 담을수 있다고 생각했습니다.
단점이라면 서버는 단지 검증만 하기때문에, jwt를 탈취 당하는 보안이 떨어진다고 생각됩니다.

 

기술 질문 4. 만약 댓글이 여러 개 달려있는 할일을 삭제하려고 한다면 무슨 문제가 발생할까요?
cascade를 사용하지 않았다면 외래키 오류가 뜰것입니다.
cascade.REMOVE나 orphanremoval = true로 작성을하면 고아객체는 삭제될것이고, 부모가 삭제되면 자식도 전파되어 삭제될것입니다

 

기술 질문 5. 연관관계를 설정할 때 단방향과 양방향으로 맺는 것의 차이점은 무엇일까요? 각 방법의 장단점은 무엇이 있을까요?
단방향 관계 :
코드가 단순해지며, 한쪽만 참조할 경우에 사용할수 있습니다.
단방향 매핑만으로 테이블과 객체의 연관관계 매핑은 되어있습니다.
다만, 한쪽만 참조를 할 수 있습니다.
양방향 관계 :
양쪽 객체를 서로 참조할수 있습니다.
다만 복잡성이 증가합니다, 단방향 매핑후, 필요할경우 양방향 매핑을 하는것이 좋습니다.

 

과제를 하며 어려웠던 점은 무엇이었나요?
7~10은 처음 접하는 것이기도 하고
코드스니펫을 참조 하기도 하였습니다
조금씩 수정을 하며 이해를 하기는 했지만, 온전히 제가 짰다고는 할 수 없습니다.
만약 코드스니펫과 강의가 없었다면 6에서 제출을 끝내지 않았을까.. .싶기도...

 

 

배운점

저번 피드백에서 받은 exception 핸들러와 response entity에 대해서 확실하게 깨우치게 되었고

jwt와 filter에 대해 코드를 수정해보며 어떤 흐름으로 진행되는지 조금 이해하게 되었다

과제를 하면서 cascade와 orphanremoval에 대해 생각했고

데이터베이스 정규화에 관해서 (솔직히 말이 너무 어려웠음 원자성이나, 이행적 함수종속이나 ㅇㅇ..) 더 이해하는 시간이 되었다!

상태코드를 생성하며, 어떨때 적합한 상태코드를 반환해야하는지 느끼게 되었다

 

팀원들의 오류사항을 보고 쿼리의 실행 순서가 있다는것을 알았으며

복잡한 로직일때 flush를 적절히 사용해야 한다는것을 느꼈다.

아니면 jpql쓰던가..!

 

참고자료

https://lovon.tistory.com/95

 

느낀점

jpa를 사용하며 jdbc보다 편리해지기도 했고 쿼리문을 작성하지 않아도 되니 편했다

트랜잭션의 중요함을 알게되었다

 

오늘의 회고 & 12시간 몰입했는가? 

이것저것 준비할게 많다 많아..! 집중!