항해99 9주차 WIL

중간발표가 있었다. 피드백내용이다.

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

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

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. 회의 중 나온 의견
    카카오로그인시 강제로그인처리가 있어 같은 방식으로 일반 회원가입시 바로 로그인이 되어
    메인페이지로 넘어가는 방식도 괜찮을 것 같다.