README.md

Comfit

기업과 나를 연결하는 기준

Comfit은 기업의 핵심 정보와 나의 경험을 하나로 엮어 지원 기업별 맞춤 자소서 전략을 제안하는 AI 기반 분석 플랫폼입니다.

👥 Team member

이채영 👑	오수빈	정유진	배정민
@hummingbbird	@odukong	@u-zzn	@qowjdals23

🔧 Tech Stack

Comfit의 근거 있는 기술 스택 선정 과정 살펴보기 👀

역할	종류
Library
Programming Language
Formatting
UI Documentation
Styling
Data Fetching
Package Manager
Build Tool
Version Control
Deployment

🏁 Convention

👀 Commit Convention

가장 보편적으로 사용되는 방식인 Udacity Git Style Guide 기반 컨벤션을 따릅니다.

[init] 개발 환경 초기 세팅
[feat] 새로운 기능 추가
[fix] 버그 수정
[design] 스타일 변경 및 디자인 구현
[update] Fix와 달리 원래 정상적으로 동작했지만 보완의 개념
[remove] 파일을 삭제하는 경우
[move] 코드나 파일을 이동하는 경우
[rename] 파일 혹은 폴더명을 수정하는 경우
[docs] 문서를 수정한 경우
[comment] 필요한 주석 추가 및 변경
[refactor] 코드 리팩토링 (결과의 변경 없이 코드의 구조를 재조정, 가독성을 높임)
[test] 테스트 코드
[chore] 그 외 자잘한 수정
[deploy] 배포

👇 기본 구조

type: description (#이슈 넘버)

- 커밋에 대한 설명
- 커밋만 보고도 어떤 작업인지 이해할 수 있도록 하기 위함

👀 Git Convention

• 기본 틀: [type]/#[이슈넘버]/기능 이름 (ex)feat/#914/company-card-component)
• 기능 타입에 맞게 가장 앞단의 키워드를 변경해주세요. (feat / refactor / fix / hotfix/ chore 등)
• 기능 이름에는 kebab-case를 사용합니다.

👀 Coding Convention

📁 파일 및 폴더명

• 케밥 케이스(kebab-case) 사용
• 예: company-card.tsx

✨ 컴포넌트명

• 파스칼 케이스(PascalCase) 사용
• 예: const CompanyCard = () => {};

📛 변수

• 기본: var 금지

  	규칙	예시
  기본	camelCase	hotPostResponseData
  Boolean 타입	is 접두사 사용	isActive
  상수	대문자 스네이크 케이스	VITE_API_KEY, ROTATE_DELAY

🦾 함수

가독성과 유지보수성을 고려하여 Jake Trent의 네이밍 규칙을 따릅니다.

• 기본: 화살표 함수 사용

• 이벤트 핸들러

  • handle접두사 사용(단, props는 on 접두사 사용)
  • 네이밍 순서는 handle+명사+동사 (ex) handleButtonClick)
  • 2번 이상 사용될 경우 shared/lib 폴더에 생성

  <MyComponent onAlertClick={handleAlertClick} />

🆎 타입

• 기본: interface 사용(확장성 good 👍)
• 유니온, 리터럴 타입과 같은 특수한 경우에만 type 사용
• 네이밍: PascalCase(ex) LoginResponseType)

➕ 그 외

• 시맨틱 태그 사용(무지성 div 태그 ❌)
• border, border-radius와 같이 크기가 절대적으로 고정되어야 하는 경우 px 단위 사용
• 그 외 모든 것은 rem 단위로 통일
• letter-spacing: em 단위 적용
• 웹 접근성도 고려하는 개발
• import 문에서 type은 하단에 입력

📂 폴더 구조

fsd 구조는 표준화된 폴더 구조 방법론으로 이해 관계 파악이 용이하고, 기능을 중점으로 디렉토리가 나뉘어 코드의 위치가 명확하다는 장점이 있어요. Comfit 팀은 이와 같은 이유로 fsd 폴더 구조를 도입하게 되었어요. 더 자세한 도입 이유과 그 과정은 해당 PR에서 확인할 수 있어요.

src
 ┣ app // 프로젝트 초기화, 라우팅 설정 등
 ┃ ┣ layout
 ┃ ┣ providers
 ┃ ┣ routes
 ┃ ┣ styles
 ┃ ┣ App.tsx
 ┃ ┗ main.tsx
 ┣ features // 도메인 단위로 컴포넌트 관리
 ┃ ┣ bookmark
 ┃ ┣ company-analyze
 ┃ ┣ experience
 ┃ ┣ home
 ┃ ┣ login
 ┃ ┣ my-page
 ┃ ┣ onboarding
 ┃ ┗ register
 ┣ pages // 도메인 단위로 페이지 관리
 ┣ shared // 공유되는 항목들
 ┃ ┣ assets
 ┃ ┃ ┣ icons
 ┃ ┃ ┣ icons
 ┃ ┃ ┗ images
 ┃ ┣ config
 ┃ ┣ lib
 ┃ ┣ model
 ┃ ┣ stories
 ┃ ┣ styles
 ┃ ┃ ┣ tokens
 ┃ ┣ types
 ┃ ┗ ui
 ┗ widgets // 의미적으로 구분되는 컴포넌트(header, company-card 등)

👼 Ground Rule

🧩 협업 규칙

1. 존중하며 말하기
2. 카카오톡, 디스코드 등 소통 채널 빠른 확인 필수!
3. 적극적인 태도로 접근하고 같이 해결하기
4. 많이 웃기 !!! 😆😆😆😆

🧩 개발 규칙

1. 작업 전 코드리뷰부터 💨
2. PR 볼륨 조절하기(너무 큰 PR은 리뷰어에게 부담이 됩니다 😇)
3. 2인 이상 approve 필수🟢 / LGTM 지양❌
4. 근거 있는 개발, 근거 있는 AI 툴 사용 🤖
5. 컨벤션 잘 지키기 👮