기록/회고
JPA 게시판 프로젝트 회고(22.12.15~22.12.17)
모달조아
2022. 12. 19. 05:52
느낀점
이번 JPA 게시판 프로젝트는 페어 프로그래밍으로 진행해보았다. 페어 프로그래밍을 처음해보았는데 색달랐다. 좋은 점도 있고, 나쁜 점도 있다. 좋은 점은 나랑은 다른 개발 스타일, 생각들을 접할 수 있다는 점이다. 개발을 하다보면 다른 사람들은 어떤 생각으로 코드를 짰을까하는 생각이 자주 드는데, 그런 궁금증을 조금은 해소할 수 있었다. 또, 내가 놓치고 있던 부분들을 캐치할 수 있었다. 나쁜 점은 페어 프로그래밍이 길어지면 집중하기가 어려웠다. 각자의 속도가 다르다보니 시간이 길어지면 멍하니 바라볼 때도 있었다. 사실 이건 오로지 나의 문제다.
소현이는 개발 진행도를 빠르게 가져가면서 후에 리팩토링을 하는 스타일이었다. 나는 개발할 때, 궁금증이 생기거나 에러가 생기면 잔가지를 치면서 진행도가 더뎌지는 경향이 있다. 어떤 스타일이 옳다고는 하지 못하지만, 일단 나는 이번에 같이 페어 프로그래밍을 하면서 소현이의 개발 스타일의 좋은 점을 흡수하면 나의 단점을 개선할 수 있을 것 같다고 느꼈다.
게시판 과제를 진행하면서 가장 크게 느꼈던 점은 테스트가 참 어렵다란 것이다. 그리고 그렇게 느끼는 이유는 아마 깊게 공부하지 않아서, 정확히 동작원리를 알지 않고 사용하기만 해서일 가능성이 높다. 급할수록 돌아가라는 것이 정답인 것은 알지만 그렇게 하기가 쉽지는 않다. 항상 남에게 설명할 수 있을 정도로 공부하자.
프로젝트를 하며 생겼던 고민, 문제들
- PostResponseDto 에 User 와 관련된 정보를 얼마나 담아야 하는지
- 이건 정답이 없을 것 같다. 무식하지만 간단한 해결 방식은 User 정보를 전부 다 담는 방법, User 정보가 필요한 정도가 다를 때마다 DTO를 새롭게 만들어서 담는 방법 2가지 정도 있을 것 같다. 프로젝트를 할 때마다 DTO 가 애물단지다. DTO 를 어느 레이어에서 변환할지, DTO 와 Entity 변환 로직의 책임을 어디에 줄 지, 많아지는 DTO 를 어떻게 관리할지 등.
- Post 가 User 에 종속적이게 해도 되는지
- 즉, User 없이 Post 가 만들어지는 경우가 있을 수 있냐는 것이다. 이것도 요구사항에 따라 다르겠지만, 나는 익명 User 는 게시글을 쓸 수 없다라는 생각으로 Post 가 User 에 종속적이게 하였다. 만약 익명 User 도 게시글을 작성할 수 있게 해야한다면 종속적이게 하면 안되고, 그럴 때는 User 엔티티도 새롭게 설계해야할 것이다.
- @Validated, @Valid 선택 문제
- Bean Validation 을 이용할 때, @Valid 와 @Validated 어노테이션을 이용하면 컨트롤러 단에서 쉽게 검증을 할 수 있다. 이 때, 어떤 것을 사용할지 선택이지만, 나는 이번 과제를 하면서 @Valid 를 선호하게 되었다. 일단 나는 create 와 update 시 dto 를 나눠서 @Validated 에만 있는 groups 기능을 사용할 필요가 없다는점, 그리고 결정적으로 @Validated 이용 시에는 검증 실패 시 ConstraintViolationException 가 발생하는데 @Validd 이용 시에 발생하는 MethodArgumentNotValidException 에서는 쉽게 BindingResult 를 가져올 수 있는 점에 반해 ConstraintViolationException 에서는 불가능하다. 또, @Valid 가 자바 표준 스펙이기 때문에 조금 더 덜 제약적이지 않을까하는 생각도 해본다. 이건 뭐 근데 거의 상관 없을 거 같긴하다. @Valid 는 컨트롤러 메서드에서만 검증이 가능하긴 하지만 크게 문제는 되지 않는다. 대부분 dto 를 통한 컨트롤러 단에서 검증이 이뤄지니깐 말이다.
- NoHandlerFoundException 가 던져지지 않았던 문제
- 컨트롤러에서 매핑되지 않은 url 요청이 올 시에 NoHandlerFoundException 를 던지고 싶었다. 그런데, NoHandlerFoundException 이 던져지지 않고 계속 스프링 부트에서 제공하는 404 에러 메시지가 발생했다. 알고보니 스프링에서 기본적으로 컨트롤러에서 매핑되지 않은 url 요청이 올 시 기본적으로 내부에서 특정 handler 를 적용해준다고 한다. yml 파일에 설정을 통하여 해결하였다.
- JPA Repository 도 테스트를 해야하는지
- JPA 를 이용한 Repository 테스트를 작성하면서 이런 고민이 생겼다. 이거 굳이 테스트 해줘야하나? 내가 짠 로직으로 작동하는 repo 도 아니고 이미 완성되있는 기본적인 CRUD 를 가져와서 쓰는 것인데 테스트의 의미가 있나 싶었다. 건우님이랑 이 주제에 대해 이야기해보다가 건우님이 우리가 빈 등록이 되었는지 안되었는지를 테스트하지 않듯이 이것도 본인은 테스트할 부분이 아니라고 생각한다라고 하신 부분이 크게 공감이 되었다. 나도 이건 테스트하지 않아도 된다고 생각한다. 내가 작성한 로직이 아니기에.
좋았던 점
- 미흡했던 검증, 예외처리, 테스트를 구현한 것
- 지난 A-Z 프로젝트를 하면서 검증, 예외처리, 테스트들이 미흡하다는 것을 알면서도 시간에 쫒겨서 구현하지 못했었다. 지난 A-Z 프로젝트를 마치고 다짐했던 것은 무조건 다음 과제에는 미흡했던 부분을 적용하자였다. 그래서 이번 과제에는 요구사항을 넘어서 검증, 예외처리, 테스트 부분을 열심히 해보려고 노력했고, 그래도 잘 해낸 것 같다.
- Mockito 를 이용한 테스트를 진행한 점
- 바우처 과제를 진행하면서 살짝 맛은 봤지만, 각종 에러가 터지면서 제대로 마무리 짓지는 않았었다. 이번에는 이왕하기로 한 거 제대로 해보려고 했고, 앞으로 다른 테스트를 할 때도 사용할 수 있을 것 같다.
- REST API docs 를 이용하여 문서화한 것
- 그동안 알고만 있었고 공부해보고 싶다는 막연한 생각만 가지고 있었는데 실천은 하고 있지 않았다. 이번 프로젝트에서는 요구사항에 포함되어 있었고, 강의에서도 배웠기에 이참에 적용해보았다. 다 좋았는데 생각보다 작성해줘야 할 테스트 코드량이 많았다. 근데 강제적으로 테스트 코드를 짜게 되니 오히려 좋을지도.
아쉬운 점, 추후에 적용할 부분들
- 검증, 예외처리에 사용했던 기술들을 정확하게 알지 않고 구현만한 점
- 적당히 알고는 있다고 생각했지만 막상 남에게 설명해보라고 하거나, 면접에서 질문이 들어온다면 대답하지 못할 것 같다. 이거는 모르는 거랑 다름이 없기에 앞으로 더 공부하면서 연습하고 채워나가야 할 부분이다.
- 예외 메시지를 설정 파일로 관리하지 않은 점
- 예외처리를 공부하면서 메시지를 한번에 관리할 수 있다는 점을 배웠는데, 이번 과제에서는 적용하는 것을 일단 미뤘다.
- 테스트를 할 때, 실패 경우도 테스트를 하자
- 저장소, 서비스 단에서는 실패 경우도 테스트를 했지만, 컨트롤러 테스트의 경우는 실패 경우 테스트를 하지 않았다. 사실 테스트에서 중요한 것은 정상 로직 테스트보다는 각종 실패 테스트들이다. 귀찮아하지말고 하자.
컨트롤러 테스트에서 통합 테스트를 제거하자@SpringBootTest 어노테이션은 참 편하다. 하지만 무겁고 오래 걸린다. @WebMvcTest 를 이용하면 컨트롤러 테스트에 필요한 빈들만 가져오니 그런 부담을 좀 덜 수 있다. 알고는 있지만 귀찮기도 하고 제출하고 싶은 마음이 커서 적용하지 않았다. 다음 번에는 꼭 적용하자.- -> 리팩토링하면서 slice test 로 변경했다.
- 빌더 패턴을 적용해보자
- 이건 그냥 사용해보자는 목적이다.