ShowEat

📖목차

• README
  • 🗓프로젝트 진행 기간
  • 📑주제
  • 🎉프로젝트 기획
  • 🔑 핵심 기능
  • 🔑 주요 기능
  • 🖥 서비스 화면
  • 🏗️ 아키텍쳐
  • 🛠 기술 스택
  • 📂 파일 구조
  • 📝 설계 문서
    • ERD
    • API
    • FIGMA
  • 📚 컨벤션
    • Ground Rule
    • Git Branch
    • Git Commit
    • Codding
    • Jira
  • 📄 문서 정리
    • 회의록
    • 지식 공유
  • 💾 결과물
    • UCC
    • 데모
    • PPT
    • 포팅매뉴얼
  • ❤ 팀 소개
    • 팀명
    • 팀명의 의미
    • 프론트
    • 백

---

🗓 프로젝트 진행 기간

2023.10.09 ~ 2023.11.17 (약 6주)

---

📑 주제

확정 매출 보장형 소상공인 펀딩 플랫폼

---

🎉 프로젝트 기획

---

🔑 핵심 기능

🔑 주요 기능

---

🖥 서비스 화면

메인 페이지

로그인

펀딩 검색/필터링/정렬

펀딩/리뷰 조회

내 정보 및 캐시카우 충전

셀러 신청 및 조회

펀딩 생성

쿠폰 사용

---

🏗️ 아키텍쳐

---

🛠 기술 스택

기술 스택

상세 기술 스택

더보기

 

---

📂 파일 구조

프론트 프로젝트 구조

📦src
 ┣ 📂apis
 ┣ 📂components
 ┃ ┣ 📂common
 ┃ ┃ ┣ 📂button
 ┃ ┃ ┣ 📂dropdown
 ┃ ┃ ┣ 📂input
 ┃ ┃ ┣ 📂overlay
 ┃ ┃ ┣ 📂table
 ┃ ┃ ┗ 📂textBox
 ┃ ┣ 📂composite
 ┃ ┃ ┣ 📂card
 ┃ ┃ ┣ 📂carousel
 ┃ ┃ ┣ 📂coupon
 ┃ ┃ ┣ 📂footer
 ┃ ┃ ┣ 📂header
 ┃ ┃ ┣ 📂imageGallery
 ┃ ┃ ┣ 📂loadingSpinner
 ┃ ┃ ┣ 📂modal
 ┃ ┃ ┣ 📂multiSlider
 ┃ ┃ ┣ 📂navigationBar
 ┃ ┃ ┣ 📂paginationBar
 ┃ ┃ ┣ 📂profileBox
 ┃ ┃ ┣ 📂searchBar
 ┃ ┃ ┗ 📂tabBar
 ┃ ┗ 📂custom
 ┃ ┃ ┗ 📂modal
 ┣ 📂configs
 ┣ 📂customTypes
 ┣ 📂hooks
 ┣ 📂layouts
 ┣ 📂libs
 ┣ 📂pages
 ┃ ┣ 📂application
 ┃ ┣ 📂buyers
 ┃ ┃ ┣ 📂coupons
 ┃ ┣ 📂error
 ┃ ┣ 📂fundings
 ┃ ┃ ┗ 📂[fundingId]
 ┃ ┣ 📂search
 ┃ ┣ 📂sellers
 ┃ ┃ ┣ 📂profile
 ┃ ┃ ┣ 📂redeem
 ┃ ┃ ┃ ┣ 📂result
 ┃ ┃ ┃ ┃ ┗ 📂[couponId]
 ┃ ┃ ┣ 📂statistics
 ┃ ┣ 📂service
 ┃ ┣ 📂sign-in
 ┃ ┣ 📂sign-up
 ┣ 📂stores
 ┃ ┣ 📂sellers
 ┃ ┗ 📂users
 ┣ 📂styles
 ┗ 📂utils

백엔드 프로젝트 구조

📦showeat
 ┣ 📂domain
 ┃ ┣ 📂auth
 ┃ ┃ ┣ 📂config
 ┃ ┃ ┣ 📂controller
 ┃ ┃ ┣ 📂dto
 ┃ ┃ ┃ ┣ 📂kakao
 ┃ ┃ ┃ ┣ 📂request
 ┃ ┃ ┃ ┣ 📂response
 ┃ ┃ ┣ 📂filter
 ┃ ┃ ┣ 📂handler
 ┃ ┃ ┣ 📂service
 ┃ ┃ ┗ 📂util
 ┃ ┣ 📂bookmark
 ┃ ┃ ┣ 📂controller
 ┃ ┃ ┣ 📂dto
 ┃ ┃ ┃ ┣ 📂request
 ┃ ┃ ┃ ┗ 📂response
 ┃ ┃ ┣ 📂entity
 ┃ ┃ ┣ 📂repository
 ┃ ┃ ┗ 📂service
 ┃ ┣ 📂business
 ┃ ┃ ┣ 📂controller
 ┃ ┃ ┣ 📂dto
 ┃ ┃ ┃ ┣ 📂request
 ┃ ┃ ┃ ┗ 📂response
 ┃ ┃ ┣ 📂entity
 ┃ ┃ ┣ 📂repository
 ┃ ┃ ┗ 📂service
 ┃ ┣ 📂coupon
 ┃ ┃ ┣ 📂controller
 ┃ ┃ ┣ 📂dto
 ┃ ┃ ┃ ┣ 📂request
 ┃ ┃ ┃ ┗ 📂response
 ┃ ┃ ┣ 📂entity
 ┃ ┃ ┣ 📂repository
 ┃ ┃ ┗ 📂service
 ┃ ┣ 📂funding
 ┃ ┃ ┣ 📂controller
 ┃ ┃ ┣ 📂dto
 ┃ ┃ ┃ ┣ 📂request
 ┃ ┃ ┃ ┗ 📂response
 ┃ ┃ ┣ 📂entity
 ┃ ┃ ┣ 📂facade
 ┃ ┃ ┣ 📂repository
 ┃ ┃ ┗ 📂service
 ┃ ┣ 📂history
 ┃ ┃ ┣ 📂controller
 ┃ ┃ ┣ 📂dto
 ┃ ┃ ┃ ┣ 📂request
 ┃ ┃ ┃ ┗ 📂response
 ┃ ┃ ┣ 📂entity
 ┃ ┃ ┣ 📂repository
 ┃ ┃ ┗ 📂service
 ┃ ┣ 📂notification
 ┃ ┃ ┣ 📂controller
 ┃ ┃ ┣ 📂dto
 ┃ ┃ ┃ ┣ 📂request
 ┃ ┃ ┃ ┗ 📂response
 ┃ ┃ ┣ 📂entity
 ┃ ┃ ┣ 📂repository
 ┃ ┃ ┗ 📂service
 ┃ ┣ 📂payment
 ┃ ┃ ┣ 📂controller
 ┃ ┃ ┣ 📂dto
 ┃ ┃ ┃ ┣ 📂request
 ┃ ┃ ┃ ┗ 📂response
 ┃ ┃ ┣ 📂entity
 ┃ ┃ ┣ 📂repository
 ┃ ┃ ┗ 📂service
 ┃ ┣ 📂qr
 ┃ ┃ ┣ 📂controller
 ┃ ┃ ┗ 📂service
 ┃ ┣ 📂review
 ┃ ┃ ┣ 📂controller
 ┃ ┃ ┣ 📂dto
 ┃ ┃ ┃ ┣ 📂request
 ┃ ┃ ┃ ┗ 📂response
 ┃ ┃ ┣ 📂entity
 ┃ ┃ ┣ 📂repository
 ┃ ┃ ┗ 📂service
 ┃ ┗ 📂user
 ┃ ┃ ┣ 📂controller
 ┃ ┃ ┣ 📂dto
 ┃ ┃ ┃ ┣ 📂request
 ┃ ┃ ┃ ┗ 📂response
 ┃ ┃ ┣ 📂entity
 ┃ ┃ ┣ 📂repository
 ┃ ┃ ┗ 📂service
 ┃ ┃ ┃ ┣ 📂implement
 ┣ 📂global
 ┃ ┣ 📂config
 ┃ ┣ 📂entity
 ┃ ┣ 📂exception
 ┃ ┣ 📂kafka
 ┃ ┣ 📂response
 ┃ ┃ ┣ 📂ocr
 ┃ ┣ 📂s3
 ┃ ┃ ┣ 📂config
 ┃ ┃ ┣ 📂dto
 ┃ ┗ 📂util

---

📝 설계 문서

ERD

ERD

API

전체 문서

Request

Response

FIGMA

FIGMA

---

📚 컨벤션

Ground Rule

클릭하여 내용 표시/숨기기

GROUND RULE

🥇 프로젝트 수칙

💻 회의 진행

1. 매일 오전 9시, 오후 5시 2회에 걸쳐 **데일리 스크럼(Daily Scrum)**을 진행해, 개인별 당일 목표를 설정하고 진행 상황을 공유합니다.
2. 매주 금요일 오후 5시에 **스프린트 세션(Sprint Session)**을 진행해 일주일간 프로젝트의 진행 상황 및 추후 진행 목표를 설정합니다.
3. 데일리 스크럼과 스프린트 세션은 팀장이 회의를 주재하고, 다른 팀원들이 돌아가며 회의록을 작성합니다.
4. 회의에 적극적으로 참여하고, 팀장의 지목에 따라 본인의 의견을 반드시 제시합니다.

💻 코드 리뷰

1. **코드 리뷰(Code Review)**는 점심시간을 활용해 필요한 부분만 간단히 30분 동안 진행합니다.
2. 서로 다른 코드 스타일을 합의한 **코딩 컨벤션(Coding Convention)**에 따라 일원화합니다.
3. 코드 리뷰는 우선순위에 따라 빠르게 진행하며, 사소한 의견을 반영할 지에 대한 부분은 코드 작성자가 선택할 수 있도록 합니다.

💻 코드 작성

1. 에러(Error)가 발생 시 1시간 정도는 혼자서 고민해보고, 해결이 되지 않을 경우 팀원들과 바로 공유합니다.
2. 에러를 해결하기 위해 고민한 내용 및 해결 과정은 노션에 정리하여 공유합니다.
3. 코드에 주석(Comment)을 작성하는 습관을 생활화하여, 다른 팀원들이 내가 작성한 코드를 이해하기 쉽도록 합니다.
4. 기능의 구현 원리를 공부하고 파악하기 위해서 오픈 소스(Open Source) 라이브러리 사용을 최소화하는 것을 원칙으로 합니다.

💻 깃 관리

1. 풀리퀘스트(Pull Request)가 있을 경우, 이를 확인했다는 의미에서 최소한 1개 이상의 의견을 남겨야 합니다.
2. 풀리퀘스트 시 의견 갈등이 생겼다면, 충분한 토론과 의견 수렴 과정을 거쳐 다수의 의견을 따라야 합니다.
3. 커밋(Commit)하기 전에 고칠 부분을 한 번 더 점검합니다.
4. 1가지 기능 또는 1가지 함수를 새로 만들 때마다 커밋하는 습관을 생활화합니다.
5. **커밋 메시지(Commit Message)**는 합의한 **커밋 컨벤션(Commit Convention)**에 따라 최대한 상세하게 작성합니다.
6. 깃 브랜치(Branch) 규칙에 따라 브랜치를 관리하고, 모든 작업은 올바른 브랜치에서 작업해야 합니다.

🥈 생활 수칙

💻 개인 일정 관리 및 연락

1. 개인 일정이 생긴 경우 반드시 미리 다른 팀원들에게 공유합니다.
2. 프로젝트 중간에 취업 등으로 수료하게 된 경우, 도의적 차원에서 공통 프로젝트를 마무리하고 가야 합니다.
3. 카카오톡(KakaoTalk), 디스코드(Discord), 매터모스트(Mattermost) 등을 통한 연락을 확인했을 때는, 확인했다는 의미의 답변 또는 이모지(Emoji)로 표시합니다.
4. 매주 금요일 논의해, 주말 중 하루는 스트레스 관리 및 개인 공부를 위한 시간으로 활용할 수 있도록 합니다.

💻 개인 건강 및 위생 관리

1. 교육장에서 퇴실하기 전에 자기 자리를 깔끔하게 정리정돈합니다.
2. 몸이 아프면, 미안해하지 않고 빠르게 회복할 수 있도록 푹 쉬는 것을 권장합니다.
3. 밥을 든든히 먹고, 굶지 않습니다. “잘 먹고 죽은 개발자가 때깔도 곱습니다.”

🥉 마인드셋 수칙

💻 마인드셋

1. 적극성 : 회의나 코드 리뷰 때 의견이 있다면 망설이지 않고 의견을 이야기합니다. “말할까 말까 할 때는 말해야 합니다.”
2. 긍정적인 태도 : 프로젝트에 임할 때는 웃으면서 재미있게 합시다. “행복하기 때문에 웃는 것이 아니고 웃기 때문에 행복합니다.”
3. 소통 : 다른 팀원의 의견을 존중하고, 말을 끊지 않아야 합니다. 의견이 다르면, 대화를 통해 타협점을 찾아야 합니다.
4. 협력 : 팀원이 힘들어하는 부분이 있다면, 웃으면서 도와주어야 합니다. 도움을 줄수록 나의 실력도 함께 올라갑니다.
5. 신뢰 : 다른 팀원들의 책임감과 실력에 대해 믿음을 잃지 맙시다.

Git Branch

클릭하여 내용 표시/숨기기

브랜치 명명 컨벤션

BRANCH NAMING CONVENTION

Git flow

• ex) feat/{이슈 키}-{BE/FE}-{이슈 요약}

• master / main - 제품으로 출시 및 배포가 가능한 상태인 브랜치 → 최종 결과물 제출 용도

• develop - 다음 출시 버전을 개발하는 브랜치 → 기능 완성 후 중간에 취합하는 용도

• feature - 각종 기능을 개발하는 브랜치 → feat/login, feat/join 등으로 기능 분류 후 작업

• hotfix - 출시 버전에서 발생한 버그를 수정하는 브랜치

Git Commit

클릭하여 내용 표시/숨기기

## 📖 **커밋 메시지 규칙**

• [커밋 유형]: [커밋 내용]의 형식으로 작성합니다.
• 커밋 유형과 커밋 내용은 모두 영어로 작성해야 하며, 한글로는 작성할 수 없습니다.
• 커밋 유형에 이모지는 사용하지 않으며, 커밋 타입은 대문자로 시작합니다.
• 커밋 유형과 커밋 내용 사이는 콜론(:)으로 구분하며, 커밋 유형과는 붙이고, 커밋 내용과는 띄워서 작성합니다.
• 커밋 내용은 대문자로 시작해야 하며, 나머지는 소문자로 작성하는 것이 원칙입니다. AI, SSAFY 등 축약어, 고유명사 등은 대문자로 표기할 수 있습니다.
• 커밋 내용을 시작하는 첫 단어는 Create, Add, Modify, Delete, Merge 중 하나를 선택하여 작성합니다.

📖 커밋 유형의 종류

• Init
  • 새로 브랜치를 생성하여 처음으로 커밋을 하는 경우
  • (예) Init: Create feat/S09P11A203-52-document-scan branch
• Chore
  • 그래들(Gradle) 또는 package.json 파일에 의존성을 추가하거나 수정하는 경우
  • 도커(Docker) 파일을 추가하거나 수정하는 경우
  • 기타 설정 파일을 추가하거나 수정하는 경우
  • (예) Chore: Add env.yml file
• Feat
  • 새로운 기능을 추가한 경우
  • CSS 또는 스타일을 수정한 경우
  • (예) Feat: Add document scan feature
• Fix
  • 버그를 고친 경우
  • 급하게 치명적인 버그를 고쳐야 하는 경우
  • (예) Fix: Modify word addition bug
• Merge
  • 브랜치에서 기능 구현 완료 후 다른 브랜치와 통합하는 경우
  • (예) Merge: Merge feat/S09P11A203-52-document-scan branch to develop branch
• Refactor
  • 효율적인 코드를 위해 코드 수정 및 리팩토링을 진행한 경우
  • 파일을 삭제하는 작업만 수행하는 경우
  • 파일, 폴더명을 수정하거나 옮기는 작업만 진행한 경우
  • (예) Refactor: Modify folder structure
• Test
  • 기능에 대한 테스트 코드를 작성하는 경우
  • (예) Test: Add funding test code

Codding

클릭하여 내용 표시/숨기기

CODING CONVENTION

• 1문자의 이름은 사용하지 않는다.
• 네임스페이스, 오브젝트, 함수 그리고 인스턴스에는 camelCase를 사용한다 ex) camelCase
• 클래스나 constructor에는 PascalCase를 사용한다. ex) PascalCase
• 약어 및 이니셜은 항상 모두 대문자이거나 모두 소문자여야 한다. ex) NFT
• 클래스명과 변수명은 명사 사용
• 메서드명은 동사 사용
• 상수명은 대문자를 사용하고, 단어와 단어 사이는 _로 연결한다.
• component는 PascalCase를 사용한다.

Jira

클릭하여 내용 표시/숨기기

JIRA CONVENTION

1. 매주 월요일 오전 스크럼 회의 이후 각자의 이슈 티켓을 생성한다.
2. 이슈 생성 시 확인해야 할 부분
   • 담당자가 본인으로 설정되어 있는지
   • 컴포넌트가 지정되어 있는지 (FE, BE, 공통 중 택1)
   • Epic Link가 지정되어 있는지 (설계, FE개발, BE개발, 회의, 학습…)
   • 스프린트의 총 Story Points가 40 이상인지
3. 이슈 티켓 이름은 [말머리] 구체적인 기능 으로 적는다.
   • ****************************기능 관련 이슈일 경우 **************[말머리]**************는 기능 명세서의 대분류를 따른다.
4. 매일 오전 스크럼 회의 이후 그 날 처리할 이슈 티켓을 진행 중으로 이동시킨다.
   • 실시간으로 이슈를 처리할 때마다 완료 처리한다.

---

📄 문서 정리

회의록

페이지 전체 모습

스크럼 페이지 세부 모습

스프린트 페이지 세부 모습

지식 공유

페이지 전체 모습

---

💾 결과물

UCC

https://www.youtube.com/watch?v=4qqfbgUPDNE&t=6s

시연 영상

https://youtu.be/s2JSZ5LAmCs?si=W-nynO6U6YPOTYGU

포팅메뉴얼

포팅메뉴얼 참조

---

❤ 팀 소개

팀명

📢 안녕하세요! 삼성 청년 소프트웨어 아카데미(SSAFY) 서울 2반 교육생으로 조직된 프로젝트 팀 ‘스택플로(Stackflow)’입니다. 프로젝트 진행 과정에서 발생할 많은 문제를 팀원 간 공유하고 해결책을 모색하면서 극복해 나가겠습니다. 또한, 각자 공부하고 싶은 최신 기술 스택을 함께 공부하며 교학상장(敎學相長)하는 기회로 삼겠습니다. 감사합니다.

팀명의 의미

프로젝트 팀명은 유명한 개발 커뮤니티 사이트 ‘스택 오버플로(Stack Overflow)’에서 착안하였습니다. 스택(Stack)은 프로젝트를 통해 학습할 기술 스택과 쌓여갈 개발 능력을 의미하고, 플로(Flow)는 프로젝트를 통해 얻게 될 성과와 성취를 의미합니다. 즉, 프로젝트를 통해 성장하면서 각자 원하는 성과를 달성하고자 하는 바람을 담았습니다.

Frontend

고건	구본웅

Backend

김하림	문수정	박시균	오유정