코드 리뷰를 하면서 팀원 간에 합의한 개발 관습을 문서화합니다. 항상 최신의 상태를 유지하기 위해서 팀원 모두 노력해주셨으면 좋겠습니다.

• 무료 프로젝트 관리 기능인 깃허브 프로젝트를 통해서 이슈(Jira의 티켓 개념)를 관리합니다.
• 이슈를 생성할 때는 이슈 유형(Type)을 반드시 선택해주시고, 프로젝트에 추가 후 우선 순위(Priority)와 예상 소요 시간(Est)를 함께 넣어주세요.
• 이슈를 생성할 때는 스프린트(Sprint)와 상태(Status)는 비워두어 일단 백로그(Backlog)에 두도록 합니다.
• 이슈는 팀 회의 때 Grooming, Triage, Planning 과정을 거친 후에 스프린트에 추가하는 것이 원칙입니다.
• 긴급 이슈가 있거나 스프린트에 To Do 이슈가 소진되었을 때는 디스코드에서 소통 후에 현재 스프린트에 추가해주세요.
• 자율적인 협업과 자발적인 기여를 위해서 특별한 사유가 없다면 이슈를 생성할 때 담당자를 설정하지 않습니다.
• 이슈의 상태는 스프린트에 추가되었을 때 부터 To Do로 설정해주세요.
• 작업을 시작하시면 이슈의 상태를 반드시 In Progress로 옮겨주세요. (많이 까먹는 부분입니다.)
• 이슈가 연결된 Pull Request가 병합되면 이슈는 자동으로 Done 상태로 전환됩니다.
• 동시에 2개 이상의 이슈를 할당하지 않도록 주의해주세요. WIP가 2보다 커지면 팀의 리뷰 부담이 커지게 됩니다.
• PM이 구해질 때 까지 모두가 PM이라는 마음가짐으로 프로젝트에 임해주세요. 스스로 티켓을 생성하고 요구 사항을 상세히 작성해주세요.
• 서브 이슈는 Spike 티켓에서 파생된 Action 티켓에 한해 사용합니다.
• 서브 이슈가 완료되지 않아도, 상위 Spike 티켓(Parent Issue)은 완료 처리될 수 있습니다.

1. 프로젝트 보드에서 To Do 상태의 티켓을 선택하고 본인에게 할당합니다.
2. 프로젝트 설정

• 먼저 프로젝트 설정 가이드를 완료합니다.

3. 브랜치 생성

• main 브랜치에서 새로운 feature 브랜치를 생성합니다.
• 브랜치 이름에는 -, _ 외의 특수문자 사용은 제한됩니다.
  참고 이슈

4. 기능 구현 및 커밋

• 브랜치 내에서 소스 코드를 수정하고 커밋합니다.
• 변경이 모두 완료되면 포크받은 리포지토리의 브랜치를 푸시합니다.

5. 테스트 작성

• 기여한 코드가 정상적으로 동작하는지 확인할 수 있는 테스트 코드를 작성합니다.

6. PR 생성

• Pull Requests 페이지에서 새로운 PR을 생성합니다.
• PR의 제목과 설명은 가급적 한국어로 작성해주세요. 이슈 제목과 일치해주면 나중에 찾기가 편합니다.
• PR이 등록된 이슈와 연관되어 있다면, PR 생성 후 오른쪽 사이드바의 Development 항목에서 해당 이슈를 선택해 연결해주세요.

7. PR 리뷰 및 병합

• 최소 한 명 이상의 관리자가 PR을 검토하고 코멘트를 남깁니다.
• 변경 요청이 있을 경우, 수정을 반영한 후 다시 푸시하고 리뷰를 요청합니다.
• 디자인 변경이 있을 경우, PR에 ui 태그를 달아서 Chromatic을 실행합니다.
• UI Review 체크에서 해당 디자인을 담당한 디자이너에게 리뷰를 요청합니다. (생성된 PR의 하단 Merge 부분에서 확인할 수 있음)

UI Review: 작업 내역을 디자인 담당자에게 확인 요청하는 작업

UI Tests: 코드 변경으로 발생한 UI 변경이 혹시 UI Regression은 아닌지 Chromatic이 떠준 스냅샷을 하나씩 비교하면서 개발자가 스스로 확인해주는 작업

• 최소 1개의 승인을 받은 후 main 브랜치에 병합됩니다.
• 이후 릴리즈를 통해 기여한 내용이 배포됩니다.

• src/components 아래에 폴더를 만들고, 그 안에 컴포넌트 파일, 스토리 파일, 테스트 파일을 위치시킵니다.
• 폴더 이름, 파일 이름, 컴포넌트 이름은 모두 PascalCase로 letter case를 통일합니다.
• 변수 이름, 함수 이름, prop 이름은 모두 camelCase로 letter case를 통일합니다.
• index.tsx 파일을 통해서 re-export하지 않습니다.

├── src
│ ├── components
│ │ ├── Checkbox
│ │ │ ├── Checkbox.stories.tsx
│ │ │ ├── Checkbox.test.tsx
│ │ │ └── Checkbox.tsx

• 관련 논의: https://github.com/DaleStudy/leaderboard/pull/18#pullrequestreview-2377895806

• 함수 컴포넌트 작성할 때는 function 키워드로 선언해주세요.
• 이벤트 핸들러를 작성할 때는 화살표 함수를 선언 후에 변수에 할당해주세요.
• Boolean props는 is, has 접두사를 사용하지 않고 형용사 형태로 작성해주세요. (예: reversed)
• API의 설명을 작성할 때는 명사형태로 작성해주세요 (예: /** 비활성화 상태 */)
• 신규 컴포넌트 개발시 index.ts에 re-export를 하여 root importimport { button } from "daleui"가 가능하게 해주세요

• 스토리 제목이 컴포넌트 경로를 통해서 자동으로 유추될 수 있도록 title 속성의 값은 생략해주세요. 문자열로 직접 명시하면 타입 안전하지 않고, 컴포넌트 이름을 바꿀 때 싱크가 깨지기 쉽습니다.
  • 관련 논의: https://github.com/DaleStudy/daleui/pull/168#discussion_r2048006809
• 여러 스토리에 걸쳐서 필요한 args는 스토리 수준에서 중복하지 마시고 컴포넌트 수준에서 지정해주세요.
  • 관련 논의: https://github.com/DaleStudy/daleui/pull/168#discussion_r2048008436
• 컴포넌트의 기본값은 args에서 선언하여, 스토리에서 기본적으로 선택되도록 작성해주세요.
  • 관련 논의: https://github.com/DaleStudy/daleui/pull/792#discussion_r2756976616
• 스토리북은 컴포넌트 함수의 타입에 따라서 알아서 최적의 arg type을 적용해줍니다. 스토리북이 기본으로 설정해준 arg type을 덮어쓰면 컴포넌트의 타입이 변할 때 마다 개발자가 계속 신경써서 arg type을 조정 해줘야하는데 매우 까먹기 쉬운 부분입니다. 따라서 아주 타당한 이유가 있지 않는한 arg type을 직접 지정하는 것은 삼가해주세요.
  • 타당한 이유 예시)
    1. reactNode Type을 사용해서 story에서 따옴표(")를 사용해야할 때 -> control: 'text' 사용
    2. 컴포넌트를 여러개 export하는 compound pattern의 경우 -> argType 사용
• 항상 고정되어야 하는 prop은 Story의 argTypes에서 control: false로 선언합니다.
  • ex) Orientation Story에서 orientation props

• 테스트 파일은 별도의 디렉토리에 중앙화 하지 않고 애플리케이션 파일 바로 옆에 둡니다.
• 단순한 테스트 구조를 위해서 테스트 대상 모듈의 구조가 복잡하지 않다면 describe()-it() 대신에 test()를 씁니다.
• 이벤트를 발생시킬 때는 fireEvent 대신에 @testing-library/user-event 패키지를 사용해 주세요. 브라우저 입장이 아닌 사용자 입장에서 테스트를 작성하기 위함입니다.
  • 관련 논의: https://github.com/DaleStudy/daleui/pull/170#discussion_r2057064150
• 테스트 제목은 한국어 사용자가 쉽게 명세를 파악하기 쉽도록 한글로 작성해주세요.
  • 관련 논의
    • https://github.com/DaleStudy/daleui/pull/168#discussion_r2059342361
    • https://discord.com/channels/775115965964222492/1280152682044063837/1366565616299020288
• 스토리(Storybook) 와 테스트(Unit Test) 는 목적이 다르므로 분리 작성합니다.
  • 스토리: 문서화 및 데모 목적 / 테스트: 동작 검증 및 명세 목적
  • 따라서, 스토리에 의존하는 테스트(composeStories 등)는 사용하지 않습니다.
  • 테스트는 스토리 변경에 영향받지 않고 독립적으로 동작해야 합니다.
  • 관련 논의: Github 이슈, 관련 논의: 디스코드 정리