팀플을 본격적으로 한 후, 오늘 팀원들과 내가 기능 구현한 코드들을 합치면서 코드 리뷰를 진행했다. 역시 여러 사람들과 코드를 합치는게 진짜 어렵다. 깃부터 아주 말썽이였다. 오늘 내가 밥먹을 타이밍에 마침 딱 깃에서 머지할 때 문제가 생겼다..(내가 한 머지가 문제였던 것.) 밥도 못먹고 일단 문제부터 수정했다. 이유를 잘 알 수 없는데 내가 맡은(User도메인) Repository가 두개였다. 이유가 짐작은 가지만 정확한 이유를 찾기 전에 일단 수습부터 했다. 내가 짐작하는 이유는 이것.
UserRepository의 위치가 애매했다. Repository 패키지 안에 있지 않고 혼자 따로 나와 있길래 새로 Repository 패키지를 만들어서 넣어놨는데, 머지할 때 뭔가 이상하게 합쳐졌나보다. 그래서 패키지 밖에 있는 UserRepository를 지웠다.
[연관관계를 잘 맺어주자!]
그런데 또 오류가 났다.. 오류가 진짜 너무 길었다.. 처음 눈에 띄었던 것은 WebSecurityConfig가 Bean으로 뜨지 못한다는 것.
그런데 그 위에 오류에서는 다른 오류가 있었다.
다시보면 에러가 2개가 뜬다. 첫번째 에러는 Post 엔티티와 Comment 엔티티가 서로 연관관계를 맺는다. 이때 서로 연관관계 설정이 잘못됏으니 잘 연결 해라! 이다. 이런 오류가 뜬 이유를 보자.
Post Entity에서는 Comment Entity를 'post'로 매핑했다. 근데?
Comment에선 나는 모르는 일이요~ 하고 있었다. 그러니까 JpaEntityManager가 둘이 말이 다르니까 빨리 처리해라~ 하는 거였다. 주석처리된 부분을 추가하니까 문제 없이 잘 돌아간다.
그런데 여기서 생기는 의문은 왜 JPA에서 문제가 생겼는데 WebSecurityConfig가 Bean으로 뜨지 않는지?였다.
지금까지 오류가 있으면 저 오류는 항상 따라다녔던 느낌이다. 이건 아직 내실력으로는 문제가 풀리지 않아서 내일 튜터님께 여쭤보러 가야겠다.
[Builder를 이용해서 생성자를 만들자]
샤라웃 투 최준영님
처음 팀프로젝트를 시작 할 때 선언했던 것 처럼 앞으로 생성자 사용을 하지 않고 객체 주입을 Builder로 하기로 했다. 그런데 관성적으로 생성자들을 만들고, Setter들을 사용했다. Builder를 사용하면 내가 원하는 필드들만 주입할 수 있고, 생성자를 private으로 설정할 수 있기 때문에 데이터 불변성을 지킬 수 있다. 또 코드의 가독성을 높일 수 있으며 유연성을 높일 수 있다. 아직 Builder사용이 어색해서 생겼던 문제 두번째는 Setter였다. Builder는 Setter의 역할을 대체할 수는 없다.
Entity를 수정할 때 특정값들을 수정할 경우 Setter를 사용하게 되는데, 이는 Builder로는 처리할 수 없어 따로 Setter 메서드를 만들어줘야 한다.
이게 조금 어렵게 느껴진다. Setter 사용을 지양하려고 Builder를 사용하는데, 결국 Entity를 수정하려면 Setter와 비슷한 update 메서드를 구현해야 한다. Setter를 사용해서 Entity를 업데이트 하는 것과, update메서드를 내가 직접 구현해서 Entity를 업데이트 하는것이 어떻게 다른지를 잘 모르겠다. 내일 준영님께 여쭤봐야겠다.
[global 예외 처리]
지난 뉴스피드 프로젝트 때 마지막 3시간은 예외처리에 시간을 썼다. 모든 컨트롤러 단에서 예외발생 케이스를 모두 try catch 문으로 감쌌다. 이걸 AOP를 이용하면 한번에 예외를 처리할 수 있다. 오늘 예상치 못한 오류들이 발생해서 글로벌 예외처리를 공부를 못했다.. 내 오류를 처리해주는 글로벌 예외처리는 어디 없나? 그렇다면? 지금이라도 한번 읽어보자.
오우... 지금 자료를 읽어보는데 이거 정리하려면 단단히 공부를 해야겠다. 기본적으로 예외가 발생하면 처리되는 방식의 흐름부터 스프링에서는 어떻게 예외를 다루는지에 대해 다루는 글이다. 지금 심심미약 상태에서 보기에는 살짝 버거운 내용! 내일 정신이 말짱할 때 다시 보고 til을 작성해보자. AOP는 내가 피드백 받았던 내용일 뿐더러, 내가 실제로 절실히 필요서을 느꼈기 때문에 더 제대로 다뤄보고 싶다.