📂 BE 개발 컨벤션 v1.4

0️⃣ . Issue

Projects 에서 이슈를 생성한다.

1. BE-Feat-Issue-Template

---
name: 새로운 기능
about: feat
title: "[BE-FEAT]"
labels: BE_FEAT
assignees: ''

---

✨ Description
---
- 기능에 대한 한 줄 설명을 작성 해주세요.

✨ Task
---
- [ ] 기능 세부 요구 사항에 대해 작성 해주세요.

✨ Time
---
- 예상 소요 시간을 작성 해주세요.

2. BE-Bug-Issue-Template

---
name: "버그 수정  \\U0001F41C "
about: fix
title: "[BE-FIX]"
labels: BE_FIX
assignees: ''

---

🐛  description
---
- 해당 버그에 대한 설명을 한 줄로 작성해주세요.

🐛  file
---
- 버그와 관련된 캡쳐 및 세부 설명을 추가적으로 필요하다면 작성해주세요.

🐛  time
---
- 고치기까지 예상 소요 시간

1️⃣ . PR

1. PR 템플릿

## 🍄 PR 확인 사항
PR이 다음 요구 사항을 충족하는지 확인하세요. :

- [ ] API 명세서가 업데이트 혹은 작성이 되어 있나요?

## 현재 작업은 어떤 이슈를 해결한 것인지 설명해주세요.
> Issue Number: {번호}

- 이슈에 있는 태스크 들을 붙여넣어주세요.

## 기존 코드와 달라진 점이 있다면 설명해주세요.

- [ ] 있음
- [ ] 없음

2. PR 작성 방식

🔥 팀원에게 PR을 작성했음을 알려주세요!

반드시 PR을 작성 후에 깃허브에서 리뷰 요청을 날린 후, PR 알림 템플릿 에 맞춰서 backend-hook 의 모두에게 알려주세요!

Assignees : 기능을 구현한 본인을 태그한다.

Label : 기능 타입 (BE-Feat, BE-fix … 필요하다면 BE-{태그} 이름으로 추가)

2-1. PR 알림 템플릿

🍀 PR이 도착했어요!
기능 내용 :
(PR 링크)[]

2️⃣ . Commit

• 커밋은 기능 단위로 진행한다.
  • 기능을 최대한 작게 한다.
  • 커밋에 해당 기능에 대한 테스트를 포함한다.
• 커밋 메시지는 아래의 형식을 따른다.

feat: {구현한 기능에 대한 설명} 기능

docs: {작성한 파일에 대한 설명} 작성/수정

• 태그는 아래를 참고한다.

Tag Name	Description
feat	새로운 기능을 추가
fix	버그 수정
hotfix	급하게 치명적인 버그를 고쳐야하는 경우
style	코드 포맷 변경, 세미 콜론 누락
refactor	프로덕션 코드 리팩토링
docs	문서 수정 (리드미 등)
test	테스트 코드, 리펙토링 테스트 코드 추가, Production Code(실제로 사용하는 코드) 변경 없음
rename	파일 혹은 폴더명을 수정
remove	파일을 삭제하는 작업만 수행한 경우
build	yml, gradle과 같은
빌드 관련 파일 수정
chore	어디에 넣기도 애매한 잡일 (파일 이동)

3️⃣ . Projects

1. Projects 활용 방식

• 이미 만들어진 BE-Work-Board 를 활용한다.
• Issue 를 생성 후, 해당 기능을 개발하고 있을 경우 InProgress 로 옮긴다.

4️⃣ . Branch

1. 작업 브랜치 네이밍 컨벤션

반드시 be/** 방식으로 사용한다.

be/{태그}/#{이슈번호}-{CRUD}-{도메인이름}-api

ex) be/feat/#123-post-pokemon-api , be/fix/#124-post-pokemon-api

2. 깃허브 브랜치 전략

🔥 main , be-develop, be-feat/ 이 존재한다.

be-develop 에서 작업 브랜치를 생성한다.

3. 브랜치 작업 방식

branch 를 생성하여 작업하는 경우 이와 같은 과정을 따른다.

1. branch 를 생성하기 전 git pull 을 통해 develop을 업데이트 한다.
2. 브랜치를 네이밍에 맞게 생성한다.
3. git fetch 를 통하여 발생하는 conflict 를 확인한다.
4. git pull --rebase [원격 저장소] [브랜치] 명령어를 통해 리베이스 하여 해결한다.
5. 변경사항들을 commit 후에 push 한다.
6. merge 후 머지된 브랜치를 delete 한다.

5️⃣ . Review

1. 리뷰 작성 방식

• 빠른 리뷰를 위해 직설적으로 작성한다.
• 여러개를 다는 경우 pending 후 한번에 보낸다.
• 리뷰는 최대 24 시간, 주말이 끼어있는 경우 36 시간 안에 진행한다.
• 리뷰는 팀원 모두에게 받는다. 코드에 문제가 생길 경우 모두의 책임으로 함께 해결한다.

단, 문제 지적 시 반드시 문제 원인과 그 대안을 같이 작성한다.

또한 이모지를 하나 이상 포함하도록 한다.

🔥 단 밑과 같은 예시는 이모지로 취급하지 않는다.

ex) 🌴🍀⭐️💥🍒 당신 코드 구려요 🍊🌸💫💞💛 👎 구려요

6️⃣ . Code

1. 폴더링

• 큰 도메인을 중심으로 폴더를 구분한다. (pokemon, ability, type ....)

2. 작성 방식 (컨벤션)

• 처음에는 생성자만 사용한다

  • 이후 Builder가 필요하다면**, 팀원과 전부 합의 후** 리팩토링한다.

• 정적 팩토리 메서드는 쓸 수 있지만, Dto 에만 사용하는 것을 권장한다.

   만약 엔티티에 쓰기 시작한다면 이도 **팀원과 전부 합의**한다.
  

• Record 는 Dto 에서만 사용한다.

• 어노테이션은 긴 것이 가장 밑에 가도록 정렬한다.
• 다만 `@Override` 같은 어노테이션들은 가장 위에 가도록 정렬한다.
• 매개변수의 길이가 | 회색 선을 넘어가는 경우 매개변수 사이에 한칸씩 띈다.
  • private 메서드는 사용하는 곳 바로 아래에 둔다.
    • 단, 해당 메서드가 여러 곳에서 공통으로 사용되는 경우 클래스 제일 하단부에 둔다.

2-1. 메서드 개행

• 개행은 return 문 전에 반드시 한칸 띄운다.
  • 그러나 메서드 내부가 return 문 하나 뿐이라면 한칸을 띄우지 않는다.
• 처음 메서드를 시작할때는 개행을 사용하지 않는다.

2-2. 클래스 개행

• 첫 라인은 개행을 한다.
• 마지막 라인은 개행을 하지 않는다.
• 어노테이션이 붙은 필드 사이에서는 개행을 한다.
• 어노테이션이 안붙은 필드 사이에서는 개행을 한다.
• 메서드 사이에 개행을 한다.

2-3. ENUM 에러 메시지 필드 개행

• 상태 코드 별로 개행을 한다.

3. yml

3-1. ddl-auto

• Dev

  • None 을 Default 로 해놓는다.
  • 데이터베이스에 변경사항이 있는 경우, 쿼리로 직접 작성하여 반영한 후 코드에도 반영한다.
    • 이후 Validation 으로 변경 후 코드와의 차이가 없는 것을 확인 후 None 으로 변경한다.
    • 반드시 해당 작업을 진행한 후 팀원에게 알린다.

• Test

  • 원하는 설정값을 사용한다.
  • 데이터베이스는 로컬에서 각자의 MySQL을 사용한다.

3-2. 비밀키 관리

🔥 깃허브 서브 모듈을 사용한다.

미아의 설명을 듣고 4인 페어에서 실습 후 최종 결정한다.

4. 테스트 코드

• DisplayName 한글, 메서드 이름 영어

  • 기능이 하는 일을 상세하게 설명한다.
  • ~한다. 라는 이름으로 끝낸다.
    • 이름 : 테스트하려는 메서드 이름을 쓰고 조건이 있다면 그 뒤에 When 을 붙인다.

• TDD 는 하지 않는다

  • 도메인은 반드시 테스트 한다.
  • 검증 로직 및 예외 처리는 테스트를 한다.
  • Service 로직은 테스트 한다.
    • 검증 로직이 있을 경우 == 개발자의 개입이 있을 경우 작성한다.
    • 위와 같은 케이스가 아니더라도 원하는 경우 작성해도 좋다ㅣ.
  • Controller는 @Valid 만 (의존성은 Mockito, @WebMvcTest)
  • 인수 + 통합 테스트 (알아서 판단하십시오.)
  • Repository는 테스트를 본인이 직접 쿼리를 쓰는 경우 테스트 (@DataJpaTest)
    • 함께 테스트 할 수 있다면 한 메서드에서 테스를 진행한다. (휴먼 에러, 쿼리 정상 작동, 데이터 있음 )
    • 데이터에 따라 나뉠 수 있는 엣지 케이스는 따로 작성한다.