Convention

Jump to bottom

Cass edited this page Oct 22, 2024 · 4 revisions

Coding Convention

Naver Coding Convention 사용

Branch Strategy

Github flow
- main/feature 두 종류의 branch로 구분
- feature branch의 이름은 feature/[name]으로 명명
  - name은 개발 단위의 기능을 의미하는 단어로 명명
main branch : 실제 출시 버전으로 배포를 진행
feature branch : 개발 단위별 브랜치를 생성하여 main으로 merge
신규 기능 개발 시 feature/ branch 생성하여 작업 후, PR 생성하여 리뷰 후 main branch에 merge하는 방식으로 진행

Commit Message

[<Type>] <title>

<body>

<footer (optional)>

type : 커밋의 종류. 첫 글자는 대문자로 한다
- [Feature] : 새로운 기능 추가
- [Fix] : 버그 수정
- [Docs] : 문서 수정
- [Refactor] : 코드 리팩토링, 포맷 변경
- [Test] : 테스트용 코드 작성, 테스트 케이스 작성
- [Chore] : 프로젝트의 설정 변경 (빌드, 패키지 ...)
body : 커밋의 내용 본문
한 줄 이내로 작성이라면 평문으로 작성하고, 세부 내용 설명시에는 - 를 사용해서 항목을 추가한다

commit body
- commit detail 1
- commit detail 2

footer : 이슈 트래킹 정보
종류: #이슈 번호 형식으로 입력한다. 동일한 주제의 다른 이슈 번호는 나열하고, 다른 주제라면 줄을 바꿔서 쓴다
이슈 넘버는 오름차순으로 작성한다
종류
- Fixes : 수정중인 이슈
- Resolve : 수정 완료된 이슈
- Ref : 참고

Fixes: #1, #3
Resolve: #2
Ref: #5, #7, #11

객체지향 설계 원칙

Setter, Property 미사용
한 메소드에는 한 번의 들여쓰기만 사용한다. (= 한 메소드는 하나의 책임만을 가진다)
else 키워드는 최대한 지양한다
(DTO를 제외한) 클래스는 최대한 50줄을 넘지 않는다. (= 하나의 엔티티가 한 가지의 작업만 해야 한다)
method, variable의 작명은 의미가 명확하도록 줄여쓰지 않는다