코드 컨벤션
깃플로우 전략
배포 계획
이번 주 한 일
이외에도 기술적인 방향을 잡기 위한 질문을 정리해두시면 가장 좋습니다!
→ 단, “A는 어떻게 구현하나요”의 질문은 삼가주세요.
→ “A와 B를 알아보았는데, 둘 중 A가 낫다고 판단했는데 맞을까요?”의 식의 고민의 흔적을 담아 질문해주세요.
현재 Seat table 와 place table 가 구분되어 있는데, seat table를 단독으로 사용하지 않는 상황에서 구분할 필요성이 있을까요? → 이대로 하자~
/api/v1/places/{placecId}/goods/{goodsId}/sequences/{sequenceId}/seats/{seatId}
이 순서? 이렇게 작성하는 것이 맞을까요? → 이건 너무해…. 복합키로서 필요한 것만 쓰자;;;
→ 만약 어떤 메소드가 goodId가 필요하다면, 그거는 queryparameter로
dto → entity 변환 시
User of(String email, String password…),
User of(UserCreateRequest) entity는 request에 의존하지 않고 그 자체로 존재해야 한다고 생각
Request.toEntity(User) → User of(String email, String password…)
튜터님의 의견은? 궁금합니다? 저희는 User.of(request) 방식으로 결정했습니다.
이 부분의 이후 문제점을 발견, Sequence 같은 경우 request가 필요하지 않는데 이것을 통일화하기 위해서는 SequenceRequest를 만들어야 하는데 불필요한 request dto인데 맞는 것일까?
→ 하지만, 한 팀원의 의견(익명성 보장)은 굳이 entity를 생성하는 부분에서 이 request를 파라미터로 전달하는 부분이 꼭 모든 부분에서 통일화가 되어야 하는가? request를 전달하는 방식을 사용하자는 것은 개발의 편의성, 변경 가능성을 고려해서 적절한 방식을 혼용해서 사용하는 것이 어떤가입니다.
→ 이 request를 파라미터로 전달하는 방식과 필드를 파라미터로 전달하는 방식을 혼용해서 사용하는 것이 코드 내 통일성(= 컨벤션)을 위배하는 것인가? 에 대한 의견이 궁금합니다. → 저는 코딩 컨벤션이라는게 entity의 생성방식을 고정하는 것은 아니라고 생각하는데..
튜터님 한 말씀 ✅
**request.toEntity() → Entity.builder().build**
builder 패턴?
패키지 정렬? 배열?을 어떤 기준으로 하는 것이 명확할까요?
그냥 빼서 쓰자!
엔티티와 request, response dto 에서 원시타입과 참조타입의 사용
경매 남은 시간에 관련하여 의견이 있는데, 어떻게 생각하시나요? Good Idea
숙제: 멘토링 결과 다음 주까지 해올 일