Code Convention

• Entity
  • setter 사용 금지
    • 1번 해당 필드 값을 변경을 위한 메서드를 만들자 @setter 쓰지 말자
      • 프로필 업데이라고 가정을 한다면 updateProfile(String name, String passwrd)
  • private Builder → Builder 강제함으로써 코드 통일성 📈
• 객체간 변환 작업
  • static method dto 내부에서 선언하고 to 로 반환
• Custom ResultCode 사용
  • Domain 별 ErrorCode + CommonCode
• Custom ResponseEntity 사용
• 공통 예외 → 따로 클래스 만들지 않고 공통적으로 처리
• api 1개당 dto 1개씩 (req, res)
  • card → comment → task (계층을 표시하지만 모든 계층을 표기하기 보다는 자신의 부모 요소 하나정도로 가져간다.)
    • 1번 task → api/v1/comment/{commentId}/task
  • 단건 조회 @Pathvariable 사용
    • 요청할 데이터가 1개일 경우만 해당
    • 2개 이상은 Dto에 담아서 요청

Code Style

• **GoogleStyle → 인텔리제이 기능 을 더 사용해서 하자!**
• 저장할때 자동 정렬 build 정렬

네이밍 규칙

• dto

  도메인 + 기능 + 요청 / 응답 Req / Res

  • request: Req
  • response: Res

• 메소드명: 무슨 일을 하는 메소드인지 이해될 정도면 됨

• Entity

  • 엔티티명: 도메인명 그대로 ex) User

  • 테이블명: 예약어만 s 붙히기

  • 참고 자료 : https://dev.mysql.com/doc/refman/8.0/en/keywords.html#keywords-8-0-detailed-U

  • Optional를 빼지 않는다 → Optional<User> findById(Long Id)

    public Card verifyExistsCard(Long cardId) {
          return cardRepository.findById(cardId)
              .orElseThrow(() -> new CardNotFoundException(ErrorCode.CARD_NOT_FOUND));
    }
    

• Service

  • update → transactional, LAZY → tr = readonly = true

• Test

  • 단위 테스트로 진행
  • 테스트 변수 파일에 모아서 상속받아 사용!
  • 자신이 맡은 부분은 테스트코드 자신이 작성하기!

• 패키지 구조

  • domain / global / infra (도메인 별로)

• User

  • 소셜로그인
    • google, naver, kakao
  • 로컬로그인
    • 닉네임(ID) / 전화번호 / 패스워드 회원가입
    • id → autoincrement
  • 소셜 / 로컬 다른 유저 취급
  • filter / 로그아웃 filter 처리