🎸 AMP

🎧 TEAM-DECIBEL

소현

지수

진석

나은

🚀 Tech Stack

카테고리	기술 스택
Library
Server State Management
Language
Build Tool
Styling
Repository Management
Build System
Package Manager
CI/CD

---

🗂️ 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	기타 수정	빌드 업무, 패키지 매니저 등 설정 변경
build	빌드 시스템	빌드 도구 및 종속성 변경
ci	CI 설정	CI 설정 파일 및 스크립트 수정
perf	성능 개선	성능 최적화 코드
test	테스트	테스트 코드 추가 및 수정
type	타입 수정	타입 정의 수정
asset	리소스 추가	디자인 에셋(svg, img) 추가
rename	이름/위치 수정	파일명 수정 및 폴더 이동
remove	파일 삭제	미사용 파일 삭제
revert	커밋 되돌리기	이전 커밋 복구
init	초기 세팅	프로젝트 초기 세팅

📄 Code Convention

---

⚛️ 컴포넌트

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

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

  const InfoText = () => {
    return (
      <>
        <h1>Welcome!</h1>
        <p>We are Team-Decibel!</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 AmpProps { ... }

• 일반 타입 네이밍 규칙

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

💡 변수

• 변수 및 상수 선언

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

• 데이터 구조 및 타입

  • 복수 데이터는 끝에 s 사용 (ex. userLists)
  • 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 및 함수 파라미터)

// 1. Interface 네이밍 (PascalCase + Types)
interface VoteAllInfoTypes {
  date: number;
  time: string;
}

interface UserDataTypes {
  userName: string;
  userBirth: string;
}

// 2. 구조 분해 할당 적용 예시
const MonthVoting = ({ date, time }: VoteAllInfoTypes) => { ... }

const checkIsUser = ({ userName, userBirth }: UserDataTypes) => { ... }

🎨 스타일

🏗️ Markup Naming

• 요소를 감싸는 Wrapper는 container로 명칭 통일
• 스타일 네이밍은 요소의 의미가 드러나도록 작성 (ex. user-list-container)

💄 CSS Property Order (Mozilla Style)

속성 기술 시 아래의 흐름(바깥에서 안쪽으로)을 최대한 준수합니다.

1. Display & Layout: display, position, float, z-index
2. Box Model: width, height, margin, padding
3. Visual: border, background, opacity
4. Typography: color, font, text-align, white-space
5. Content: content (pseudo-elements)

CSS 속성 기술 순서

1. display -객체의 노출여부/표현방식--
2. list-style
3. position -위치/좌표--
4. float
5. clear
6. width / height -크기/여백--
7. padding / margin
8. border / background -윤곽/배경--
9. color / font -글자/정렬--
10. text-decoration
11. text-align / vertical-align
12. white-space
13. other text
14. content -내용--

‼️ Ground Rule

---

🙌 협업 규칙

• 💡 모르는 것을 부끄러워하지 않기

• 🙋‍♂️ 질문 많이 하기

• 🌱 서로 배려하며 소통하기

• 🧐 깊이 생각하고 고민해보기

• ⏰ 매일 데일리 스크럼 지키기

🔍 코드리뷰 규칙

1️⃣ 둥글게 말하기

• 공격적이거나 단정적인 표현은 지양합니다.

2️⃣ 근거 있는 리뷰

• 개인의 취향이 아닌 객관적인 이유와 맥락을 설명합니다.
• 더 나은 대안이 있다면 관련 공식 문서나 레퍼런스(Reference) 링크 첨부를 적극 권장합니다.

3️⃣ 코드래빗(AI)에 의존하지 않기

• AI 리뷰어는 보조 도구일 뿐입니다. 자동 리뷰에 의존하여 대충 넘기지 않습니다.
• 작성자의 로직, 의도, 비즈니스 맥락을 우리 스스로 꼼꼼히 확인하고 검증합니다.

4️⃣ 비판적 수용

• 모든 리뷰 코멘트를 무조건적으로 수용할 필요는 없습니다.
• 의견이 다를 경우 적극적으로 토론하며, 의견을 나눕니다.