코딩 컨벤션

IntelliJ Code Style

컨벤션

naver code style

• * 와일드 카드 임포트 지양한다.

[No 확정]Repo, Service, Controller 메서드명

• 조회 메서드의 경우
• Repository, Service - find{메서드명}
• Controller - get{메서드명}
• 예외인 경우
• 아래와 같이 Get이 명확하게 더 잘 어울리는 경우에는 사용해주세요!

@validation 전략

• Controller Dto

• Entity

DTO 전략

• 편의상 Controller - Service 간의 DTO는 공용으로 사용합니다.

• 필요 시 Controller - Service 분리가 필요한 경우 별도의 DTO를 만들어 분리합니다.

• 기본적으로 inner record 형식을 따릅니다.
• example

public record XXRequest() {
	public record CreateRequest(String name) {

	}

	public record UpdateRequest(String name, String description) {
	
	}
} 

public record XXResponse(String id, String name, String description) {
	public record CreateResponse(String id) {

	}
	
	public record UpdateResponse(String name, String description) {

	}
}

Exception 관리

• 상속으로 가져가겠습니다.

Controller 에서 Service로 갈 때 DTO를 어떻게 넘길건지

• 변수가 4개 이하라면 풀어서 넘긴다.

• 휴먼에러 위험이 있다면 DTO를 만들어서 빌더 패턴을 고려하세요.

Interface 네이밍

• 형~ 용사

테스트 코드 규칙

• 접근제어자는 제외하기 (테스트 코드 클래스 자체에서만 사용되는 부분은 제외!)

• 통합 테스트에서는 테스트 데이터를 다룰 때에는 EntityManager 사용하기

• 테스트 코드 메서드에서는 test 이름은 제외
• ❌ testUpdateMatchStatus
• ✅ updateMatchStatus

아직… No 확정

• Service에서 Repository 결과 값을 그대로 반환하는 경우, 서비스 테스트 생략!!!



↑ Service 메소드
But! Repository의 메서드가 표준 스펙의 메서드가 아니라면 Repo 테스트 작성 필요

Swagger 컨벤션

1. 스웨거 어노테이션은 상단에 위치

2. @Operation 어노테이션
• summary : 문장이 아닌 키워드로 ex) 로그인, 회원 가입, 팀 공고 등록
• description : ~한다. 처럼 문장을 간결하게 잘성해주세요. 길이를 간결하게 가져가기 위해서 이렇게 작성했습니다.

3. @Schema 어노테이션



• Id(PK)인 경우 고유 PK라고 명시



• Enum인 경우, description에 추가로 작성