Skip to content

kusitms-com/30th_Meetup_TeamF_Moping_Front

BranchesTags

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

127 Commits
.github
.github
 
 
fe
fe
 
 
README.md
README.md
 
 
build.sh
build.sh
 
 
dh.html
dh.html
 
 

Repository files navigation

📌 모일 때 맵핀, MOPING

Moping 서비스 배포 주소 : https://www.moping.co.kr/

모핑 메인


👨‍👧‍👦 팀 소개

팀명 : 핑핑이들

분야 이름 포지션 내용
기획 박가은 📈 PM, 서비스 기획 유저 리서치, 와이어프레임 작성, 서비스 정책 확립,
비즈니스 모델 구축
기획 김규리 📋 서비스 기획 유저 리서치, 와이어프레임 작성, 서비스 정책 확립,
비즈니스 모델 구축, 서비스 마케팅 리드
기획 안재형 📊 서비스 기획 유저 리서치, 와이어프레임 작성, 서비스 정책 확립,
비즈니스 모델 구축, 서비스 마케팅 리드
디자인 김윤서 🎨 디자인 리드 ux/ui디자인, gui 디자인
디자인 이어령 🎨 디자인 ux/ui디자인, gui 디자인
개발 최호 📱 프론트엔드 리드 화면 UI 구현, API 연동
개발 최서희 📱 프론트엔드 화면 UI 구현, API 연동
개발 문희상 💻 백엔드 리드 API 구현, ERD 설계, 서버 배포
개발 윤소민 💻 백엔드 API 구현, ERD 설계, 서버 배포

🤔 서비스 개요

모핑 서비스개요1 모핑 서비스개요2 모핑 서비스개요3

목표 사용자

  • 마음에 드는 공간을 네이버 지도에 북마크하는 20대 여성
  • SNS를 통해 트렌드를 빠르게 접함 자신의 확실한 추구미를 가짐 자신의 취향 공간을 공유 친구와 함께 그 공간을 방문하는 것을 즐김

Pain Point

  • 방문하고자 하는 공간을 결정할 때의 어려움
  • 함께 공간을 방문하는 사람에게 정보를 일일이 공유하는 과정의 수고로움
  • 함께 공간을 방문하는 사람 모두가 찬성하는 공간을 결정하는 과정에서의 번거로움

Needs

  • 신뢰성 있는 정보와 효율적인 커뮤니케이션을 통한 공간 선택
  • 자신이 신뢰하는 집단이 북마크한 공간을 살펴봄으로써 신뢰도 있는 정보를 얻고 싶음
  • 친구들과 약속 장소를 정할 때 간편하게 커뮤니케이션 하고 싶음

Solution 및 기대효과

(1) 양방향 공간 선택

  • MOPING은 N명의 공간을 지도상에 한번에 모음으로써, 탐색 과정을 조금 더 효율적으로 하고 합리적인 선택에 도움을 줌

(2) 모임 링크에 축적되는 공간 정보

  • MOPING은 모임별로 공간 정보가 축적됨. 매번 새롭게 탐색하고 선택하는 것이 아닌, 링크 별로 공간을 모아주어 모임의 공간 탐색 및 선택의 수고로움을 덜어줌

(3) 새로운 공간에 대한 탐색의 기회

  • MOPING을 통해 자신이 신뢰하는 사람이 등록한 공간 정보를 얻을 수 있음. 이는 기존에 알지 못했던 새로운 공간에 대한 탐색 기회를 얻을 수 있으며, 이는 MOPING을 계속 이용하게 하는 동기가 될 것임 |

서비스 차별성

모핑 차별성

선별된 공간 정보

  • 각자 탐색해온 공간을 모아줌으로써 최종 탐색을 도움

함께 공간을 방문하는 사람과 만들어가는 지도

  • 지도 뷰로 보는 공유된 공간/북마크 목록

📱 서비스 기능

모핑 기능1

모핑 기능2

모핑 기능3

모핑 기능4


📜 API 명세서

moping API 명세서 다운로드


📁 ERD

MySQL

image

MongoDB

image


🗺️ 시스템 아키텍처

image

🖼️ 프론트엔드

🛠️ 기술 스택

Language, Framework, Library

  • Next.js: 서버 사이드 렌더링(SSR)과 정적 사이트 생성(SSG)을 지원하여 페이지 로딩 속도와 SEO를 최적화합니다. 이를 통해 웹 애플리케이션의 성능과 사용자 경험을 크게 향상시킬 수 있습니다.
  • TypeScript: 강력한 타입 검사와 정적 타입 체킹을 제공하여, 개발 중 발생할 수 있는 런타임 오류를 사전에 방지하고 코드의 전반적인 품질을 높입니다. Next.js와의 통합을 통해 오류를 조기에 감지하고, 대규모 코드베이스의 관리를 용이하게 해줍니다.
  • React: UI 라이브러리로, 컴포넌트 기반 아키텍처를 통해 재사용 가능한 UI를 구축할 수 있으며, Next.js와 함께 서버 및 클라이언트에서 효율적으로 렌더링을 처리할 수 있습니다.
  • CSS/SCSS: 주로 Tailwind CSS를 사용하여 스타일링을 처리하지만, 복잡한 커스터마이징이나 특수한 스타일링 요구사항에 대응하기 위해 여전히 CSS/SCSS가 사용될 수 있습니다. Tailwind CSS는 유틸리티 클래스를 통해 신속하고 효율적인 스타일링을 가능하게 하지만, 프로젝트에 따라 CSS나 SCSS로 보완해야 할 때도 있습니다.
  • Tailwind CSS: 유틸리티 기반의 CSS 프레임워크로, 미리 정의된 클래스를 사용해 직관적이고 빠른 스타일링이 가능합니다. 별도의 CSS 파일 없이 HTML에서 직접 스타일을 적용할 수 있어 개발 생산성을 극대화하며, 필요 시 커스터마이징이 용이합니다.
  • ESLint와 Prettier: 코드 스타일을 자동으로 검사하고 일관성을 유지하며, 코드의 품질과 가독성을 높여줍니다.
  • Husky: Git hooks를 활용해 코드 푸시 시 자동으로 코드 검사를 실행하여 협업 중 코드 품질을 보장합니다.

CICD

  • Vercel: Vercel의 CI/CD 파이프라인은 자동화된 빌드 및 배포를 제공하여 개발 효율성을 극대화합니다. 간단한 설정으로 코드 변경 사항이 실시간으로 배포되며, Next.js 애플리케이션 배포에 최적화된 환경을 제공합니다.

🙏 협업 툴

  • Slack: 실시간 커뮤니케이션을 위한 협업 툴.
  • Notion: 문서화, 일정 관리, 작업 관리를 위한 툴.
  • Gather: 가상 오피스 환경에서 팀원들이 실시간 협업할 수 있는 툴.

Branch Naming Rule

branch는 작업 단위 & 기능 단위로 생성된 issue를 기반으로 합니다. 그러나 작은 수정 작업은 이슈 없이도 브랜치를 생성할 수 있습니다.

  • Branch Naming Rule:

    1. 기능 개발 또는 중요한 작업: 이슈를 먼저 생성하고 브랜치를 작성합니다. 이슈 번호와 작업의 도메인을 조합하여 브랜치 이름을 정합니다.
      • 예: feature/25-ui-component
    2. 작은 수정 작업: 문서 수정, 간단한 스타일링 변경 등 사소한 작업은 이슈 없이도 브랜치를 생성할 수 있습니다.
      • 예: docs/update-readme, style/update-button-styles

    Prefix 설명:

    • feature: 새로운 기능을 개발할 때 사용합니다.
    • bugfix: 버그를 수정할 때 사용합니다.
    • docs: 문서를 수정할 때 사용합니다.
    • config: 설정 파일 또는 환경 구성을 변경할 때 사용합니다.

File Naming Rule

  • 파일명 규칙: 파일 및 폴더 이름은 일관된 네이밍을 유지해야 하며, 팀원 간 파일명을 쉽게 인식할 수 있도록 해야 합니다.
    1. 컴포넌트 파일:
      • 컴포넌트 파일명은 PascalCase를 사용합니다.
      • 예시: Button.tsx, UserProfile.tsx
    2. 일반 파일:
      • 일반적인 유틸리티 함수, 설정 파일 등은 camelCase를 사용합니다.
      • 예시: formatDate.ts, fetchData.ts
    3. 폴더 이름:
      • 폴더 이름은 kebab-case로 작성하며, 소문자만 사용합니다.
      • 예시: user-profile/, button-styles/
    4. CSS/SCSS 파일:
      • 스타일 파일은 kebab-case로 작성합니다.
      • 예시: header-styles.scss, button.scss

PR

Pull Request Naming Rule

  • Pull Request: develop & main branch로 merge할 때에는 pull request가 필요합니다. PR 제목에는 간결하고 이해하기 쉬운 설명을 포함해야 합니다.
  • Pull Request Naming Rule: [<Prefix>] <Description> 의 양식을 준수하되, prefix는 commit message convention과 일관성을 유지합니다.

예시:

  1. 새로운 UI 컴포넌트 추가
    • Pull Request Title: [feat] 새로운 버튼 컴포넌트 추가
  2. 환경 설정 파일 수정
    • Pull Request Title: [chore] 환경 설정 파일 업데이트
  3. 버그 수정
    • Pull Request Title: [fix] 드롭다운 메뉴 버그 수정
  4. 문서 수정 작업
    • Pull Request Title: [docs] 프로젝트 README 업데이트

Issue 템플릿

🐛 Bug Report 템플릿

  • 설명: 버그에 대한 간단한 설명.
  • 재현 방법: 버그를 재현할 수 있는 단계별 설명.
  • 예상 결과: 기대했던 동작을 명시.
  • 환경: OS, 브라우저 등의 환경 정보.

✨ Feature Request 템플릿

  • 설명: 제안하는 기능에 대한 간략한 설명.
  • 동기: 이 기능이 필요한 이유.
  • 예상되는 기능: 예상되는 기능의 동작 방식 설명.

Pull Request Template

📄 Pull Request 템플릿

  • 관련 이슈: 작업한 이슈 번호를 명시합니다.
  • 작업 내용: 구현된 기능이나 변경 사항을 간략하게 설명합니다.
  • 스크린샷: 변경된 UI나 기능이 있다면, 스크린샷을 첨부합니다.
  • 추가 사항: 논의가 필요한 사항이 있으면 추가로 작성합니다.
  • 리뷰 요구 사항(선택): 특별히 검토가 필요한 사항이 있으면 적어주세요.

Commit Message Convention

[<Prefix>] #<Issue_Number> <Description> 의 양식을 준수합니다. 커밋 메시지는 코드 변경 사항을 명확하게 전달할 수 있도록 간결하고 구체적으로 작성해야 합니다.

  • feat: 새로운 기능 추가
    • 예시: [feat] #11 버튼 컴포넌트 구현
  • fix: 버그 수정
    • 예시: [fix] #10 UI 렌더링 오류 수정
  • docs: 문서 수정
    • 예시: [docs] #14 README 파일 업데이트
  • style: 코드 포맷팅, 세미콜론 누락 등 스타일 수정
    • 예시: [style] #23 코드 포맷팅 적용
  • refactor: 코드 리팩토링 (기능 변화 없음)
    • 예시: [refactor] #15 컴포넌트 구조 개선
  • chore: 기타 자잘한 수정 (빌드 스크립트 수정, 패키지 관리 등)
    • 예시: [chore] #21 패키지 의존성 업데이트
  • test: 테스트 코드 추가 또는 수정
    • 예시: [test] #18 버튼 컴포넌트 테스트 추가
  • perf: 성능 향상 관련 작업
    • 예시: [perf] #20 렌더링 최적화 작업
  • rename: 파일 및 폴더명 수정
    • 예시: [rename] #22 컴포넌트 파일명 수정
  • enhancement: 기존 기능의 개선 또는 새로운 기능 추가 (사용자 경험, 성능 등)
    • 예시: [enhancement] #25 사용자 피드백 반영하여 버튼 디자인 개선

💻 백엔드

👍 공통 사항

  • 단위 테스트 작성(service 메소드 별로) : Kotest 사용
  • 다른 사람이 알아보기 쉽도록 주석처리해야 합니다. (controller, service 메서드마다)
  • issue 생성 및 PR을 통해 본인이 구현한 부분에 대한 기록을 남겨야 합니다.
  • 테스트 및 원할한 서버 운영을 위한 로그를 작성해야 합니다.(에러나 운영에 필요한 로그. 검색시 검색어와 같은 로그)
  • 예외처리는 항상 잘 만들어두기 (code, message, data)
  • 개발 기간 : 9/30 ~ 11/24
  • 스프린트 (3일간격) 진행 (해올 것을 정해서 해오기)
    • 수요일, 토요일

🛠️ 기술 스택

  • Language, Framework, Library

    Kotlin Springboot Gradle Spring Data JPA

    • Kotlin은 간결하고 직관적인 문법으로 코드 생산성을 높이며, Null 안정성을 제공하여 오류를 사전에 방지
    • JPA를 통해 SQL을 직접 작성하지 않아도 되므로 데이터베이스 작업에 소요되는 시간을 줄이고, 비즈니스 로직 구현에 집중 가능

  • Test

    JUnit MockK

    • JUnit은 간단한 어노테이션 기반 설정으로 테스트 작성과 실행을 직관적이고 효율적으로 만들어줌
    • MockK는 코틀린에 특화된 모킹 라이브러리로, 코루틴과 같은 코틀린 고유 기능을 쉽게 모킹할 수 있어 비동기 코드 테스트에 강점이 있음

  • CICD

    Jenkins Docker

    • Jenkins를 사용한 CI/CD 파이프라인은 자동화된 테스트, 빌드, 배포를 통해 개발 프로세스를 효율적으로 관리
    • Docker는 애플리케이션을 컨테이너로 패키징하여 일관된 실행 환경을 제공하고, 배포를 빠르고 효율적으로 수행 가능

  • Database

    MySQL MongoDB Redis

    • MySQL은 뛰어난 성능과 확장성을 제공하며, 광범위한 커뮤니티 지원과 다양한 플랫폼에서의 안정성을 보장
    • MongoDB는 유연한 스키마 설계를 통해 다양한 데이터를 효율적으로 저장하고, 빠른 쿼리 성능을 제공
    • Redis는 인메모리 데이터 저장소로 초고속 데이터 접근과 다양한 데이터 구조를 지원

  • API 테스트, 명세서

    Notion Postman Spring REST Docs Swagger

    • RestDocs를 통해 생성된 문서를 Swagger UI로 시각화하여, 개발자와 비개발자 모두가 실시간으로 API를 테스트 가능
    • 테스트 코드 작성과 함께 API 문서가 자동으로 생성되어, 실제 코드와 문서의 동기화 문제가 발생하지 않음
    • 테스트 시에 문서를 검증할 수 있어 신뢰성을 높임

  • 🙏 협업 툴

    Slack Notion


🤙 개발규칙

⭐ Code Convention

Naming
  • 패키지 : 언더스코어(_)나 대문자를 섞지 않고 소문자를 사용하여 작성합니다.
  • 클래스 : 클래스 이름은 명사나 명사절로 지으며, 대문자 카멜표기법(Upper camel case)을 사용합니다.
  • 메서드 : 메서드 이름은 동사/전치사로 시작하며, 소문자 카멜표기법(Lower camel case)를 사용합니다. 의도가 전달되도록 최대한 간결하게 표현합니다.
  • 변수 : 소문자 카멜표기법(Lower camel case)를 사용합니다.
  • ENUM, 상수 : 상태를 가지지 않는 자료형이면서 static final로 선언되어 있는 필드일 때를 상수로 간주하며, 대문자와 언더스코어(UPPER_SNAKE_CASE)로 구성합니다.
  • DB 테이블: 소문자와 언더스코어로(lower_snake_case) 구성합니다.
  • 컬렉션(Collection): 복수형을 사용하거나 컬렉션을 명시합니다. (Ex. userList, users, userMap)
  • LocalDateTime: 접미사에 *Time**를 붙입니다.
Comment

1. 한줄 주석은 // 를 사용한다.

// 하이~

2. 한줄 주석 외에 설명을 위한 주석은 JavaDoc을 사용한다.

/**
 * 두 정수를 더합니다.
 *
 * <p>이 메소드는 두 개의 정수를 입력받아 그 합계를 반환합니다.</p>
 *
 * @param a 첫 번째 정수
 * @param b 두 번째 정수
 * @return 두 정수의 합
 * @throws ArithmeticException 만약 계산 중 오류가 발생하면
 */
Import

1. 소스파일당 1개의 탑레벨 클래스를 담기

탑레벨 클래스(Top level class)는 소스 파일에 1개만 존재해야 한다. ( 탑레벨 클래스 선언의 컴파일타임 에러 체크에 대해서는 Java Language Specification 7.6 참조 )

2. static import에만 와일드 카드 허용

클래스를 import할때는 와일드카드(*) 없이 모든 클래스명을 다 쓴다. static import에서는 와일드카드를 허용한다.

3. 애너테이션 선언 후 새줄 사용

클래스, 인터페이스, 메서드, 생성자에 붙는 애너테이션은 선언 후 새줄을 사용한다. 이 위치에서도 파라미터가 없는 애너테이션 1개는 같은 줄에 선언할 수 있다.

4. 배열에서 대괄호는 타입 뒤에 선언

배열 선언에 오는 대괄호([])는 타입의 바로 뒤에 붙인다. 변수명 뒤에 붙이지 않는다.

5. long형 값의 마지막에 L붙이기

long형의 숫자에는 마지막에 대문자 'L’을 붙인다. 소문자 'l’보다 숫자 '1’과의 차이가 커서 가독성이 높아진다.

URL

URL

URL은 RESTful API 설계 가이드에 따라 작성합니다.

  • HTTP Method로 구분할 수 있는 get, put 등의 행위는 url에 표현하지 않습니다.
  • 마지막에 / 를 포함하지 않습니다.
  • _ 대신 ``를 사용합니다.
  • 소문자를 사용합니다.
  • 확장자는 포함하지 않습니다.

☀️ Commit Convention

Rules

1. Git Flow

작업 시작 시 선행되어야 할 작업은 다음과 같습니다.

issue를 생성합니다.feature branch를 생성합니다.add → commit → push → pull request 를 진행합니다.pull request를 develop branch로 merge 합니다.이전에 merge된 작업이 있을 경우 다른 branch에서 진행하던 작업에 merge된 작업을 pull 받아옵니다.종료된 issue와 pull request의 label을 관리합니다.

2. IntelliJ

IntelliJ로 작업을 진행하는 경우, 작업 시작 시 선행되어야 할 작업은 다음과 같습니다.

깃허브 프로젝트 저장소에서 issue를 생성합니다.생성한 issue 번호에 맞는 feature branch를 생성함과 동시에 feature branch로 checkout 합니다.feature branch에서 issue 단위 작업을 진행합니다.작업 완료 후, add → commit을 진행합니다.remote develop branch의 변경 사항을 확인하기 위해 pull 받은 이후 push를 진행합니다.만약 코드 충돌이 발생하였다면, IntelliJ에서 코드 충돌을 해결하고 add → commit을 진행합니다.push → pull request (feature branch → develop branch) 를 진행합니다.pull request가 작성되면 작성자 이외의 다른 팀원이 code review를 진행합니다.최소 한 명 이상의 팀원에게 code review와 approve를 받은 경우 pull request 생성자가 merge를 진행합니다.종료된 issue와 pull request의 label과 milestone을 관리합니다.

3. Etc

준수해야 할 규칙은 다음과 같습니다.

develop branch에서의 작업은 원칙적으로 금지합니다. 단, README 작성은 develop branch에서 수행합니다.commit, push, merge, pull request 등 모든 작업은 오류 없이 정상적으로 실행되는 지 확인 후 수행합니다.

Branch

1. Branch

branch는 작업 단위 & 기능 단위로 생성된 issue를 기반으로 합니다.

2. Branch Naming Rule

branch를 생성하기 전 issue를 먼저 작성합니다. issue 작성 후 생성되는 번호와 domain 명을 조합하여 branch의 이름을 결정합니다. <Prefix>/<Issue_Number>-<Domain> 의 양식을 준수합니다.

3. Prefix

  • main : 개발이 완료된 산출물이 저장될 공간입니다.
  • develop: feature branch에서 구현된 기능들이 merge될 default branch 입니다.
  • feature: 기능을 개발하는 branch 입니다. 이슈 별 & 작업 별로 branch를 생성 후 기능을 개발하며 naming은 소문자를 사용합니다.

4. Domain

  • user, map, (error, config)

5. Etc

  • feature/7-user, feature/5-config
Issue

1. Issue

작업 시작 전 issue 생성이 선행되어야 합니다. issue 는 작업 단위 & 기능 단위로 생성하며 생성 후 표시되는 issue number 를 참조하여 branch 이름과 commit message를 작성합니다.

issue 제목에는 기능의 대표적인 설명을 적고 내용에는 세부적인 내용 및 작업 진행 상황을 작성합니다.

issue 생성 시 github 오른편의 assignee, label을 적용합니다. assignee는 해당 issue 담당자, label은 작업 내용을 추가합니다.

2. Issue Naming Rule

[<Prefix>] <Description> 의 양식을 준수하되, prefix는 commit message convention을 따릅니다.

3. Etc

[feat] 약속 잡기 API 구현
[chore] spring data JPA 의존성 추가
Commit

1. Commit Message Convention

[<Prefix>] #<Issue_Number> <Description> 의 양식을 준수합니다.

  • feat : 새로운 기능 구현 [feat] #11 구글 로그인 API 기능 구현
  • fix : 코드 오류 수정 [fix] #10 회원가입 비즈니스 로직 오류 수정
  • del : 쓸모없는 코드 삭제 [del] #12 불필요한 import 제거
  • docs : README나 wiki 등의 문서 개정 [docs] #14 리드미 수정
  • refactor : 내부 로직은 변경 하지 않고 기존의 코드를 개선하는 리팩터링 [refactor] #15 코드 로직 개선
  • chore : 의존성 추가, yml 추가와 수정, 패키지 구조 변경, 파일 이동 [chore] #21 yml 수정, [chore] #22 lombok 의존성 추가
  • test: 테스트 코드 작성, 수정 [test] #20 로그인 API 테스트 코드 작성
  • style : 코드에 관련 없는 주석 달기, 줄바꿈
  • rename : 파일 및 폴더명 수정
Pull Request

1. Pull Request

develop & main branch로 merge할 때에는 pull request가 필요합니다. pull request의 내용에는 변경된 사항에 대한 설명을 명시합니다.

2. Pull Request Naming Rule

[<Prefix>] <Description> 의 양식을 준수하되, prefix는 commit message convention을 따릅니다.

3. Etc

[feat] 약속 잡기 API 구현
[chore] spring data JPA 의존성 추가

About

No description, website, or topics provided.

Resources

Readme
Activity
Custom properties

Stars

0 stars

Watchers

0 watching

Forks

0 forks
Report repository

Releases

No releases published

Packages

No packages published

Contributors 4

  •  
  •  
  •  
  •  

Languages