https://github.com/nhnacademy-be6-5ritang 북스토어 깃허브 링크
회고
nhnacademy 수료를 하기 직전 최종 프로젝트로 북스토어 프로젝트를 진행했다.
해당 프로젝트는 약 2달에 걸쳐 진행되었고 아카데미측에서 제공해준 요구사항(전체아님 일부)은 다음과 같다.
요구사항을 보고 첫 주차때 깃허브로 전체 일정을 짜고 팀원들 각자의 역량에 맞춰 기능을 분담했다.
배포를 제외하고는 수업 시간에 배운 것들이어서 참 다행이라고 생각했으나 막상 요구사항에 맞는 기능을 구현하려고하면 여러가지 시행착오를 거쳐야만 했다.
erd를 여러번 뒤엎는다던가, 페이지가 나오지않아서 db table을 다 지워버린다던가, 에러처리를 front, back 나눠서 해야하는 것을 모르고 하지 안했다던가 등등 여러가지 문제상황이 발견되었다.다행이 TA분이 있어서 문제상황에 대한 조언은 받을 수 있었지만 그것을 해결하는 것은 우리의 몫이었다.
그리고 코드리뷰과정에서 현직 개발자분께 구현한 bookstore project에 대한 피드백을 받았고 프로젝트 막바지까지 전부는 아니지만 그래도 절반이상은 피드백을 수용하고 문제를 해결했다. 현재 프로젝트는 끝났지만 그것을 고치기 위해 팀원들 모두 공부하고 있다.
전체 요구사항중 두개를 제외하고는 전부다 구현했다. 팀원 2명이 나가버리는 바람에 절때 다 못할 거라고 생각했는데 막상 해보니 두개 빼고 다해버려서 진행율은 거의 98%이상 되었다고 보면 될 것 같다.
개발을 아예 할 줄몰랐던 내게 있어서 프로젝트 경험은 많은 도움을 주었고 개발자로서 첫발을 내딛게 할 수 있는 자신감을 갖게 해주었다. 또한 끝까지 포기하지않고 완수해서 sonarqube testcoverage 80%이상으로 검증된 나의 코드들이 배포서버에서 잘 작동하는 것을 보면 뿌듯하기도 하다.
여기까지 회고를 써보고 잘하게된 것과 어려웠던 것을 구분해보고 자세하게 얘기해보고자 한다.
잘하게 된 것
- 깃허브 사용
그전까지만해도 깃허브를 단순히 pull, push하는 저장소 용도로만 생각했었는데 깃허브 organizaiton기능, 프로젝트관리 기능을 써보니 왜 깃허브를 사용하는지 알 것 같다. 또한 풀리퀘스트와 코드리뷰를 하는 과정에서 코드의 잘못된 점을 지적하고 새로운기능이 무엇인지 고민해보는 과정과 study repository(https://github.com/nhnacademy-be6-5ritang/5ritang-study)도 따로 만들어서 팀원들과 기술문서를 작성하는 과정을 경험했다.
- 블로그 글쓰기
본인 벨로그에 팀프로젝트 관련되어 아티클을 작성하고 있다. 작성한 블로그 글을 팀원들과 공유하였고 본인만 글을 쓰는 것이아니라 팀원들도 블로그를 운영하게끔 유도해본적도 있다.
어려웠던 것
-
erd설계
erd를 실무가아닌 프로젝트 단위에서 설계하다보니 일단 만들고보자는 식으로 막만들었다. 그러다보니 나중에 필드를 바꾼다던가 테이블을 없애버린다던가 굳이 cascade를 할 이유가 없는 것을 cascade 해버린다던가 등등 여러가지 문제가 생겼다.
역시 프로젝트 초입에 하는 것들이 가장 중요한 것 같다. 따라서 erd 설계를 할때 github에서 다른사람이 만든 erd를 참고해보고 설계를 해보는 것이 좋지 않을 까 싶다. 또한 msa 관점에서 만들어야 하기 때문에 쿠폰 서버의 경우 쿠폰 자체역할로 보고 book api 서버에 있는 것과 분리해서 봐야 한다는 점도 고려해봤다. -
배포
스프링클라우드 게이트웨이로 이중화 된 백서버를, nginx로 이중화된 프론트서버에 로드밸런싱해야하는 두가지 문제가 있었다.
백서버 이중화는 원래 할 생각이 없었는데 마지막에 팀원중 한분이 이중화 하여 간단하게 해결할 수 있었다. 이게 쉽게 해결할 수 있었던 이유는 프론트 이중화를 해결해봤기 때문이었다.
프론트 이중화 문제는 두번째 주부터 고생해서 진행한 것인데 이때 첨으로 ssl이 뭔지, 443, 80포트가 뭔지 알게되었다. 그리고 프론트서버 이중화를 왜 해야하고 그것을 ci/cd로 해결하는 과정도 팀원들과 공부하였다.
-
에러처리
에러 처리문제는 그냥 백에서만 하면 되는 줄 알았는데 TA님이 프론트, 백 둘다해야된다고 하셔서 어쩔 수 없이 둘다 했다. 그런데 왜 둘다 해야되는지는 몰라 TA님과 논쟁을 하게 되었다.
TA님과 논쟁을 하면서 깨달은 점은 백에서만 에러처리를 하면 에러의 주체를 구분짓기가 힘들다는 것이다. 예를 들면 프론트와 백관계에서 프론트가 클라이언트가 된다. 그러면 백에서 발생한 에러는 무조건 서버에러가 되는 것이다. 근데 만약 프론트에 에러처리를 하지않으면 클라이언트가 누구인지 알 수가 없다. 그래서 프론트 백 둘다 해주어야 확실한 발생주체를 파악할 수가 있는 것이었다. -
테스트코드 작성
테스트코드 작성을 하기위해 mockito문법 공부도하고 @webmvc, @DataJpaTest, @Mock, @MockBean 등등 controller, service, repository의 단위테스트를 하기위해 사용해야할 어노테이션도 공부하였다. 문제는 프론트단에서 간단한 기능들은 쉽게 테스트가 가능했지만 백단에서는 security때문에 테스트코드에 문제가 생겨서 실패하는 경우도 있었다. 이런 부분들은 단위테스트 수준에서만 작동시키기위해 security의 경우 @AutoConfigureMockMvc(addFilters = false)를 사용했다.
사실이런 것들은 크게 문제가 되진 않았지만 더 큰 문제는 테스트 코드양이 너무 많았다는 것이다. sonarqube 기준 coverage(line) 최소 80%이상이 배포 기준이었기 때문에 이것을 해결하기 위해 테스트 코드 작성에만 일주일 이상의 시간이 필요 했다.
따라서 테스트코드는 기능구현이 완료되면 즉시 작성하여 검증하는 습관을 가져야 할 것 같다.
- N+1
기존에는 jpql을 사용했는데 TA님 권고로 querydsl을 사용하게되었다. 정말 편리하게 쿼리를 짤 수 있었고 덕분에 기능구현을 빨리 할 수 있게 해준 효자같은 기술이었다. 문제는 N+1문제였는데 실제 수업시간에도 예제로 경험을 해봤고 왜 발생하는지 해결방안은 무엇인지 배웠지만 실제 프로젝트 상에서 경험한 것은 처음이었다
이런식으로 author와 publisher가 계속 나오는 것을 보고 이것을 어떻게 해결할 까 고민하다. join fetch를 사용하였다.
덕분에 해결했다!
사실 쿠폰의 경우 n+1문제가 발생안했다. 왜냐면 customrepository에서 간단한 쿼리제외하고 전부다 querydsl을 사용했고 entity(fetch type은 전부 lazy로 설정)에서 가져올때 조인테이블이 한개고 페이지 offset, pagesize를 설정해서 필요한 데이터를 한번에 쿼리로 가져오게끔 설계했다.
