Skip to content

Commit ad7223e

Browse files
authored
Merge pull request kookmin-sw#6 from capstone-maru/docs/kookmin-sw#3-README
Docs/kookmin-sw#3 백엔드 프로젝트 README 파일, 컨벤션 파일 작성
2 parents 79948fd + d2a6438 commit ad7223e

File tree

2 files changed

+217
-8
lines changed

2 files changed

+217
-8
lines changed

README.md

Lines changed: 163 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -1,10 +1,165 @@
1-
# back-end
1+
# 🏠 공간 공유 서비스앱 MARU
22

3-
## git convention
4-
- commit format `git commit -m "(feat) # (issue_number) - (title)"`
5-
- branch name ` (feat) / #(issue_number) `
3+
<br>
64

7-
## git workflow
8-
- main 에서 develop branch 생성
9-
- develop branch 에서 결함이 없음을 테스트 한 후 main 에 merge
10-
-
5+
## 프로젝트 소개
6+
7+
> 저희는 공간을 함께 공유하며 사용할 사람들을 찾아주는 플랫폼을 제공하고자 합니다.
8+
> 공급의 감소, 전셋값의 상승 등 도시에서 여러 이유로 주거비가 상승하고 있습니다.
9+
> 이는 특히 경제적으로 어려운 젊은 세대에게 부담으로 다가오고 있습니다.
10+
>
11+
> 저희의 목표는 젊은 세대의 이러한 경제적 어려움을 공유 경제를 통해 해결하는 것입니다.
12+
> 즉, 젊은 세대들이 함께 주거 비용을 나누고, 남는 공간을 효율적으로 활용하여 부담을 줄이는 것을 돕고자 합니다.
13+
> 각자의 생활 방식에 따라 함께 살 룸메이트 또는 하우스메이트를 찾을 수 있도록 도와주며, 남는 공간을 공유하고 싶어하는 사람들을 연결시켜주어 비용 부담의 문제를 해결하고자
14+
> 합니다.
15+
16+
<br>
17+
18+
## 팀원 구성
19+
20+
<div align="center">
21+
22+
| **최정민 (FE)** | **조희정 (FE)** | **이준호 (BE)** | **정연수 (BE)** |
23+
|:--------------------------------------------------------------------------------------------------------------------------------------:|:------------------------------------------------------------------------------------------------------------------------------:|:--------------------------------------------------------------------------------------------------------------------------------:|:------------------------------------------------------------------------------------------------------------------------------------------:|
24+
| [<img src="https://avatars.githubusercontent.com/u/55117867?v=4" height=150 width=150> <br/> @cjeongmin](https://github.com/cjeongmin) | [<img src="https://avatars.githubusercontent.com/u/66050038?v=4" height=150 width=150> <br/> @he2e2](https://github.com/he2e2) | [<img src="https://avatars.githubusercontent.com/u/39540595?v=4" height=150 width=150> <br/> @leejh7](https://github.com/leejh7) | [<img src="https://avatars.githubusercontent.com/u/52970725?v=4" height=150 width=150> <br/> @cheesecrust](https://github.com/cheesecrust) |
25+
26+
</div>
27+
28+
<br>
29+
30+
## 1. 개발 환경
31+
32+
- Intellij IDEA Ultimate 2023.3.3 ~
33+
- Java 17
34+
- Gradle 8.5
35+
- Spring Boot 3.2.2
36+
- H2 Database (Dev)
37+
- PostgreSQL
38+
- Github, Github Issues, Github Project, GitKraken
39+
Notion, Github Wiki, Slack
40+
- [Figma](https://www.figma.com/file/7kNRrVNUAK9KZdMAPVBPgU/wire-frame?type=design&node-id=0-1&mode=design&t=oZJiMTmm1bsBSgXw-0)
41+
- [컨벤션]()
42+
<br>
43+
44+
## 2. 채택한 프레임워크, 인프라, 브랜치 전략
45+
46+
### 🍃 Spring Boot
47+
48+
- 자동 구성 기능을 제공하여 복잡한 설정 없이도 빠르게 프로젝트를 시작하고 프로토타입을 만들 수 있어 사용했습니다.
49+
- Spring 프레임워크의 기능과 라이브러리 (Spring Security, Spring Data, Spring MVC 등) 를 활용할 수 있어 사용했습니다.
50+
- YAML 파일을 사용하여 애플리케이션의 환경을 쉽게 설정할 수 있어 사용했습니다.
51+
52+
### 🐘 PostgreSQL
53+
54+
- 오픈 소스이며 무료로 사용할 수 있어 사용했습니다.
55+
- Postgre DBMS의 구조를 공부하고 서비스에 최적화된 설정으로 커스터마이즈 하여 사용했습니다.
56+
57+
### 🖊️ SonarLint, GoogleStyle
58+
59+
- 정해진 규칙에 따라 자동적으로 코드 스타일을 정리해 코드의 일관성을 유지하고자 했습니다.
60+
- 코드 품질 관리는 SonarLint에, 코드 포맷팅은 GoogleStyle에 일임하였습니다.
61+
- Google의 코딩 컨벤션을 참고해 사용했고, 예외 규칙은 팀원들과 협의했습니다.
62+
- 협업 시 매번 컨벤션을 신경 쓸 필요 없이 빠르게 개발하는 데에 목적을 두었습니다.
63+
64+
### 🐳 Docker
65+
66+
-
67+
68+
### ☁️ AWS
69+
70+
-
71+
72+
### 🪵 브랜치 전략
73+
74+
- Git-flow 전략을 기반으로 main, dev 브랜치와 feature 보조 브랜치를 운용했습니다.
75+
- main, develop, feat 브랜치로 나누어 개발을 하였습니다.
76+
- **main** 브랜치는 배포 단계에서만 사용하는 브랜치입니다.
77+
- **dev** 브랜치는 개발 단계에서 git-flow의 master 역할을 하는 브랜치입니다.
78+
- **feat** 브랜치는 기능 단위로 독립적인 개발 환경을 위하여 사용하고 merge 후 각 브랜치를 삭제해주었습니다.
79+
<br>
80+
81+
## 3. 프로젝트 구조
82+
83+
```
84+
├── README.md
85+
├── build.gradle
86+
├── .gitignore
87+
├── gradlew
88+
├── gradlew.bat
89+
├── settings.gradle
90+
91+
└── src
92+
├── main
93+
| ├── java
94+
| | └── maru
95+
| | ├── config
96+
| | ├── controller
97+
| | ├── domain
98+
| | ├── dto
99+
| | ├── repository
100+
| | ├── service
101+
| | └── BackEndApplication.java
102+
| |
103+
| └── resources
104+
| └── application.yaml
105+
├── test
106+
| └── java
107+
| └── maru
108+
| ├── config
109+
| ├── controller
110+
| ├── domain
111+
| ├── dto
112+
| ├── repository
113+
| ├── service
114+
| └── BackEndApplicationTests.java
115+
```
116+
117+
<br>
118+
119+
## 4. 역할 분담
120+
121+
### 👻 이준호
122+
123+
<br>
124+
125+
### 🐬 정연수
126+
127+
<br>
128+
129+
## 5. 개발 기간 및 작업 관리
130+
131+
### 개발 기간
132+
133+
- 전체 개발 기간 : 2024-03-04 ~
134+
135+
<br>
136+
137+
### 작업 관리
138+
139+
- GitHub Projects와 Issues를 사용하여 진행 상황을 공유했습니다.
140+
- 주간 회의를 진행하며 작업 순서와 방향성에 대한 고민을 나누고 Notion에 회의 내용을 기록했습니다.
141+
142+
<br>
143+
144+
## 6. 신경 쓴 부분
145+
146+
<br>
147+
148+
## 7. 참고한 자료
149+
150+
### [🗄️ 백엔드 아카이브](https://www.notion.so/Archive-256df43d0e6d4b148bf366cc7312e20b?pvs=4)
151+
152+
프로젝트를 진행하면서 참고한 문서 및 블로그 등을 스크랩하여 스크럼 시간에 팀원과 자신이 알게된 지식들을 공유하며 리뷰하는 시간을 가졌습니다.
153+
<br>
154+
155+
## 8. 트러블 슈팅
156+
157+
### [⚠️ 이슈 트래커](https://www.notion.so/Issue-Tracker-bc6d59d8d90a40f0a03edac83b9d595b?pvs=4)
158+
159+
프로젝트를 진행하면서 직면한 버그와 이슈를 정리하고 관리하여 다른 팀원이 동일한 문제에 직면했을 때 빠르게 해결할 수 있도록 문제의 원인, 해결방법을 정리하였습니다.
160+
161+
### [📈 포퍼먼스](https://www.notion.so/Performance-09735be60ecb42899546424654390f93?pvs=4)
162+
163+
프로젝트를 진행하면서 서비스의 성능을 향상시킬 수 있는 부분에 대해서 고민하고 테스팅한 후 성능 향상 전/후의 측정값들을 기록하고 성능 향상 원인에 대해 공부한 것을
164+
정리하였습니다.
165+
<br>

document/CONVENTION.md

Lines changed: 54 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,54 @@
1+
# Convention
2+
3+
---
4+
5+
## Commit Convention
6+
7+
💡커밋은 코드 리뷰를 원활한 진행을 도우며 히스토리를 위해 일관성이 유지되는 단위로 최대한 작게 쪼개서 커밋하며 커밋 메시지 본문을 자세하게 작성합니다.
8+
9+
### Description Prefix
10+
11+
> - feat: 새로운 기능 추가
12+
> - fix: 버그 수정
13+
> - docs: 문서 수정
14+
> - style: 코드 포맷팅
15+
> - refactor: 코드 리팩토링
16+
> - test: 테스트 코드
17+
> - chore: 빌드 업무 수정, 패키지 매니저 수정
18+
> - comment: 주석 추가 및 수정
19+
20+
### Rule
21+
22+
> - 제목은 50글자 이내
23+
> - 제목 + 본문(선택)으로 구성 / 제목에서 설명하지 못하는 경우 본문에 자세히 작성
24+
> - 커밋메세지는 무엇을 했는지 파악할 수 있게 자세히 작성
25+
> - 어떻게 보다는 무엇과 왜를 설명하기.
26+
> - 제목은 명령문O, 과거형 X
27+
> - 제목의 끝에는 마침표를 넣지 않기
28+
> - 한 개의 커밋에는 한 개의 기능/변경사항만 작성하도록 노력. 1커밋 1기능
29+
30+
### 예시
31+
32+
```bash
33+
git commit -m "feat (#1) - add some function"
34+
35+
git commit -m "commit-type [issue number] - [message]"
36+
```
37+
38+
## Branch Naming Convention
39+
40+
특정 기능을 위한 브랜치를 새롭게 만들 때, 브랜치 이름은 항상 위 Commit Convention의 Header와 이슈 번호가 함께 작성되어야 합니다.
41+
42+
특정 기능을 위한 브랜치가 아닌 무언가를 하기 위한 브랜치라면, 의미를 잘 표현할 수 있는 이름으로 작성합니다.
43+
44+
### 예시
45+
46+
```plaintext
47+
feat/#1-...
48+
49+
refactor/#2-...
50+
```
51+
52+
## Coding Convention
53+
54+
[Java GoogleStyle](https://google.github.io/styleguide/javaguide.html)에 맞춰 코드를 작성합니다.

0 commit comments

Comments
 (0)