1️⃣ 면담 일지
면담 일시 : 2022. 08. 07
참여 명단
- 김성현, 이용훈, 이예림, 훈 멘토님
면담 인증 샷
온라인 게더 모임 !
.png?table=block&id=d7b4f8e5-f5bf-46e5-bbaa-5fdff3505880&cache=v2)
면담 내용
진행사항
프로젝트 구조 보기
API 보기
Q&A
프로젝트 구조(ERD 확인)
- DB에 MBTI 정보를 다 가지고 있는게 나을 것 같다. (리펙토링을 하면 추가하면 좋을 것 같다.)
- 프론트에서 mbti를 가지고있지만 그걸 신뢰 할 수 없으니까
- 대댓글 대신 댓글을 여러개한다음에 시간순으로 보여주는게 나을 수 도있다 → 데이터가 많아지면 성능쪽 문제가 생길수도 있기 때문
코드 리뷰(API 보기)
- 이미지를 가생성으로 받고(방법1 따로), 이미지랑 텍스트를 다같이 받는 법 두가지가 있다.
- 파라미터랑 본문내용을 구분할 수 있도록 짜자. 괄호를 밑으로 내려서
- 유의미한 로직이 없으면 status code 하나로 통일하는게 좋을것 같다. (복잡하게 쓸필요가 없다.)
- 201 & 200 & 204 유의미한 행동을 하지 않는데 다 나눠서 보내줘야하나?
- 400대 에러 - 모든걸 구분하지 않아도.. api/posts/1 얘를 404로 받아야하나
- 피드파사드를 만들어서 안에 멤버랑 등등을 넣어서 만드는 식으로 구성을 해도 괜찮았던 코드를 봤다.
- dto 생성자 자체에 검증 로직을 넣어서 컨트롤러에서 반환할 수 도 있다. view에 던져주기 위한 response dto
- totalcount를 api로 따로 만들어 한번만 보내줘라 (댓글 totalCount)
- hasnext대신 nextId값을 넘겨준다. 그리고 화면에서 size가10개인데 8개 넘겨주면 그건 다음이 없는걸로 알고 처리하면 hasnext가 필요없다.
- 레포지토리 메소드에 soft delete인지 delete인지 표기해라 (changestatusdelete 같이)
- 지금은 프론트와 함께하니 api 스펙바꾸지말고 내부 리펙토링을 하는게 좋다.
- querydsl은 where절에 메서드로 동적쿼리를 넣으면 더 깔끔할 것 같다.
- baseTime이랑 baseEntity랑 나눠서 쓴거 좋은 것 같다.
- totalElements → size로 그냥 쓰면 될 듯
Q&A
예림
- 댓글이나 좋아요기능에서 포스트가 있는지 validation을 할때
1) 댓글, 좋아요에 연관관계 맺은 포스트를 가져와야할지,
2) post를 먼저 findbyId로 찾아야할지 → 더 간단하지 않을까? 포스트가 없는 예외 메시지를 날려 줄수도 있으니까
3) 조인쿼리를 만들어서 한번에 가져오는 방법
- delete할때 아무것도 보통 안넘겨 주고 204?
- 프론트에서 받아서 유의미 처리를 하지 않으면 굳이 id를 보내주거나 204를 보내주어 복잡하게 처리 할 필요가 없다.
성현
- multipart 수정 post로 해도 되나요?
- 이미지 삭제는 따로 api 빼서 할 수 있을 것 같음.
- patch put 지원 안하는건 어쩔 수 없음. post로 쓸 수 밖에..
- soft delete하니까 join 쿼리가 너무 많아지고 repository가 너무 많아져서 이게 맞는건지?
- 하이버네이트에서 지원하는 where절을 쓸 수 는 있는데, 그럼 안원할때도 다 붙어버려서 흠 어쩔수 없다. (선택 필요)
- order by가 많아지면 메모리에서 가지고있는게 좋지 않나?
- 시간측정해서 테스트를 해보는게 나을 듯
- 정렬까지 굳이? 라는 생각이 들긴한다. (인덱스 잘 걸려있으면 굳이 할 필요는 있을까?)
- dto라는 이름으로 repository → service 줄 때 써도 되나?
- 서비스에서 사용하는 쪽은 이름을 좀 바꿔주면 되지 않을까? ~dto라고하는게 여러개층에 쓸 수 있는 포괄적인 의미같다. 서비스에 사용하는거를 이름을 조금 바꾼다던가 하면 될 것 같다.
- 이름은 조금 고민을 해보세요.
- 불편함을 느끼면 바꾸기도 하고 그러는듯 !
** 멘토님 전달 참고자료 **
- soft delete
