💪프로젝트에서 사용한 혹은 사용 예정인 기술 스택은 무엇인가요?

이번 주

백엔드

• Java
• Spring
• JavaMailSender
• Spring Security
• H2 database - 테스트용

예정

백엔드

• AWS S3
• OAuth - AccessToken, RefreshToken
• Redis - blacklist 관리
• QueryDSL - 예약의 복잡한 쿼리에 필요할 것이라 생각됨

💪이번 주 진행상황

API 명세서 (1)

💪이번 주 트러블 슈팅

• 문제에 대한 한줄 요약(Template)
• 예약 시간 중복 검사 관련 구현 문의

💪 멘토님께 질문사항

• 어느 정도까지 리뷰를 하면 좋을까요?
• PR에서 테스트 코드를 상세히 적는 것은 어떤 내용을 적는 게 좋을까요?
• application.yml, application-sample, application-dev 로 구성해서 관리하고 있습니다. application-dev만 git에 올라가지 않게 하고, 개발자끼리 다른 채널을 통해서 관리합니다. 이걸 관리하는 다른 좋은 방법이 있을까요?
• 기능 별로, 몇가지 테스트 케이스는 만들어야 안전하다고 판단할 수 있습니까?
• 간단한 주석 제거나 스타일 수정에 대해서도 PR을 직접 만들어 올리나요? 아니면, 다른 개발자들에게 알리고 직접 main에 푸시하기도 하나요?
• 아래 코드처럼, 위에 코드는 responseBody를 안보내서, 저희가 Enum type인 메세지 클래스로 프론트단에 알려주는데, 밑에 sign-in처럼 body를 보내줄떄, 여기서도 SuccessMessage.SIGN_IN_SUCCESS라는 메세지를 보내주는게 좋을까요? 아니면 로그인 성공했을때 refresh이랑 accessToken을 받으니까 굳이 메세지를 보낼 이유가 없나요?
• test case일 경우에는 any()는 무조건 XXX
• to 나 from 빌더 위치는 아무대나 써도 상관없다. 멘토님은 entity에 만드는것을 선호. 단방향이면 상관 x
• void를 리턴으로 받기 보다는 값으로 받는 것 추천 → 다양한 곳에 활용할 수 있음. 테스트 용도로도 유용함. ResponseDto
• 생성 조회 수정 삭제도 다 따로 pr 만들기
• 트랜잭션은 최소한으로 걸어야한다고 생각