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

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

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

(1) 양방향 공간 선택

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

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

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

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

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

선별된 공간 정보

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

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

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

moping API 명세서 다운로드

• 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를 활용해 코드 푸시 시 자동으로 코드 검사를 실행하여 협업 중 코드 품질을 보장합니다.

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

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

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

• Branch Naming Rule:

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

  Prefix 설명:

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

• 파일명 규칙: 파일 및 폴더 이름은 일관된 네이밍을 유지해야 하며, 팀원 간 파일명을 쉽게 인식할 수 있도록 해야 합니다.
  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

• 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 업데이트

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

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

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

[<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 메서드마다)
  • javadoc 형식 https://jake-seo-dev.tistory.com/59
• issue 생성 및 PR을 통해 본인이 구현한 부분에 대한 기록을 남겨야 합니다.
• 테스트 및 원할한 서버 운영을 위한 로그를 작성해야 합니다.(에러나 운영에 필요한 로그. 검색시 검색어와 같은 로그)
• 예외처리는 항상 잘 만들어두기 (code, message, data)
• 개발 기간 : 9/30 ~ 11/24
• 스프린트 (3일간격) 진행 (해올 것을 정해서 해오기)
  • 수요일, 토요일

• Language, Framework, Library

  

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

• Test

  

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

• CICD

  

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

• Database

  

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

• API 테스트, 명세서

  

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

• 🙏 협업 툴

  

// 하이~

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