CAKEY 🎂

주문제작 케이크, 비교도 달콤하게 한입에! 😋

🥄 About CAKEY

케이키 Cakey는 주문제작 케이크에 대한 정보를 한 눈에 모아보고 비교할 수 있는 서비스 입니다 🎂

⏲️ 정보의 어그리게이션 및 조건별 필터링

• 정보의 분산으로 여러 SNS(인스타그램, 카카오톡)나 웹사이트를 개별적으로 방문해야 하며, 업체별로 가격, 스타일, 옵션을 확인하는 데 많은 시간을 소비하게 되는 문제를 해결하기 위한 기능이에요.
  • 흩어져 있는 디자인/가격 등에 대한 정보를 하나의 서비스로 모아요.
  • 필터링 기능을 통해 사용자의 정보 비교를 용이하게 해요.
  • 찜 기능을 통해 마음에 드는 스토어 및 디자인을 저장할 수 있어요.

📍 지도 기반 검색 및 위치 비교

• 홍대를 검색하면 합정 스토어가 나오는 것과 같은 광범위한 위치 분류 문제를 해결하기 위한 기능이에요.
  • 핀 기능을 통해 목적지 및 약속장소를 입력하면 주위의 스토어들을 알 수 있어요.
• 인기 스토어만 제한적으로 뜨는 인스타 검색창의 한계를 보완하기 위한 기능이에요.
  • 지역으로 검색 시 (ex. 홍대입구역)

👩🏻‍🍳 CAKEY Developers

팀원	🍀 유서연	🐱 손지유	👻 임화랑	🥨 박채연
팀원 소개
역할	WEB FRONTEND	WEB FRONTEND	WEB FRONTEND	WEB FRONTEND

🍴 Tech Stack

역할	종류
Library
Programming Language
Styling
Data Fetching
Formatting
Package Manager
Version Control
Test
Deploy

🧂 Library

라이브러리	버전	도입이유
	^18.3.1	재사용 가능한 컴포넌트 기반 아키텍처와 가상 DOM을 활용한 성능 최적화로 효율적이고 확장성 있는 UI 개발이 가능합니다.
	~5.6.2	정적 타입 검사를 통해 코드 안정성을 높이고, 강력한 IDE 지원으로 개발 생산성을 향상시킵니다.
	^1.17.0	정적 타입 기반 CSS-in-JS로 유지보수성과 성능을 모두 고려한 스타일 관리가 가능합니다.
	^8.4.7	UI 컴포넌트를 독립적으로 개발하고 테스트하며, 문서화를 통해 협업을 개선할 수 있습니다.
	^5.62.16	복잡한 비동기 상태 관리를 간소화하고, 서버 상태를 효율적으로 동기화하여 데이터 페칭과 캐싱을 최적화합니다.

🗂️ 프로젝트 폴더 구조

|-- 📁 node_modules
|-- 📁 public
    |-- 📁 svg
    |-- 📁 data
        |-- userData.json
|-- 📁 src
    |-- 📁 assets
        |-- 📁 svgs
        |-- 📁 images
    |-- 📁 components
        |-- 📁 common 
            |-- 📁 Button 
                |-- Button.tsx
                |-- Button.css.ts
            |-- index.ts 
    |-- 📁 pages
        |-- 📁onboarding
            |-- 📁components
            |-- 📁types
            |-- 📁hooks
            |-- 📁page
                |-- 📁OnboardingPage
                |-- OnboardingPage.tsx
                |-- OnboardingPage.css.ts
    |-- 📁 hooks
    |-- 📁 stories
        |-- 📁 Button.stories.ts
    |-- 📁 styles
    |-- 📁 utils 
    |-- 📁 constants
        |-- routePath.ts
    |-- 📁 apis
        |-- 📁 domains
        |-- 📁 queryKeys
    |-- 📁 types
    |-- 📁 routes
        |-- homeRoutes.tsx
        |-- adminRoutes.tsx
        |-- index.ts
|-- App.tsx
|-- main.tsx
|-- .eslintrc.json
|-- .gitignore
|-- .prettierrc
|-- README.md
|-- package.json
|-- tsconfig.json
|-- yarn.lock

📏 컨벤션

1️⃣ Coding

변수

• var 금지.
• const → let 순서로 위부터 선언.
• 변수를 조합하여 문자열 생성시 “+ “ 금지. → 리터럴 사용(백틱 ```)
• 상수는 영문 대문자 스네이크케이스 : API_KEY
• 변수명 : 의미를 확실히 나타낼 수 있도록
  • 예시 : 배열에 Arr 보다는 변수s = fruits, userlists 등등
• 줄임말 쓰지말기. 이름이 길어지더라도 어떤 변수인지 정확하게
• 만약 변수에 할당되는 값이 boolean인 경우에는 is를 접두사로 붙인다.
  • isActive 같이 is 키워드는 boolean에만 적용
• map 사용시 변동되는 리스트라면 key값을 고유하게 잘 설정해주기 index사용금지
  • 서버에서 내려주는 id값 or uuid 사용

함수

• 화살표 함수. function 키워드 쓰지말기
• 함수명 : 어떤 일을 하는지 명확히 묘사. 동사+명사의 형식.
  • get : 어떤 값을 얻는 함수
  • create : 갖고 있는 변수를 활용, 새로운 값과 변수를 만듦
  • check : 함수 안의 로직을 확인.
  • 그외, 기능을 분명하게 드러내도록 네이밍
• 이벤트 핸들링 함수는 handle 로 시작. 그 외에는 금지.
  • 예시: handleResetClick, handleSubmitClick
• 유틸함수는 반환값을 기준으로 이름 네이밍
  • boolean값 반환시 has—- ex) hasEmail = email이 존재하는지 여부를 반환하는 함수
• 중복함수는 utils 폴더에 모아서 재사용한다.

컴포넌트

• rafce

• 리액트 컴포넌트만 PascalCase 사용 : PascalCase

  • 그 외에는 camelCase ex) type, d.ts파일, ts파일

• 타입 Interface 선언시

  • 컴포넌트의 인자 : ~Props (ex. HomeProps, AdminProps)
    • 이때의 Interface는 type 폴더로 분리 금지
  • ex) MainComponent interface 선언시 = MainProps

• props명은 camelCase 대문자시 문제 생김

• 의미없는 div 또는 컴포넌트 최상단은 fragment 사용하기

  const InfoText = () => {
    return (
      <>
        <h1>Welcome!</h1>
        <p>This our new page, we're glad you're are here!</p>
      </>
    );
  };

• children이 불필요할 땐 selfClosing사용하기 <Component />

폴더명

• 무조건 소문자로 시작하기!
• 뒤에 s붙이기
• 카멜케이스!

타입

• object → interface
• 단일변수 → type
• 컴포넌트 인자에 대한 타입은 컴포넌트 상단에
• 그 외의 타입들은 types 폴더에(컴포넌트 인자에 배열or객체 등이 있다면 이 타입도 types 폴더로)
• prop의 타입명은 OOOProps
• api response 타입명은 OOOResponseTypes

메소드

• 배열 복사시 → 스프레드 연산자(…) 사용

  • const copys = […originals]

• for 보단, forEach/map을 사용

• 구조 분해 할당을 적극 이용

  interface userDataProps {
    userName: string;
    userBirth: string;
  }
  
  function checkIsUser({ userName, userBirth }: userDataProps) {}

• 불필요한 반복문 지양 : filter, array.include() 등

  • 조건부로 데이터를 확인하거나 뽑아야하는 로직을 사용할 때에는 Map 이나 Object처럼 key값을 이용해서 원소를 찾는 자료형을 이용하는것을 고려해보거나, 배열을 순회하지 않고 index로 바로 접근할 수 있는 방법이 없는지 고려.

2️⃣ Git & Github

Git Flow

• main: 제품을 배포하는 브랜치
• develop: 개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 Merge
  • develop 브랜치를 기준으로 feature 브랜치를 분기하고, 각 feature 브랜치를 합침
  • develop 브랜치에서 main 브랜치로 병합
• feature: 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치에 Merge
  • 반드시 develop 에서 분기해야 됨. 분기 된 다른 feature 브랜치에서 또 다른 feature 브랜치를 분기하면 절대 안됨.

현 프로젝트에서는 release, hotfix 브랜치는 사용하지 않음.

브랜치 생성

기능 구현 전 자신이 구현할 부분을 이슈로 관리

1. 이슈템플릿 을 활용하여 이슈 생성
2. 1에서 생성된 이슈 번호를 이용하여 브랜치 생성.
   1. 브랜치 이름은 feat/#<issued number>/example ex) feat/#18/common-button

작업

모든 작업은 develop 에서 분기된 feature 브랜치에서 진행

• 커밋 메시지는 커밋유형: <구현, 수정, 개발한 내용에 대한 커밋 메시지> (#<issued number>) ex) feat: Button 공통 컴포넌트 제작 (#18)

  커밋유형	의미
  feat	새로운 기능 추가
  fix	버그 수정
  docs	문서 수정
  style	코드 formatting, 세미콜론 누락, 코드 자체의 변경이 없는 경우
  refactor	코드 리팩토링
  test	테스트 코드, 리팩토링 테스트 코드 추가
  chore	패키지 매니저 수정, 그 외 기타 수정 ex) .gitignore
  design	CSS 등 사용자 UI 디자인 변경
  comment	필요한 주석 추가 및 변경
  deploy	배포 관련
  setting	개발 환경 세팅

브랜치 병합

feature 브랜치에서 develop 브랜치로 merge할 때는 PR을 이용함 (직접 merge ❌)

1. develop, feature 브랜치 최신화

2. develop → feature merge 하고 충돌 처리

   • feature 브랜치로 checkout 해서 git merge develop

3. PR템플릿 을 활용하여 PR 작성

   • PR 작성시 이슈번호 제대로 기입해야 이슈가 함께 닫힘(템플릿대로 하면 됨)
   • 팀원들의 review & approve(2명) 후 스쿼시 머지

   주의⚠️ - review & approve 과정에서 다른 PR 머지 등 develop에 수정사항이 생겼다면, 2번과정을 다시 해줘야 함.

4. 정상적으로 머지 되었다면 feature 브랜치 삭제

---