46_기초프로젝트 발표 후 회고_25.2.20(목)

기초프로젝트 발표 후 회고

우리 조에 대한 피드백은 다음과 같다.

발표자료가 깔끔하고

스웨거 썼는데 대신 잘 안 보인다고 하셨고

너무 잘하셔서 더 말씀 드릴 것이 없다고 하셨다.

굉장히 열심히 하신 것 같다고 말씀해 주셨다.

따로 질문 주실 줄 알았는데

안 주셔서 의아? 했다.

우리 조 팀웍이 빛을 발했던 것 같다.

 

 

<우리 조 담당 튜터님 피드백>

• 리드미 : 스택 위에 올려도 좋다
• application.properties - DDL 옵션→ 진짜 혼자 간단하게 작업할 때에만 사용해라 .
  웬만하면 create/create-drop/update 옵션은 지양하자
• → main에 올릴 때에는 수정해라 (개발용으로도 create는 잘 안씀)

<Auth>

• User 엔티티가 직접 컨트롤러에서 사용된 부분 ( AuthController )
  • jpa OSIV 옵션 : 세션(DB와의 연결)을
  • → 설정 안하면 기본옵션이 true이지만 실무에서는 false로 끄는 경우가 있다.
    (application.properties에서 옵션 끌 수 있음)
  • 트랜잭션 단위에서 영속성 관리를 하는데 현재는 트랜잭션을 벗어난 범위임
  • 유저가 없을 때 에러 발생 → 이런 것도 비지니스 로직이라고 생각할 수 있음 (서비스로)
  • 컨트롤러 : 요청과 반환을 결정하는 역할만 담당한다.
  • ⇒ login 메서드의 반환형이 오히려 token으로 구현할 수 있음
  • 옵션 true → 커넥션을 서비스에서 끝낼 수 있는걸 컨트롤러로 가져오는 것임
• 트랜잭셔널 어노테이션이 전체적으로 적용되면 클래스 단위에 붙일 수 있음

<Comment>

• rest 관점의 이야기
  • comments/{commentId}: 괜찮음
  • comments/{postId} : restful 하지 않음. 코멘트 뒤에는 코멘트가 와야함ex ) localhost:8080/comments?postId=1
  • 특정 리소스 뒤에는 해당하는 자원이 와야하고 다른걸 받아야하면 파라미터로 하자
  • → 댓글 생성 : comments로 끝내고 postId는 파라미터로 받는 게 좋겠다
  • REST : Representational State Transfer (자원의 표현법)
• 메서드 작성할 때
  • findByPost 메서드: 서비스 계층에서는 get
    • find(찾다) : 레파지토리(데베)에서 찾는거임
    • Get(조회) : 서비스 입장에서는 단순히 매핑시켜서 가져오는게 끝임
  • : 레파지토리에서 찾는 거는 find
• CommentService 에서 다른 도메인의 레파지토리를 사용하면 안된다!
  • 클린 아키텍처 그림
  → 개발에는 아무런 문제가 없다! 하지만.. 코멘트 서비스를 만드는 사람이 유저/포스트레파지토리에 막 접근하면 필요한 메서드를 막 만들게 되고 해당 도메인을 참고하지 않고 중복 코드도 많이 생기고 선을 넘게되고..
• 서비스 레이어를 한 번 거쳐서 받기

<friend>

• url 매핑 request - 예약어가 될 수 있음
  • 그냥 request 없이 friends로 친구신청할수있음
  • 헷갈린다 그냥 메서드명 send 로 하자
  • 프렌드서비스에. 보낸다 .(로그인Id가 receiverId에게) 이런 식으로 메서드 작성하면쉬움!
  • : 파라미터 = 목적어 느낌이다
• 딜리트매핑과 패치매핑..
  • 수락 or 거절
  • 컨트롤러에 API 가 너무 많다.
• 친구 한명 삭제 → pathVariable로… friendId 혹은 userId → 코멘트꺼를 참고하자!
• 너무 긴 메서드 : JPQL 쿼리를 직접 표현해보자
  • 메서드의 하고자하는 목적 자체가 .
  • findFriendRequestByStatus
• update할때 log느낌의 메세지는 반환하지 말자
• user1 user2 이런식으로 하지말고 로그인된 사용자→ loginUser / targetUser

<post>

• findAllPage 메서드는 페이지네이션이 들어간다? 애초에 맞지않는말⇒ getPosts 이런식으로 하자
• → findAll은 jpa에서는 테이블 전체를 의미하는 것임
• 페이지네이션 → Page<>에는 불필요한 것들이 많이 들어있음: spring pagination response common object 이런식으로 찾아봐라
• ⇒ Page를 직접 반환하지 말고 Page용 공용객체(?)를 반환하면 좋음
• 소프트딜리트 이후 게시글 복구 → PatchMapping
• 친구 게시물 조회 → 도메인 특화된 느낌으로 바꿔도 좋을듯 post/뉴스피드
• 정적 팩토리 메세드: 매번 생성자를
• : 가독성 굿
• 엔티티에 직접 옵션을 주는게 좋지않다
  1. 데베를 다루면 서비스를통해 쿼리를 사용하는데
  2. → 거기에 조건드는걸 보려면 엔티티를 봐야함 (협업 관점에서 좋지않다)
  3. deleted_at =null의 조건이 항상 붇는가? (아님)⇒ admin 전용 서비스/레파지토리를 따로 구현
  4. → 이런 필터나 SQLRestriction 옵션 등은 실무에서 안씀!!(충격..)
  5. → admin 계정같은 경우를 생각해봤을때 무조건 필터로 거르는게 안좋음
• created_at 내림차순 → enum으로 관리하면 굿
  • 포스트서비스에 페이징 → createdAt(string으로 하드코딩한거 안좋음)

<user>

• ResponseEntity → 공통 Response 객체를 만들면 좋다
  • public Response<> 메서드() {return Response.of(todo); }
  • ok만 찍어주기위해 responseEntity를 사용할 필요가 없음
• PatchMapping(me/password) → 어차피 나니까 me는 필요없는듯
• 2주 지나면 삭제 → 초를 바꿔서 테스트 해보자.
  • 스케쥴 어노테이션 : 나중에 문제있을수있음
    • ex. 12시가 됐을때 특정 집단에게 메세지 보내는상황실무에서는 기본적으로 서버가 여러 대가 존재알림메세지전송 → 모든 서버에서 움직이면 한 명 당 서버의 갯수만큼 알림을 받게됨 허걱..
    • ⇒ lock 작업을 해야함
    • → 그 시간이 되면 모든 서버가 하나의 동일한 작업을 실행하게 된다..
    • : 어플리케이션 레벨에서 움직이는 어노테이션임

<전체>

동일 내용을 담은 request dto → 굳이 분리 안해도 괜찮다.

• 분리하는 경우 → 등록 후에 업데이트 하는 경우
• (일부만 변경은 patch로 업데이트)