[BE Rules]

코드 컨벤션

• 낙타 표기법(Camel Case)를 따른다.
• 클래스명은 대문자로 시작한다.
• 변수와 메서드는 소문자로 시작한다.
• 클래스명과 변수명은 주로 명사, 메서드명은 주로 동사를 사용한다.
• 클래스 이름 예 : Rectangle, LaundryList, StudentDirectory
• 변수 이름 예 : firstName, description, mediaController
• 메서드 이름 예 : getFirstName(), cancelOrder(), isDeleted()
• 들여쓰기가 3번 이상인 메서드의 경우 메서드를 분리하는 방법을 찾는다.
• 메서드 라인이 20줄을 넘어가는 경우 메서드를 분리한다.
• else는 사용을 지양하며, if절에서 값을 바로 return해서 메소드를 종료하는 것을 권장한다.

커밋 컨벤션

• [타입] "커밋 메시지 내용" (#<이슈번호>)로 커밋 메시지를 작성한다. (예: [feat] S3 스토리지 도입 (#5))
• 타입은 아래로 나눌 수 있으며, 주로 feat/fix/refactor/style을 활용한다.
• build: 시스템 또는 외부 종속성에 영향을 미치는 변경사항 (npm, gulp, yarn 레벨)
• ci: ci구성파일 및 스크립트 변경
• docs: documentation 변경
• feat: 새로운 기능 구현
• fix: 버그 및 에러 수정
• perf: 성능 개선
• refactor: 버그를 수정하거나 기능을 추가하지 않는 코드 변경, 리팩토링
• style: 코드 의미에 영향을 주지 않는 변경사항 ( white space, formatting, colons )
• test: 누락된 테스트 추가 또는 기존 테스트 수정
• revert: 작업 되돌리기

패키지 구조

• 패키지는 관심사별로 나눌 수 있으며, 하위 구조는 아래와 같아야 한다.

- name
    ├── entity
    ├── repository
    └── service
    └── controller
    └── config
    └── exception
    └── etc (기타 필요할 경우 추가)

기본 개발 사이클

• 커밋 메시지와 동일한 형식의 제목으로 issue을 개방한다.
• 위 컨벤션을 준수하며 개발을 진행한다.
• pull request의 경우에도 issue와 이름을 유사하게 설정하고 뒤에 이슈번호를 붙인다.
• (예: [feat] RabbitMQ 메시지큐 기능 구현 (#17))
• 코드리뷰를 적어도 2명이 마치고 Approve해야 Merge할 수 있다.