• 최근 3달의 기간 동안 총 3번의 팀프로젝트(2번은 각 일주일, 1번은 한 달)를 진행해왔다.
• 팀 프로젝트를 진행하면서 느낀 점은 모든 구성원이 인지하고 있는 정확한 규칙이 없어서 커뮤니케이션 코스트가 많이 증가한다고 느꼈다.
• 원할하게 협업하기 위해서는 통일된 기준이 반드시 필요하다고 생각했다.
• 그래서 다음 팀프로젝트를 하기 전에 그리고 개인 프로젝트를 진행할 때도 나만의 통일된 기준이 있다면 좀 더 효율적인 협업 및 코드 작성이 가능할 거라 기대하고 코드 컨벤션 뿐만 아니라 네이밍규칙, URL디자인, 코드 설계, 깃브랜치 전략 등 나만의 컨벤션 문서를 만들어 보려고 한다.

코드 컨벤션

Google Java Style Guide의 자동서식을 따르고 추가적인 컨벤션은 아래에 따른다.

코드 컨벤션의 목표

• 누구나 쉽게 코드를 이해하고 사용할 수 있게하기 위함

Naming

• 변수는 Camel Case 를 기본으로 한다.
• 기본적으로 이름은 길이를 고려하지 않고 최대한 의도를 밝혀 명확하게 작성한다. 다만 명확성의 차이가 없을 때는 길이가 짧은 네이밍을 선택한다.
• 변수명은 맥락을 고려해서 짓는다. 예를들어 클래스 이름이 user 라면 변수에 userName과 같이 user를 붙이지 않는다.
• 변수이름에 자료형을 쓰지 않는다. 예를들어 memberList 보다는 mebers 처럼 복수형으로 표현한다.
• 패키지명은 대문자를 사용하지 않고 소문자로만 구성한다.
• Enum 이나 상수는 대문자로 구성하고 밑줄(_)로 각 단어를 분리한다.
• 메서드명은 동사로 작성한다.
• 값을 반환하는 메서드의 경우 뭘 반환하는지 알 수 있게 메서드명을 짓는다.
• 클래스명과 인터페이스명은 명사로 작성하고, Upper Camel Case 를 사용한다.
• 엔티티 이름은 단수로 작성한다.
• boolean 메서드의 경우에 문법적으로 맞지 않은데 많이 사용하는 is+동사원형의 형태는 쓰지 않는다

Structure

디렉토리 구조는 도메인을 기준으로 작성한다.

• domain: 도메인 담당
  - api
  - domain
  - dto
  - exception
• global: 프로젝트 전체 담당
  - common
  - config
  - error
  - util
• infra: 외부 인프라스트럭처 담당
  - common
  - config
  - error
  - util
• 하나의 메서드는 한 가지 일만 해야한다.
• 하나의 클래스는 같은 목적을 둔 코드들의 집합이어야 한다.
• 메서드와 클래스는 가능한 한 작게 만든다.

Programming

• 반복되는 코드는 작성하지 않는다.
• 변수는 사용하는 위치에 가깝게 둔다.
• import를 할 때는 전체 이름을 다 적는다. * 를 사용하지 않는다.

롬복 설정

• 롬복은 가능한 한 사용하지 않는다.
• @Data 롬복 어노테이션은 쓰지 않는다.
  - @ToString, @EqualsAndHashCode, @Getter, @Setter, @RequiredArgsConstructor 를 한 방에 해주는데 개발자가 예기치 못한 에러가 발생할 위험성이 매우 크다.
• @AllArgsConstructor 롬복 어노테이션은 쓰지 않는다.
  - 모든 인자를 가진 생성자를 생성한다.
  - 해당 어노테이션 사용보다 builder 패턴 혹은 정적팩토리 메서드 패턴과 같이 가독성이 더 좋은 방법이 있다. 따라서 사용하지 않는다.
• @Settr 롬복 어노테이션은 사용하지 않는다.
  - 의도도 불분명하고 객체를 언제든지 변경할 수 있는 상태가 되어 객체의 안전성이 보장받기 어렵다.
• @AllArgsConstructor 롬복 어노테이션은 사용하지 않는다.
• 기본 생성자의 접근 권한을 최소화할 목적으로 접근 권한을 protected 설정한다.
  - 굳이 외부에서 생성을 할 수 있또록 열어둘 필요가 없으며, 객체 생성에 대한 안전성을 보장할 수 있다.
  - 롬복 어노테이션으로 작성하기보다는 코드로 직접 작성한다.
• @Builder는 클래스 상단에는 사용하지 않고 사용 시 매개변수는 최소화한다.
  - @Builder 를 사용하면 해당 객체에서 AllArgsConstructor 어노테이션을 붙인 효과를 발생시킨다. 따라서 객체 생성 시 모든 필드에 대한 매개변수 활용은 방지해야하고 필요한 데이터만 매개변수로 넣어 만들 수 있도록 한다.
  - 비지니스 로직에 맞게 필수값에 대해서만 열어둔다.

---

커밋 컨벤션

커밋 메시지 구조

[commit type]: [commit message] ([issue nubmer])  // 제목 

body // 본문

제목

[commit type]: [commit message] ([issue nubmer])

• commit type

구분자	작업 유형
feat	기능 구현
fix	버그 수정
docs	문서, 주석 관련 작업
refactor	리팩토링
test	테스트 관련 작업
chore	기타 작업

• commit message
  - 이번 커밋에서 작업한 내용을 간단하게 설명함
• issue number
  - 깃허브 이슈 넘버 혹은 지라 티켓 넘버를 작성함

본문

• 제목과 본문 사이 한 줄을 개행하여 분리한다.
• 본문은 필요한 경우에 작성하고, 무엇을 왜 했는지(what과 why)를 중점으로 작성한다.

---

깃 브랜치 전략

깃 브랜치 전략은 git flow 전략을 참고해서 지금 시점에 필요하지 않은 부분은 축소시키고 만들었다.

• main
  - 언제든지 배포가 가능한 상태를 유지해야 한다.
• develop
  - 다음 버전 개발을 위한 코드를 모아두는 브랜치
  - 개발이 완료되면 main 브랜치로 머지된다.
• featrue branch
  - 기능 단위 개발 브랜치
  - 이슈 리스트로 브랜치 생성 및 관리
  - 네이밍은 feature/#이슈번호-브랜치명 의 형태로 생성한다.
  - 브랜치명은 소문자로 작성한다. 단어의 구분은 밑줄(_)로 한다.
  - featrue 브랜치에서 개발 완료 후 devleop 브랜치로 PR 요청한다.
  - merge 이후 요청한 브랜치는 삭제한다.

---

템플릿 정리

템플릿의 목적은 자주 작성하는 이슈와 PR 요청의 틀을 정형화함으로써 작성 시간을 줄이기 위함

issue

Description

설명

Progress

• todo1
• todo2

---

pull request

• 작업 목적
• 주요 변경점
• 참고
• 리뷰 포인트