🛠️ BE 코드 컨벤션

스타일

• 개행

  • class 첫 필드는 한 줄 개행 후 작성한다.
  • class 마지막 중괄호는 method 마지막 중괄호 한 줄 아래 위치하도록 한다.
  • 메서드 내의 개행은 논리적 단위로 삽입한다.

• import

  • 순서 : Code Style - Java - Import Layout에서 Layout static imports separately 적용

    import all other imports
    import javax.*
    import java.*
    <blank line>
    import static all other imports
    

  • wildcard : Code Style - Java - Classcount to use … 및 Names count to use … 99로 설정

• 메서드 순서

  • public-private 정렬 순서

    • public 메서드내의 private 메서드는 public 메서드와 가까운 아래 위치시킨다.
    • private이 계속 사용될 경우, 가장 처음 사용한 public 메서드 아래에 위치한다.

  • 메서드 정렬 순서

    • 컨트롤러와 서비스에서 CRUD 순서대로 작성
    • 협업할 때 처음 해당 코드를 보는 사람이 순차적으로 코드 의미 파악하기가 더 용이하다.

• 스타일 파일

  • Code Style - Java - Schema에서 WootecoStyle 적용하여 일괄적으로 코드 스타일을 맞춘다.

코드

• final

  • field에만 사용한다.
  • 모든 곳에 final을 사용하는데 소용되는 리소스가 더 크다. 특정 상황에서만 명시하는 것이 더 효율적이고 의미 전달이 가능하다.

• equals & toString & hashcode

  • domain 및 entity에서 모두 재정의한다.
  • equals 시 id만 비교한다.

• service layer 반환 타입

  • DTO를 파라미터로 받고, DTO를 반환한다.

• repository element 없을 때 처리

  • repository에서 get 함수를 추가로 작성해 find 시 empty일 경우 예외를 발생시킨다.

• responseEntity

  • 상태 코드 쉽게 설정하기 위해 ResponseEntity를 사용한다.

• error의 경우, handler를 사용하여 처리한다.

• 스프링 씨큐리티의 경우, 사용하지 않고 배운 내용만으로 구현한다.

• DTO static 메서드를 활용할 때

  • from : 파라미터의 개수가 1개일 경우 사용한다.
  • of : 파라미터의 개수가 2개 이상일 경우 사용한다.
  • toEnity, toDamain 사용한다.

• 롬복 등 getter, setter 자동 생성 어노테이션은 사용하지 않는다.

• 변경 감지 기능 활용

• ErrorHandler로 들어오는 것들은 로그를 남기고, 추후 필요한 것들에 대해서는 개인적 판단으로 로그를 남긴다.

• DTO에서의 검증은 형태에 관련된 검증만 처리한다.

• id의 경우, Long이 아닌 long 타입을 사용한다.

테스트

• test 명
  • DisplayName: [기능] 성공 : ~ 경우 (생략 가능)
    • ex) 회원가입 성공, 회원가입 실패: 이메일 중복인 경우
  • (긍정) 메서드명 + 상황 있을 경우 _상황
    • ex) login / save
  • (부정) 메서드명_실패이유_exception
    • ex) login_passwordMismatch_exception / save_duplicatedName_exception
• TDD의 경우, 희망하는 인원만 진행하도록 한다
• test 방식

  • domain : 유닛 테스트 진행한다.

  • service : fixture 만들어서 사용한다. : 테스트용 DB를 사용한다.

  • controller : fixture 만들어서 사용한다. : E2E로 진행한다. : 다이나믹 테스트를 선택적으로 도입한다.

  • repository : 쿼리문을 따로 작성하는 경우에만 테스트용 DB로 작성한다.

설정

• OSIV 설정
  • 설정 파일에서 초기부터 끄고 진행한다.

네이밍

• controller, service 메서드 이름

  • controller

    • create, read, update, delete

  • service

    • create, read, update, delete 동일하게 작성하고 기능에 따라 명명한다.

• 패키지 이름

  • domain
  • repository
  • service
  • controller

진행

• 일주일 동안 페어를 진행해 본 후, 추후 지속 여부를 결정한다.
• 문서화는 노션과 swagger UI로 진행한다.

GIT

• PR

  • 페어 기간 동안의 작업은 다른 팀의 두 명이 각자 진행한다.
  • 페어 기간이 아닐 때에는 모두가 리뷰를 진행한다. 단, 모든 사항이 만족스러울 경우 간단한 리뷰만 남기고 approve 한다.
  • 리뷰의 경우, PR 작성 후 하루 이내에 작성해 준다.

• commit

  • 기본적으로 커밋 컨벤션을 따른다.
  • 기능 단위로 구현과 테스트를 같이 커밋한다.
  • 문장형이 아닌 단어형으로 작성한다. ex) 로그인 기능 구현

구조

• 패키지
  • 계층형 VS 도메인형
    • 계층형으로 했을 때에 패키지 안에 클래스가 쌓이며 가독성이 떨어진 경험이 있다.
    • 도메인으로 나눌 경우 각 기능에 따라 나뉘어 있어서 처음부터 파악하기 용이하다.