7주차 간략 후기

실전 프로젝트 2주차

저번주에는 아이디어가 엎어졌다가 다시 원래 아이디어로 돌아갔다고 했는데 다시 돌아간 아이디어도 빠꾸 먹어서 다른 아이디어 찾는다고 한참 또 고생을 했다. ㅜㅜ

다들 피곤한 상태에서 아이디어까지 무조건 쥐어짜려고 하니 정말 피곤해보였고 나도 뇌가 쪼그라드는 느낌이었다.

실전 프로젝트에서 많이 싸운다고 하던데 왜 싸우나 생각을 해봤더니 이런 체력적으로 힘든 상황이 뒷받침 되는 것 같다. 이런 예민한 상태에서는 별일 아니라도 확실히 싸움으로 번지기 좋은 상황인것 같다. 서로 서로 에게 말을 조심히 그리고 배려있게 대할 필요가 있음을 다시 한번 생각하게 된 계기 였다.

여차저차 해서 이번주 목요일날 저녁에 기획을 마무리 짓고 금요일부터
API 설계 , Entity 설계 , 작업 분배 등등을 시작했다.

일단 로그인 및 게시판 관련해서 먼저 다 끝내고 핵심기능을 진행하자고 이야기가 나와서 그렇게 하기로 했다.

로그인은 내가 맡아서 처리했는데 저번주에 JWT 관련해서 로그인만 확실하게 공부하다보니 이번에 적용할때는 별 이슈없이 빠르고 편하게 적용할 수가 있었다.

실전 프로젝트를 진행하며 기술적으로 막혔던 부분은 무엇인가요?

이번주에는 기획만 실컷해서 크게 기술적으로 막힌 부분은 몇개 없지만 그중에 1개만 뽑아보면 Entity 설계에서 양방향 매핑이 좋은가? 단방향 매핑이 좋은가? 이야기가 나왔고

JPA - One To Many 단방향의 문제점 ( https://dublin-java.tistory.com/51 )

나는 여기서 참고한 내용을 기반으로 양방향으로 가자고 이야기를 했다.
그래서 양방향으로 모든 Entity를 설계했는데 DB에 데이터를 저장할때 문제가 생겼다.

결론부터 말하면

1.Entity에서 양방향 매핑을 사용할 경우 @ToString Lombok을 쓰면 StackOverFlow가 발생한다. [ToString을 진행하면서 무한으로 순환 참조가 일어나기 때문에 StackOverFlow가 발생 == JSON으로 내보낼때 문제가 생기는 것 과 동일함]

• 우리는 @ToString을 쓴것은 아니지만 @Data를 쓰면 @Getter ,@Setter 다 안쓰고 한번에 된다고 해서 해당 어노테이션을 썼는데 @Data 안에 @ToString이 포함이 되어 있었다.
• @Data를 지우고 @Getter , @Setter 를 사용했더니 문제가 해결되었다.

간단한 문제였는데 해당 어노테이션에 대한 이해가 부족해서 생긴 문제였다.