SkyScanner를 리디자인한 프로젝트
 |
 |
| 김수현 | 석미혜 |
명세서 보러가기 : API Docs
├── 📂.github
├── 📂 main
├── 🗂️ resources
├── 📕 application.yml
├── 📂 controller(컨트롤러 파일)
├── 🗂️ dto
├──🗂️ request
├──🗂️ response
├── 📂 domain(엔티티 파일)
├── 📂 infrastructure(레포지토리 폴더)
├── 📂 service(서비스 파일)
├── 📂 exception(Exception enum, Exception class 파일)
├── 🗂️ model
├── 📂 common(공용 클래스 관리)
├──🗂️ advice
├──🗂️ dto
- 파일 이름 및 클래스, 인터페이스 이름: 파스칼 케이스(Pascal Case)
- Entity에서 사용되는 속성값들은 ? 카멜 케이스(camel Case)
- 내부에서 사용되는 함수 및 기타 사용: 카멜 케이스(camelCase)
인터페이스(interface)의 이름은 명사/명사절로 혹은 형용사/형용사절로 짓는다.
클래스 이름은 명사나 명사절로 짓는다.
메서드명은 기본적으로 동사로 시작한다.
다른 타입으로 전환하는 메서드나 빌더 패턴을 구현한 클래스의 메서드에서는 전치사를 쓸 수 있다.
"static final"로 선언되어 있는 필드일 때 상수로 간주한다.
상수 이름은 대문자로 작성하며, 복합어는 언더스코어'_'를 사용하여 단어를 구분한다.
상수가 아닌 클래스의 멤버변수/지역변수/메서드 파라미터에는 소문자 카멜표기법(Lower camel case)을 사용한다.
메서드 블럭 범위 이상의 생명 주기를 가지는 변수에는 1글자로 된 이름을 쓰지 않는다.
반복문의 인덱스나 람다 표현식의 파라미터 등 짧은 범위의 임시 변수에는 관례적으로 1글자 변수명을 사용할 수 있다.
모든 작업의 단위는 github에 생성된 Issue를 기준으로 합니다.
Issue의 볼륨은 최소 하나의 기능으로 합니다.
하나의 이슈를 마무리하기 전에는 특별한 상황이 아닌 이상 다른 작업에 대한 이슈를 생성하지 않습니다.
Issue ≤ PR
하나의 이슈에 대해서 반드시 하나의 PR이 열려야하는 건 아닙니다.
원활한 코드리뷰와 리뷰에 대한 내용을 반영하기 위해서 PR은 3개의 commit을 넘어가지 않아야합니다.
하나의 PR에 3개 이상의 File Change는 지양합니다.
Branch 전략은 Git-flow를 준수합니다. 우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그
| 커밋 구분 | 설명 |
|---|---|
| FEAT | (Feature) 개선 또는 기능 추가 |
| BUG | (Bug Fix) 버그 수정 |
| DOC | (Documentation) 문서 작업 |
| TST | (Test) 테스트 추가/수정 |
| BLD | (Build) 빌드 프로세스 관련 수정(yml) |
| PERF | (Performance) 속도 개선 |
| CLN | (Cleanup) 코드 정리/리팩토링 |
- 이슈번호와 함께 커밋 내용을 적는다.
- 예시 : [#1] feat : ~