박희선 |
김채은 |
윤소은 |
김예원 |
| @heesunee | @bongtta | @Dubabii | @yeeewww |
| 역할 | 종류 |
|---|---|
| Library |  |
| Programming Language |  |
| UI Documentation |  |
| Styling |  |
| Data Fetching |   |
| Formatting |  |
| Package Manager |  |
| Version Control |   |
| Deployment |  |
main(=master): 오직 배포를 위한 브랜치 → 특별한 상황이 아니라면 배포만 진행develop: 작업한 내용을 취합하는 곳 (default branch)feat(=feature): 각 작업물을 분기해 새로 만들어 사용할 브랜치
-
Squash Merge사용 → PR 병합 시 커밋 이력을 하나로 합쳐, main/develop 브랜치 이력을 깔끔하게 유지합니다. -
병합 전
rebase필수 → 충돌이 발생하지 않도록 PR 전 반드시 최신 develop 브랜치 기준으로 rebase합니다.
git fetch origin
git rebase origin/develop
⚠️ Rebase 도중 충돌이 발생하면 직접 해결한 후git rebase --continue로 이어갑니다.
- 커밋 메시지는 의미 있는 단위로 작성, PR 제목도
커밋 컨벤션과 동일하게 정리합니다. - 리뷰 후 Merge 시점에는 커밋을 깔끔히 squash 한 뒤, 팀원 전원이 동일한 형식으로 PR 머지합니다.
Commit 메시지 종류 설명
| 제목 | 내용 |
|---|---|
init |
초기 세팅 (초기 이후는 setting 사용) |
setting |
패키지 설치, 개발 설정 |
feat |
새로운 기능 추가 / 퍼블리싱 |
fix |
버그 수정 |
style |
CSS 등 사용자 UI 디자인 변경 |
api |
API 연결 로직 작성 |
refactor |
프로덕션 코드 리팩토링 및 QA 반영 |
chore |
빌드 테스트 업데이트, 패키지 매니저 설정 (프로덕션 코드 변경 X) |
deploy |
배포 작업 |
comment |
필요한 주석 추가 및 변경 |
test |
테스트 추가, 테스트 리팩토링 (프로덕션 코드 변경 X) |
rename |
파일 또는 폴더 이름 수정 및 이동 작업 |
remove |
파일 삭제 작업만 수행 |
docs |
문서 수정 |
!HOTFIX |
급하게 치명적인 버그 수정 |
!BREAKING CHANGE |
커다란 API 변경 |
shared/아래 폴더는 전부 common(공통)의 의미로 생각한다.pages/아래 세부 폴더(components, constants 등등)가 각각 위치한다.
|-- 📁 .github
|-- 📁 node_modules
|-- 📁 public
|-- 📁 src
|-- 📁 pages
|-- 📁 home
|-- 📄ex) Home.tsx
|-- 📁 components
|-- 📁 styles 등
|-- 📁 shared
|-- 📁 components
|-- 📁 styles
|-- 📁 constants
|-- 📁 types 등
|-- index.html 등 ETC
- 컴포넌트 / class
PascalCase - 폴더명
소문자 - 파일 명 (컴포넌트 제외)
kebab-case - 변수, 함수
carmelCase - 파라미터
carmelCase - 상수
BIG_SNAKE_CASE
- interface는 필수로
PascalCase사용한다. - Props 타입 →
컴포넌트명+Props- 예시
interface PostPageProps { title: string | undefined; setTitle: (e: React.ChangeEvent<HTMLTextAreaElement>) => void; tempContent: string; editContent: string; setEditorContent: (content: string) => void; setContentWithoutTag: (content: string) => void; } const PostPage = (props: PostPageProps) => { const {title, setTitle, tempContent, editContent, setEditorContent, setContentWithoutTag ... }
- 예시
- 일반 타입 →
… + Types - PropsTypes는 컴포넌트 파일 내 / 그 외 타입은 pages/…/types 폴더에 따로 분리
컴포넌트 Wrapper 네이밍 규칙 :(미정)Wrapper→ (Layout)→Container→Box- semantic tag는 적극 활용한다.
- **
aria-label**도 적극적 활용!
- **
- SVG 파일 사용시
- svgr로 컴포넌트화 후 사용하므로 svg이름을 그대로 변환하여 사용한다.
-
이벤트 핸들러 네이밍
handle + 기능 + 이벤트- 예시
const handleBtnClick = () => {}; const handleTabChange = () => {};
→ props로 넘길 때 key값은
on + 이벤트- 예시
const BoxComponent = () => { return <memoComponent onClick={handleBtnClick} />; };
- 예시
-
유틸(utils) 함수 네이밍
동사(기능) + 명사(대상) -
값이 boolean일 경우는
is + 상태(default)- 예시
const [isLogined, setIsLogined] = useState(false);
→ 추가적으로
can / should / has정도를 상황에 맞게 추가한다. - 예시
-
api 함수
HTTP 메서드 + 명사- 예시
const getList = () => {}; const getMovie = () => {};
- 예시
-
네이밍 시 단수를 기본으로 사용하고 / 복수면 뒤에 List 키워드를 붙인다.
-
assets (Icon이나 Img)의 경우 피그마 네이밍을 적극 활용한다.
-
URL, HTML 같은 범용적인 대문자 약어는 대문자 그대로 사용한다.
-
변수/최대한 직관적으로 작성하여 네이밍을 보고도 무슨 데이터, 행위인지 바로 유추할 수 있도록 한다.
- 주석이 필요한 경우에는 어떤 역할을 하는지 다른 사람이 이해할 수 있도록 작성한다.
- 변수/함수 명은 20자 미만, 주석으로 변수 설명
-
주석은 작성하려고 하는 대상 바로 위에 작성
- var 금지.
const→let순서로 위부터 선언.- 변수를 조합하여 문자열 생성시 “+ “ 금지. → 리터럴 사용(백틱 ```)
- 변수명 : 의미를 확실히 나타낼 수 있도록
- 예시 : 배열에 Arr 보다는 변수s = fruits, userlists 등등
- 줄임말 쓰지말기. 이름이 길어지더라도 어떤 변수인지 정확하게
- 예시 : Btn X → Button으로 사용
- map 사용시 변동되는 리스트라면 key값을 고유하게 잘 설정해주기
index 사용 금지- 서버에서 내려주는 id값 or uuid 사용
- 전역 변수는 되도록 사용하지 않기
- 화살표 함수. function 키워드 쓰지말기
- 중복함수는 utils 폴더에 모아서 재사용한다.
- 변수/함수 명은 20자 미만.
- 최대한 네이밍에 의미를 담아서 작성하고 필요 시에 주석으로 설명 추가
- 필요하다면 early return 패턴을 적극적으로 활용
- 예시
**// early return 패턴** function processUser(user) { if (!user || !user.isActive) return; // **조건이 맞지 않으면 일찍 반환** // 나머지 처리 코드... }
- 예시
rafce→ 고정- 의미없는 div 또는 컴포넌트 최상단은 fragment 사용하기
const InfoText = () => {
return (
<>
<h1>Welcome!</h1>
<p>This our new page, we're glad you're are here!</p>
</>
);
};- children이 불필요할 땐 selfClosing사용하기
<Component/> - children 적극적으로 활용하기!
- object → interface
- 단일 변수 → type alias
- 컴포넌트 인자에 대한 타입은 컴포넌트 상단에
- 그 외의 타입들은 types 폴더에
- api response 타입명은 OOOResponseTypes
-
배열 복사 시 → 스프레드 연산자(…) 사용
const copys = […originals]
-
for 보단,
forEach/map을 사용 -
구조 분해 할당을 적극 이용
interface userDataProps { userName: string; userBirth: string; } function checkIsUser({ userName, userBirth }: userDataProps) {}
-
불필요한 반복문 지양 : filter, array.include() 등
- 조건부로 데이터를 확인하거나 뽑아야하는 로직을 사용할 때에는
Map이나Object처럼key값을 이용해서 원소를 찾는 자료형을 이용하는것을 고려해보거나, 배열을 순회하지 않고 index로 바로 접근할 수 있는 방법이 없는지 고려.
- 조건부로 데이터를 확인하거나 뽑아야하는 로직을 사용할 때에는
→ 추가 예정
-
button 태그에 **
type**은 명시적으로 작성 -
비교 연산자는 **
===**와 **!==**만을 사용 -
axios 안에서
then/catch대신async/await지향
- 팀원들의 코드는 곧 나의 코드라 생각하기
- 모르는건 적극적으로 질문하기
- 예민해지는 상황이 와도 항상 웃기
- 연락을 잘 보고, 빨리 답장하기
- 비대면으로 회의를 진행할때는 카메라 켜기
- 기록하면서 개발하기
- 트러블슈팅 공유하기
| 캘린더 | 작업 보드 |
|---|---|
|
- 주 단위로 목표를 세우고 매주 월요일 스크럼 진행
- 각자의 진행 상황 공유 및 주간 목표 재조정
- 주말마다 회고 진행
- 어떤 작업이 지연되었는지, 다음 주에는 무엇을 개선할지 논의
- 피그마, Notion을 활용한 일정 시각화
- 디자인/기능/배포 일정 한눈에 확인 가능하도록 관리
- PR 리뷰 마감 기한 설정
- 마감 일자는 여유롭게, 커뮤니케이션은 빠르게
- 실제 데드라인보다 하루 일찍 마감 기준으로 설정
- 예상보다 일찍 끝나면 다음 작업 빠르게 이어나감