프로듀싱하는데 협업을 하고 싶다?
당장 무명 작곡가라 수익구조가 필요하다!
즉각적으로 내 작품에 대한 리뷰를 받고 싶다!!
"작곡가"들을 위한 온라인 프로듀싱 협업 서비스🎤🎶🎸🎹
Collusic 프로젝트를 처음 접하시는 같이 개발하는 개발자에게 전합니다. 이 규칙은 서로의 코드를 더 잘 이해할 수 있게 정해진 규칙입니다. 때문에 언제든지 모든 개발자가 동의한다면 변경이 가능합니다. 규칙을 준수하여 서로의 발전을 도와줍시다.
- 파일이름의 형식은 "camelCase" 를 사용하도록 합시다.
- 컴포넌트 (react)는 "CamelCase" 구조를 따릅니다.
- 컴포넌트는 파일명 혹은 index.jsx의 경우 상위 폴더이름을 따라야합니다. ex) root/index.js =>
- 파일 이름은 소문자로 시작하지만 컴포넌트 이름은 대문자로 시작합니다.
- 변수, 함수명은 "camelCase" 를 사용합니다.
- class 나 함수형 컴포넌트의 이름은 "CamelCase" 을 따릅니다.
- enum에 선언되는 값들은 "CAPITAL_UNDER_SCORE" 를 따릅니다.
- 컴포넌트를 제외한 함수의 이름은 동작의 의미가 담겨 있어야 합니다.
- 컴포넌트 코드가 들어간 파일의 확장자는 jsx를 사용합니다.
else 사용을 최대한 자제합니다.
컴포넌트 렌더링의 경우 삼항연산자 사용을 권장합니다.
하나의 함수는 하나의 역할만을 합니다.
한 메서드에 오직 한단계의 들여쓰기만 합니다.
작은 변수들을 목적을 나타내는 객체 안에 할당하여 목적을 분명히 합니다.
메서드, 클래스, 변수 이름을 축약하지 않고 목적을 가지고 있는 클래스 안에 집어넣어 목적을 나타냅니다.
클래스는 50줄 이하, 패키지 10개 이하로 제한합니다.
게터/세터 속성 사용을 금지합니다.
규칙1, 2, 3, 5, 6, 9
https://developerfarm.wordpress.com/2012/02/03/object_calisthenics_summary/
수정이 필요한 Issue는 Icebox에 보관합니다.
수정이 끝난 Issue는 client, server 분야에 따라 Frontend Backlog, Backend Backlog에 각각 보관합니다.
- main 브랜치 => product에 배포되는 브랜치
- main 브랜치는 언제든지 배포 가능해야 한다.
- 무조건 PR을 날려 검토받는다. (PR은 최대한 자세히)
- 브랜치 생성
- main 브랜치에서 생성해와야 한다.
- 브랜치 이름은 한 눈에 어떤 작업을 위한 브랜치인지 알 수 있는 이름을 가져간다.
- feature/Issue-(Issue번호) 형식의 해당 Issue에 맞는 단위 개발 브랜치를 생성해 작업한다.
- 커밋
- 파일을 추가, 수정, 삭제할 때 마다 커밋하여 작업 히스토리를 남긴다.
- 작업을 진행한 이유를 다른 사람이 알 수 있도록 커밋 메세지를 남긴다.
- Pull Request
- 피드백이나 도움이 필요할 때, merge 준비가 완료된 경우 PR을 생성한다.
- 요청을 수락하면 변경 내용을 브랜치에 merge한다.
- main으로 merge, push 되었을 때는 즉시 배포되어야 한다.
- main으로 merge가 일어나면 자동으로 배포가 되도록 설정