진행사항
프로젝트 구조 보기
API 보기
Q&A
프로젝트 구조(ERD 확인)
- DB에 MBTI 정보를 다 가지고 있는게 나을 것 같다. (리펙토링을 하면 추가하면 좋을 것 같다.)
- 프론트에서 mbti를 가지고있지만 그걸 신뢰 할 수 없으니까
- 댓글 여러개한다음에 시간순으로 보여주는게 나을 수 도있다 → 데이터가 많아지면 성능쪽 문제가 생길수도 있다.
코드 리뷰
- 이미지를 가생성으로 받고, 이미지랑 텍스트를 다같이 받는 법 두가지가 있다.
- 파라미터랑 본문내용을 구분할 수 있도록 짜자. 괄호를 밑으로 내려
- 유의미한 로직이 없으면 하나로 통일하는게 좋을것 같다. (복잡하게 쓸필요가 없다.)
- 201 & 200 & 204 유의미한 행동을 하지 않는데 다 나눠서 보내줘야하나?
- 400대 에러 - 모든걸 구분하지 않아도.. api/posts/1 얘를 404로 받아야하나
- 피드파사드를 만들어서 안에 멤버랑 등등을 넣어서 만드는 식으로 구성을 해도 괜찮았던 코드를 봤다.
- dto 생성자에 로직을 넣어서 컨트롤러에서 반환할 수 도 있다. view에 보여지는 것.
- totalcount를 api로 따로 만들어 한번만 보내줘라
- hasnext대신 nextId값을 넘겨준다. 그리고 화면에서 10개인데 8개 넘겨주면 그건 다음이 없는걸로 알아라 같이 생각을 하면될듯.
- 레포지토리에 soft delete인지 delete인지 표기해라 (changestatusdelete 같이)
- api 스펙바꾸지말고 내부 리펙토링을 하고 면접이랑 cs공부를 해라
- where절에 빼서 메서드로 동적쿼리를 넣으면 더 깔끔할 것 같다.
- baseTime이랑 baseEntity랑 나눠서 쓴거 좋은 것 같다.
- totalElements → size로 그냥 쓰면 될 듯
Q&A
예림
- 댓글이나 좋아요기능에서 포스트가 있는지 validation을 할때
1) 댓글, 좋아요에 연관관계 맺은 post를 가져와야할지,
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라는 이름으로
- 서비스에서 사용하는 쪽은 이름을 좀 바꿔주면 되지 않을까? ~dto라고하는게 여러개층에 쓸 수 있는 포괄적인 의미같다. 서비스에 사용하는거를 이름을 조금 바꾼다던가 하면 될 것 같다.
- 이름은 조금 고민을 해보세요.
- 불편함을 느끼면 바꾸기도 하고 그러는듯 !
용훈
** 멘토님 전달 참고자료 **
- soft delete
