![[팀]조규현 공간(1-2)](https://www.notion.so/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2Fbccf8e74-7462-46c9-bf54-264ba3f2845e%2F%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2021-09-27_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_5.45.11.png?table=block&id=f8e45e2e-c66c-48da-a402-d54b8154e4aa&cache=v2)
공통적으로 나온 코드 리뷰
- 불필요한 어노테이션
- 불필요한 주석
- createdBy 필드의 필요성
- GenerationType값 선택이유
- @Setter를 지양하자
- crud 반환값
- 주석 허용 범위
- @Transactional의 올바른(?) 사용법
- 예외 로그를 다 찍어야 할까?
게시글 수정 서비스 로직
- upsert
- upsert 기능이 필요하면 예외 처리가 아닌 null 분기처리로 로직을 이어나가자.(예외로 분기처리는 좋지않다고 본다.)
- 새로운 데이터를 생성 또는 수정할떄 다른 도메인을 find(참조)할 수 있는 상황에서 upsert를 사용할 수 있다.
- api의 기능으로 upsert를 사용하기보단 로직의 일부로 upsert가 사용되는 방향이 좋을 것 같다.
- patch VS put
- patch는 object의 한 필드 또는 부분적 교체할 때 사용한다.
- 수정될때 필드 데이터가 갱신되지 않으면 데이터를 유지한다.
- put은 object 대부분을 수정할 때 사용한다.
- 수정될때 필드 데이터가 갱신되지 않으면 null로 저장된다.
예외 로그를 다 찍어야 할까?
- 그렇다
- db 다운되면 get 요청이 로깅되어야 문제를 인지할 수 있을 것 같다.
- 아니다
- 사용자 단순 실수까지 로그를 찍어야할까? 정말 심각한 오류가 터졌을 때 로그가 너무 많으면 유의미한 정보를 얻어내기 힘들 것 같다.
변수명
- postModifyRequest VS request
- postModifyRequest 같은 풀네이밍을 선호함
- 코드가 길어졌을 경우에는 조금 더 자세한 변수명이 편리하다고 생각이 들어서 최대한 자세한 변수명으로 적으려고했음.
- 코드의 일관성을 유지하기위함
- request
- class 이름을 상세하게 정하면된다.
- request만으로도 의미가 통하기때문에 request 네이밍도 충분하다.
- 때로는 유연성을 가져가야할때도 있다.
return ApiResponse.ok("게시글 다건 조회 성공", posts);
- 메세지의 영역은 백엔드가 아니라 프론트의 영역이라고 생각한다.
- 메세지를 수정하기위해 서버 배포를 해야할까?
- 국제화 측면에서 생각해보자.
PostDto 관련 궁금증
각 요청마다 dto를 통해 전달해야 하는 데이터에 약간의 차이가 있습니다. 현재는 하나의 dto를 사용하고 있는데 어떻게 바꿀 수 있을까 생각을 해 볼 때,
- 각 케이스마다 꼭 필요한 field만 가지는 dto를 여러 개를 만들어서 사용하는 것과 공통되는 field를 가지는 dto를 빼도 좋을 것 같다.
ENUM
- Enum 상태 머신을 찾아보자!