백엔드 코드 컨벤션

📄 코드 스타일 컨벤션

1. 기본적인 코드 스타일은 우아한테크코스코딩 컨벤션(xml)을 따른다.
   • Intellij 스타일 컨벤션 xml 적용
2. 클래스 내 순서
   1. 상수 → 인스턴스 필드 → 생성자 → 기능 → getter → setter → equals → hashCode → toString
3. 줄 바꿈도 컨벤션이다.
   1. 클래스 선언부와 필드 사이에 공백 한 줄 추가한다.
   2. 인스턴스 변수 사이에 개행을 한다.
   3. 메소드 사이에 개행을 한다.
   4. 클래스 마지막에 개행을 하지 않는다.
   5. 파일 마지막에 개행한다.
4. 네이밍
   1. 상수(static final)는 대문자, 스네이크 기법으로 작성한다.
   2. 변수(인스턴스 변수, 메서드 파라미터, 메서드 변수)는 소문자 카멜 기법으로 작성한다.
5. 어노테이션은 대상(클래스 혹은 메소드)의 정체성과 가장 가까운 순으로 선언부에 가깝게 한다.
6. 객체 필드, 메소드 파라미터, 메서드 변수에 가능하면 final 을 붙인다.
7. 패키지명은 단수, 소문자로 한다.
8. 생성자 선언 순서는 파라미터가 적은 순서대로 작성한다.

package com.naaga.domain; // (5)

@EntityListeners(AuditingEntityListener.class)
@Entity // (3)
public class Example {
    // (2)
    private static final Example FIXED_EXAMPLE = new Example(1L, "나아가", 20);

    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Id // (3)
    private Long id;

    private String name;

    private int age;

    public Example() {...} // (8)

    public Example(final String name) {...} // (8)

    public Example(final String name, final int age) {...} // (8)

    public Example(final Long id, final String name, final int age) {...} // (8)

    public void doSomething(final String a, final int b) {...} // (4)

    public Long getId() {...}

    public void setId(final Long id) {...}

    public boolean equals(final Object o) {...}

    public int hashCode() {...}

    public String toString() {...}
}

☕️ JAVA 코딩 컨벤션

📖 기본

• 객체지향 생활 체조 원칙 중 아래의 원칙을 기본으로 한다.
  • 한 메소드에 오직 한 단계의 들여쓰기(indent)만 한다.
  • else & switch예약어를 사용하지 않는다.
  • 게터를 지양한다.
  • 줄여쓰지 않는다(축약 금지).
  • 한 줄에 점을 하나만 찍는다.
  • 일급 컬렉션을 쓴다.
  • 모든 엔티티는 작게 유지한다.
• Lombok은 사용하지 않는다.
• record는 DTO와 VO에서 사용한다.

🧪 테스트

공통

• 네이밍 규칙
  • 테스트 메서드명을 한글로 작성한다.
  • 테스트 메서드의 @DisplayName 애노테이션을 생략한다.
    • @SuppressWarnings("NonAsciiCharacters")와 @DisplayNameGeneration(ReplaceUnderscores.*class*) 어노테이션을 테스트에 추가한다.
  • 예외케이스에 대한 테스트 메서드 네이밍은 ~ 하면 예외가 발생한다.로을 통일한다.
  • 생성로직에 대한 테스트 메서드 명은 ~ 생성한다.로 통일한다.
• 테스트가 어려운 외부 서비스는 TestDouble을 적용한다.
• 테스트 클래스의 빈 주입은 필드 주입을 사용한다.
• 테스트 Fixture & Builder
  • id가 null한 픽스쳐를 매번 생성한다.
  • 영속화 시키는 방법은 Builder로 구현한다.
• given, when, then 주석을 명시적으로 붙인다. 생략하지 않는다.
  • given, when, then 절을 나누기 곤란한 경우 given, when & then 과 같이 & 으로 합쳐 작성한다.
    • // given & when
    • // when & then
    • // given & when & then

@Test
void 없는_장소를_조회하면_예외가_발생한다() {
	// given
	final Place place = new Place(...);
	placeRepository.save(place);
	
	// when & then
	assertThatThrownBy(() -> placeRepository.findById(-1L))
		.isInstanceOf(PlaceException.class);
}

@Test
void 장소를_아이디로_조회한다() {
	// given
	final Place expected = new Place(...);
	placeRepository.save(place);
	
	// when
	final Place actual = placeRepository.findById(place.getId());

	// then
	assertThat(actual).isEqualTo(expected);
}

E2E 테스트

• RestAssured로 작성한다.
• 응답 바디는 usingRecursiveComparison() 사용한다.
  • 비교가 불가능한 필드는 ignore한다.

⛓️ JPA

• @Entity 클래스의 이름을 단수로 한다.
  • 만약 MySQL 예약어와 겹치면 다른 단어를 선택한다.
• @Entity 클래스의 기본 생성자는 protected 로 지정한다.

📁 패키지 구조

도메인 패키지 구조

├── main
│   ├── game
│   │   ├── application
│   │   ├── config
│   │   ├── domain
│   │   ├── exception
│   │   ├── infrastructure
│   │   ├── persistence
│   │   ├── exception
│   │   └── presentation
│   ├── player
│   │   └── ...
│   └── ...
└── test
    ├── game
    │   ├── application
    │   ├── config
    │   ├── domain
    │   ├── exception
    │   ├── infrastructure
    │   ├── persistence
    │   ├── exception
    │   └── presentation
    ├── player
    │   └── ...
    └── ...

예외처리

• 도메인 단위로 예외를 클래스를 생성한다.
  • 그 도메인 예외에 대한 enum Type을 나눠 상황을 정의한다.

메소드 네이밍 규칙

• Controller
  • 조회 요청 : find~()
  • 쓰기 요청 : create~()
  • 삭제 요청 : delete~()
  • 수정 요청 : update~()
  • DTO
    • 요청 DTO : ~Request
    • 응답 DTO : ~Response
• Service
  • 조회 메서드는 맨 아래에 위치한다.
  • 조회 요청 : find~()
  • 쓰기 요청 : create~()
  • 삭제 요청 : delete~()
  • 수정 요청 : update~()
  • DTO
    • 입력 DTO : ~Command
    • 반환 : 도메인
• Repository
  • Spring Data JPA 쿼리 메소드 명명을 따른다.