38-COLLABORATION-WEB-29cm

LET'S SOPT 38기 합동세미나 데스크탑 웹 3조 29cm 🛒

🛒 29cm

👥 팀 소개

박진석

이혜원

이채원

박우찬

이현종

📁 팀원 별 구현 사항

📌 진석

📌 혜원

📌 채원

📌 우찬

📌 현종

🚀 Tech Stack

카테고리	기술 스택
UI Library
Language
Build Tool
Package Manager
Server State Management
Styling
Version Control
CI/CD
Deployment
Cooperation
Formatting
UI Documentation

📁 Directory Structure

📦 38-COLLABORATION-WEB-29CM
│
└── 📁 src
    ├── 📁 app
    │   ├── 📁 layout
    │   ├── 📁 router
    │   ├── App.tsx
    │   └── main.tsx
    │
    ├── 📁 pages
    │   ├── 📁 home
    │   │   ├── 📁 api
    │   │   ├── 📁 assets
    │   │   ├── 📁 components
    │   │   ├── 📁 hooks
    │   │   └── home-page.tsx
    │   │
    │   ├── 📁 product
    │   │   └── product-page.tsx
    │   │
    │   ├── 📁 error
    │   │   └── error-page.tsx
    │   │
    │   └── 📁 showcase
    │       ├── 📁 api
    │       ├── 📁 components
    │       ├── 📁 hooks
    │       └── showcase-page.tsx
    │
    └── 📁 shared
        ├── 📁 api
        ├── 📁 constants
        ├── 📁 hooks
        ├── 📁 icons
        ├── 📁 styles
        ├── 📁 types
        ├── 📁 ui
        └── 📁 utils

🗂️ Convention

🪾Git Flow

🌿 브랜치 전략

브랜치	역할	설명
main	Production	출시될 수 있는 안정된 상태의 코드를 관리합니다.
develop	Development	모든 기능 개발이 이 브랜치를 기반으로 진행됩니다.
Feature	Feature	기능 구현 및 버그 수정을 위한 개별 작업 브랜치입니다.

🚀 개발 프로세스

1. 이슈 기반 브랜치 생성

   • 모든 작업 시작 전 GitHub Issue를 생성합니다.
   • 해당 이슈 번호를 기준으로 develop 브랜치에서 기능 별 이슈 브랜치로 분기합니다. (feat/기능명/#issue-number)

2. 작업 및 PR 생성

   • 기능 구현이 완료되면 PR을 생성합니다.
   • 팀원 중 2명 이상의 Approve이 있을 때, develop 브랜치로 병합합니다.

3. 브랜치 삭제

   • develop 브랜치로 병합 후, 사용이 끝난 이슈 브랜치는 삭제합니다.

📝 커밋 컨벤션

• init: 커밋 메시지

Prefix

유형	의미	상세 내용
feat	새로운 기능 추가	새로운 기능 구현
fix	버그 수정	오류 수정
hotfix	긴급 수정	치명적인 버그 즉시 수정
refactor	리팩토링	코드 구조 개선 (기능 변화 X)
style	스타일 변경	스타일 코드 및 포맷팅 변경
docs	문서 수정	문서 작성 및 수정
chore	기타 수정	빌드 업무, 패키지 매니저 등 설정 변경
perf	성능 개선	성능 최적화 코드
remove	파일 삭제	미사용 파일 삭제
revert	커밋 되돌리기	이전 커밋 복구
init	초기 세팅	프로젝트 초기 세팅

📄 Code Convention

---

⚛️ 컴포넌트

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

  • 의미 없는 div 태그 사용 지양
  • 최상단 fragment 사용
  • children이 불필요할 땐 selfClosing사용하기 <컴포넌트 이름/>
  
  

  const InfoText = () => {
    return (
      <>
        <h1>Welcome!</h1>
        <p>We are Team-29cm!</p>
      </>
    );
  };

📁 폴더명

• 케밥 케이스(kebab-case) 사용

  • 폴더명과 파일명 모두 케밥 케이스를 적용합니다.
  • ❌️️ UserProfile/, loginForm.tsx
  • ✅ user-profile/, login-form.tsx

• 무조건 소문자로 시작

  • 모든 파일과 폴더는 소문자로 시작하여 일관성을 유지합니다.
  • ❌ Main-header.tsx
  • ✅ main-header.tsx

🧩 타입

• PascalCase 사용

  • 타입과 인터페이스 이름은 PascalCase로 작성합니다.

• interface 사용 지향

  • 객체 구조 정의 시 type 대신 interface를 사용합니다.

• Props 네이밍 규칙

  • 컴포넌트의 Props 타입은 [컴포넌트명] + Props 접미사를 붙입니다.
  • interface ShowcaseProps { ... }

• 일반 타입 네이밍 규칙

  • 그 외 일반적인 타입 정의 시에는 이름 뒤에 Types 접미사를 붙입니다.
  • interface UserTypes { ... }

💡 변수

• 변수 및 상수 선언

  • const → let 순서로 선언 (var 금지)
  • 상수는 UPPER_SNAKE_CASE 사용 (ex. API_KEY)
  • 줄임말 지양, 의미 있는 변수명 사용 (ex. userData)

• 데이터 구조 및 타입

  • 복수 데이터는 끝에 s 사용 (ex. productItems)
  • Boolean은 is 접두사 사용 (ex. isActive)
  • 문자열 조합은 템플릿 리터럴(`) 사용

• map 사용 시 key에 index 사용 지양 (고유 ID 권장)

🔑 함수

• 화살표 함수(const) 사용을 원칙으로 합니다.

• 네이밍: [동사 + 명사] 형식을 사용합니다.

  • get: 값 반환 | create: 신규 생성 | check: 로직 확인
  • convert: 형태 변환 | add/minus: 수치 연산 | filter: 배열 필터링

• 이벤트 핸들러: 오직 이벤트 관련 함수에만 handle을 붙입니다.

  • 동작을 상세히 기록 (ex. handleResetClick, handleSubmitClick)

• 유틸 함수: 반환값 중심으로 네이밍합니다.

  • Boolean 반환 시 has 접두사 사용 (ex. hasEmail)

🏗️ 배열 & 구조 분해

• 배열 복사: 스프레드 연산자(...) 사용
  • ex) const copys = [...originals]
• 반복문: for문 지양, forEach나 map 사용 권장
• 구조 분해 할당: 객체/배열 추출 시 필수 사용 (특히 Props 및 함수 파라미터)