[TIL]20220918

오늘 실전 프로젝트 3주차 중간발표가 있었다.

걱정이 굉장히 많았다. Todo List의 기능이 그래도 어느 정도 마무리가 되었지만 view가 아직 만들어지지 않아 시연 때 어떻게 보여드려야 하나 고민이 있었다.

프론트엔드 파트가 두분이셔서 참 너무 고생들이 많으셨다.

중간 발표 전날 우리는 view를 조금이라도 만들어보자 마음을 먹었고 나도 퍼블리셔 경험이 있었기에 프론트엔드 팀원들과 힘을 합쳐 밤새 view를 만들어 냈고 시연 때 어느 정도 구현한 기능들을 잘 보여드릴 수 있었다.

큰 탈 없이 발표를 끝 마쳤고 덕분에 앞으로 개발에 도움이 될 피드백들을 많이 얻을 수 있었다.

중간 발표에서 멘토님들께서 주셨던 피드백 내용들은 이러하다.

---

• 중간 발표 후 피드백 받은 부분 회의

  1. 질문 : 브랜치 주제가 너무 세세하다.

     • 피드백 Git branch convention으로 ex) feature/member/addKakaoLogin 식으로 정하였는데 이렇게 세세하게 할 필요가 없다고 말씀해 주셨습니다. ex) feature/todoAndTodoList → 만약에 todoList 작업 이 후, todo 작업을 할 때 todoList의 코드도 변경되는 부분이 생길 수 있어 한 사람이 작업을 해야 병합시 문제가 안 생기고 따로 작업을 할 경우 한 명이 작업하는 것이 좋겠다고 말씀해주셨습니다. (리소스를 낭비 할 수 있는 부분일 수 있다.)
       
     • 추후 상의한 내용 코드 컨벤션을 말씀해주신 부분을 참고하여 수정
       

  2. 질문 : like 같은 경우는 todoListId에 like를 하는 것이고 나중에 사용자나 행성에 like를 누르거나 했을 때 likeController가 더 커질 수 있을 것 같다.

     • 피드백 지금 현재는 likeController가 todoList를 like하는 것 밖에 없으므로 todoList 안에 넣는 것이 좋겠다.
       
     • 추후 상의한 내용
       1. todoList패키지 안에 like패키지를 넣는다.(선택, 추 후 확장성을 고려)
       2. todoList패키지 안에 like패키지를 넣는데 controller와 service를 합친다.

  3. 질문 : controller에서 service를 바로 리턴을 했다.

     • 피드백 controller를 봤을 때 깔끔하다라는 느낌은 들지만 controller에서 service를 리턴 할 때, 리턴 타입이 명확하게 드러나게 해주는 편이 좋다.
       
     • 추후 상의한 내용 → ex) controller에서 reture followService.getFollowers(memberId, request); → 한 줄을 추가해 리턴 전에 Boolean isSuccess = followService.getFollowers(memberId, request)를 적고 return new ResponseEntity<>(Message.success(isSuccess), HttpStatus.OK);
       

  4. 질문 : 현재 만나고 있는 JPA의 한계점이 어떻게 될까요

     • 피드백 답변시 “이런 이야기가 있더라고요”는 안 좋은 답변이 될 수 있다. 쿼리DSL, JPA 부분은 속도나 쿼리 날라가는 부분을 실제로 파악하고 넘어가야 된다. 스레시 홀드를 여러분이 한 번 잡아봤으면 좋겠다.
       
     • 추후 상의한 내용 이 부분은 실제로 두 가지 다 적용해보고 제이미터나 테스트코드를 활용해 파악해 볼 예정입니다.
       

  5. 질문 : 커밋메세지를 보다가 발견을 한 부분인데 나누기 0 관련된 문제를 해결한 부분이 있었는데 어떨 때 나타나는 현상이었나요(todo를 삭제 했을 경우 달성률 테이블의 달성률의 분모가 0이 되는 부분)

     • 피드백 Dto 벨리데이션에서 체크를 할 수 있을 거 같다. 리턴되는 값이 0이거나 들어갔을 때 쿼리가 0이거나 했을 때 벨리데이션을 강화했으면 좋겠다. Dto단에서 혹은 Response단에서 체크를 해봤으면 좋겠다라는 생각을 해봤습니다.(todo가 없을 때 not null이 발생하는 문제)
       
     • 추후 상의한 내용 Dto에 컬럼 같이 어노테이션(@Vaild)을 붙여 조건처리 할 수 있을 것 같다. 이 부분은 적용 후 확인 예정
       

  6. 질문 : 배치를 쓴 이유

     • 피드백 스케쥴러만 써도 충분한데 스코프를 늘리기 위해서 배치를 사용하는 것이고 배치를 사용하는 것은 오버 엔지니어링이 될 수도 있다. 개발 스코프를 늘리고 내가 많은 것을 경험하고 싶다도 좋은 이유겠지만 스케쥴러로 간단하게 구현해보는 것도 리소스를 최소하는 방법을 찾아가는 방법이 아닐까 하는 생각이 들었습니다.
       
     • 추후 상의한 내용 스케쥴러를 먼저 구현해보고 이후 배치를 할 수 있다면 하는 방향으로 생각중입니다. → 위키에 남길 예정
       

  7. 질문 : JPA에서 나오는 쿼리 중에 기억에 남는 쿼리가 있나요(답변 : 쿼리가 너무 많이 나와 JPA나 쿼리DSL이나 이런 부분으로 넘어갔습니다.)

     • 피드백 모든 테이블이 조인으로 잘 물려 있어서 그런 것 같다.(ERD를 보니까) 그런 것들 때문에 겪는 문제 같다. 쿼리 계속 날려보면서 어느 부분에서 얼마나 쿼리가 더 많이 나오는지 잘 비교를 했으면 좋겠다. 나중에 최종발표를 위해서는 중요한 의사결정과정이 될 수 있으므로 잘 챙겨주셨으면 좋겠다.
       
     • 추후 상의한 내용 조인된 부분에 대한 조회과정에서 조인된 엔티티의 컬럼을 사용하는 경우 쿼리가 한번씩 더 생기는 N+1문제가 나온 것 같다. 복잡한 쿼리를 하는 경우에는 JPA만으로는 해결이 안되는 부분이 있었다. 다양한 쿼리를 적용해보고 비교해 볼 예정
       

  8. 다른 조의 피드백 중 기억에 남는 부분(프리커밋 - 자바단에서 잡아줄 수 있음)

  9. 프론트 피드백에서 백엔드에 대해 나온 부분

     1. 프론트에서 유효한데이터를 보내줄거란 생각을 버려야 된다.

        (반대입장에서도 마찬가지)

     2. 소셜로그인과 이메일이 중복될 수 있는 부분

     • 추후 상의한 내용

       1. 프론트에서 보내준 데이터에 대한 검증과정을 추가하려고 한다.

       2. 현재 상태) 카카오의 이메일이 이미 가입된 아이디의 이메일과 같은 경우에 카카오 로그인을 시도하면 기존 아이디로 로그인 됨

          1안) 카카오 로그인을 할 때 이메일을 체크하고 이미 가입된 아이디가 있는 경우에 가입된 이메일이라고 막는 방식

          2안) 카카오 로그인을 하는 경우 회원 가입시 이메일 정보 뒤에 #KAKAO 과 같은 형태의 문자열을 추가하여 구분해 줌 (선택)

  10. 회의 중 나온 의견

      카카오로그인시 강제로그인처리가 있어 같은 방식으로 일반 회원가입시 바로 로그인이 되어 메인페이지로 넘어가는 방식도 괜찮을 것 같다.

---

그리고 현재 스파르타코딩에서 주최하는 스파르톤에 참가 중이다.

우리 백엔드 팀원들과 합심해서 함께 참여하게 되었다. 밤새 코딩 버닝타임을 갖자는 취지인데 오늘 우리는 스프링 심화 강의 중 "테스트 코드 작성"에 대해 각자 다뤄보며 현재 진행 중인 프로젝트에 도입을 해볼 생각이다.

내가 맡았던 "n월의 리포트" 관련 기능에서 다양한 쿼리로 조회를 해야 하는데 N+1문제도 그렇고 JPA만으로는 원하는 데이터를 조회하는데 어려움이 있어 JPA, QueryDSL, JPQL, Native Query 도 활용해볼 생각인데 저 여러가지중 어떤 시점에 어떤 것을 활용해야 할지 아직 판단이 잘 서지 않는다.

그래서 팀원들과 논의해본 바, 여러가지 방법으로 조회해 보고 테스트 코드를 통해 속도를 비교해서 더 속도가 빠른 방법으로 선택을 하자고 했다.

딱 한가지만 통일해서 사용하기보다 적절한 시점에 적적한 것을 사용하는게 좋을 것 같다.

미루다 미루다 드디어 해보게 됬던 부분인데 열심히 강의를 보러 가보겠다.

화이팅!