" 더 큰 세상에서 걸음마를 뗄 후배들이 선배의 손을 잡고 뛸 수 있도록 "
같은 계열 '선'배와의 진로 상담 '약'속, 선약
ㄴ 같은 경험을 가진 선배와의 진로 상담을 통해 더 맞춤화된 조언을 받을 수 있도록
ㄴ 같은 계열/원하는 직무의 선배를 터치 한번으로 더 쉽게 찾을 수 있도록
 |
 |
김창균  |
홍석범 |
김창균 - EC2, RDS 세팅 / 컨벤션들 작성 / 구글 소셜 로그인 연동 / API 개발
홍석범 - 응답, 에러 처리를 포함한 프로젝트 초기 세팅 / DOCKER CI, CD 세팅 / 네이버 OCR, 구글 미트 회의실 개설 등 외부 API 연동 / API 개발
Git Flow
main운영서버 브랜치hotfix핫픽스용 브랜치develop개발서버 브랜치prefix/#이슈번호작업을 진행 중인 브랜치
Branch Naming Rule
- 이슈를 먼저 생성하고 부여받은 이슈 번호를 바탕으로 브랜치를 생성합니다.
- 여기서의
prefix는 전부 소문자를 사용합니다.
prefix/#이슈번호
ex) feat/#8
ex) fix/#17
Commit Convention
- 여기서의
Prefix는 전부 대문자를 사용합니다.
[PREFIX/#이슈번호] 작업내용
ex) [FEAT/#8] 단어 리스트 조회 API 구현
ex) [FIX/#17] 검색 결과 필터링 기능 오류 수정
Prefix Convention
branch에서의prefix는 전부 소문자를 사용합니다.label은 전부 대문자를 사용합니다.- 한 commit에서는 해당 prefix type에 해당하는 내용만 갖도록 commit을 최대한 분리합니다.
| prefix types | 의미 |
|---|---|
| ✨ FEAT | 새로운 기능 추가 |
| 🛠️ FIX | 버그, 오류 등을 수정 |
| 🔀 MERGE | 다른 branch와 병합 |
| ⚙️ SETTING | 프로젝트 초기 세팅 |
| 🧩 CHORE | 기능, 성능과 직접적으로 관련이 없는 작업(초기 세팅 이후) ex) .gitignore, 의존성 추가 등 |
| 📝 DOCS | README나 WIKI 등의 문서 수정 |
| ✏️ CORRECT | 문법 상 오류나 타입, 변수명 등을 변경 |
| 📂 FILE | 폴더링 변경 |
| 🔁 RENAME | 파일 이름 변경 |
| ♻️ REFACTOR | 코드 리팩토링 |
| ⚰️ DEL | 쓸모없는 코드 삭제 |
| 💡 TEST | 테스트 코드, 리팩토링 테스트 코드 작성 |
| 🔥 !HOTFIX | 치명적인 버그가 발생하여 급하게 수정 |
Issue Template
- [PREFIX] 이슈내용
- 여기서의
PREFIX는 전부 대문자를 사용합니다.
## 💡 Issue
<!-- 이슈에 대해 간략하게 설명해 주세요 -->
-
## 📝 To-do
<!-- 진행할 작업에 대해 적어주세요 -->
<!--
- [ ] 도메인 모델(Entity) 정의
- [ ] DTO(Record) 정의
- [ ] Repository 인터페이스 생성
- [ ] Service 클래스 작성
- [ ] Controller 클래스 작성
- [ ] 공통 응답 처리 및 예외 처리
- [ ] Swagger 테스트
-->
- [ ]
Pull Request Template
- [PREFIX] #이슈번호 - PR내용
- 여기서의
PREFIX는 전부 대문자를 사용합니다.
# 💡 Issue
- resolved: #이슈번호
# 📸 Screenshot
<!-- 필요 시 사진, 동영상 등을 첨부해 주세요
ex) 포스트맨, 스웨거, 로그 등 -->
# 📄 Description
<!-- 작업한 내용에 대해 상세하게 설명해 주세요,
코드를 첨부할 경우 permalink를 사용해 주세요 -->
-
# 💬 To Reviewers
<!-- 리뷰어들에게 남기고 싶은 말을 적어주세요
ex) 코드 리뷰 간 참고사항, 질문 등 -->
-
# 🔗 Reference
<!-- 이슈를 해결하며 도움이 되었거나, 참고했던 아티클들의 링크를 첨부해 주세요 -->
-
Package Structure
계층형 구조 vs 도메인형 구조
- 계층형 구조
- 규모가 작고, 도메인이 적은 경우
- 계층형 패키지 안에 클래스들이 구분이 안 될 만큼 많아질 경우가 적다.
- 애플리케이션 흐름 및 가독성이 도메인형보다 좋다.
- 유스케이스별로 클래스를 분리하는 경우가 적다.
- 도메인의 변경이 일어나도, 규모가 작고 도메인이 적은 만큼 변경 범위가 그렇게 넓지 않을 것이다.
- 도메인형 구조
- 규모가 크고, 도메인이 많은 경우
- 규모가 크고 도메인이 많은 만큼 도메인별 응집도가 높은 것이 중요할 것이다.
- 규모가 큰 만큼 유스케이스별로 클래스를 분리하는 경우가 있을 수 있다.
- 도메인형 구조를 사용합니다.
Enum클래스는model패키지 안에 포함합니다.
├── build.gradle
├── 📂 src/main/java/org/sopt/seonyakServer
│ ├── 📂 domain
│ │ ├── 📂 entity1
│ │ │ ├── 📂 controller
│ │ │ ├── 📂 dto
│ │ │ │ ├── 📂 request
│ │ │ │ └── 📂 response
│ │ │ │
│ │ │ ├── 📂 model
│ │ │ ├── 📂 repository
│ │ │ └── 📂 service
│ │ │
│ │ └── 📂 entity2
│ │ │ ├── 📂 controller
│ │ │ ├── 📂 dto
│ │ │ │ ├── 📂 request
│ │ │ │ └── 📂 response
│ │ │ │
│ │ │ ├── 📂 model
│ │ │ ├── 📂 repository
│ │ │ └── 📂 service
│ │ │
│ │ └── 📂 utils
│ │
│ └── 📂 global
│ ├── 📂 auth
│ │ ├── 📂 filter
│ │ ├── 📂 jwt
│ │ ├── 📂 redis
│ │ └── 📂 security
│ │
│ ├── 📂 common
│ │ ├── 📂 dto
│ │ ├── 📂 external
│ │ └── 📂 model
│ │
│ ├── 📂 config
│ └── 📂 exception
│ ├── 📂 enums
│ ├── 📂 model(CustomException)
│ └── GlobalExceptionHandler.java
│
└── SeonyakServerApplication.java
