코딩 컨벤션

IntelliJ Code Style

컨벤션

naver code style

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

@validation 전략

DTO 전략

// Dto패키지 안에 
public record ${entity}Request(){
	public record createRequest (...){
	}
		
	public record updateRequest (...){
	}
}

=============== 서로다른 클래스 영역 ===================

// Dto패키지 안에 
public record ${entity}Response(){
	public record naming ... (...){
	}
}

Exception 관리

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

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

• 풀어서 넘긴다.

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

Interface 네이밍

• 형~ 용사

테스트 코드 규칙

• 통합테스트 작성 시 모의 데이터가 필요할 것이다. 나의 경우 팔로잉 멤버 목록 조회 기능에 대한 통합테스트를 짜던 중 팔로우 테이블에 데이터가 미리 적재되어 있었어야 했었다.

• MemberService에서 통합 테스트를 하던 중 Follwe 테이블에 데이터를 저장하기 위해 Follow 레포를 가져다가 쓴다고 했을 떄, 해당 도메인에 대한 통합 테스트인데 다른 데이터가 필요해서 각각의 레포짓토리를 의존성을 주입받아도 되나? 라는 생각을 시작으로 약간의 상황을 가정해봤다.

• 예를 들어 게시판 경우라고 생각해보았을 때 사용자 데이터도 미리 있어야 하고, 이미지도 있어야 되고 등 팔로잉한 데이터 또한 존재해야 한다고 했을 때 게시판 통합 테스트에서 해당 repository들을 전부 @Autowired로 할경우 해당 필요한 데이터 도메인에 따라 비례적으로 코드량이 증가할 것이다.

@Autowired MemberRepository

@Autowired ProfileImageRepository

@Autowired CommentRepository
...

private EntityManager ...;

// 단 하나의 선언으로 여러가지 레포의 의존성을 대체할 수 있고 코드 또한 줄어든다