협업툴
1. 버전관리
-
깃허브:
- 가장 대표적인 코드 호스팅 플랫폼
- 내장된 기능으론 프로젝트 코드 저장, 협업, 이슈 트래킹, pr, 코드 리뷰 등이 있다.
-
깃랩:
- 깃헙과 거의 유사하지만 자체 서버에 설치해서 사용하는 오픈소스 버전이 존재
- CI/CD 통합 기능이 잘 되어있어 자동화 빌드 및 배포가 가능
깃랩이 ui도 깃헙보다 괜찮고 팀원들의 코맨트를 봤을 때도 좀 더 직관적이다.
2. 커뮤니케이션
-
슬랙:
- 실시간 커뮤니케이션 도구이고 다양한 플러그인 연결 가능(깃헙, 지라, 피그마 등)
-
MS Tems:
-
회의 채팅을 위한 도구
-
오피스365와 통합이 되어있어 문서 공유와 협업에 유리
슬랙이 ui/ux 면에서 좋다고 느낀다.
3. 테스크 관리
-
지라:
- 애자일 방법론에 기반한 프로젝트 관리 도구
- 다양한 플러그인과 연동이 가능하여 대규모 프로젝트 관리에 적합
-
노션:
- 문서, 데이터베이스와 태스크 관리를 한 곳에서 할 수 있다.
지라를 통해 태스크 관리를 하고, 정리해야 할 문서는 컨플런스로 정리하면 깔끔할 것 깉다.
코드 리뷰의 중요성
-
장점:
1. 코드 품질 향상
다른 팀원들의 눈으로 보면 내가 확인하지 못한 이슈를 확인할 수 있다.
2. 지식 공유
팀원간의 지식 공유로 개발적 스킬을 향상
3. 코드 스타일 통일
공통된 코드 스타일과 컨벤션을 일관되게 통일 -
코드 리뷰 프로세스
- 기능 개발 완료 시 pr 생성
- pr에는 변경내용, 동작 작성
- 다른 팀원이 본인이 pr한 피드백 제공
- 피드백 수정 후 팀원들에게 리뷰 요청
- 피드백 해결 후 머지하고 기능 배포
브랜치 전략
간략하게 2가지가 있다.
1. 깃 플로우
- 대규모 프로젝트에 적합
- 브랜치를 마스터, 디벨롭, 피쳐, 릴리즈, 핫픽스로 나눠 관리
2. Trunk-based
- 소규모, 빠르게 돌아가야 하는 프로젝트에 적합
- 마스터 브랜치 위주로 작업
코딩 컨벤션 및 스타일 관리
리액트 협업 시 대표적인 컨벤션
리액트로 협업할 때의 대표적인 컨벤션은 코드의 일관성을 유지하고, 협업자가 쉽게 이해하고 작업을 이어나갈 수 있도록 돕는 것에 중점을 둔다. 다음은 리액트 협업에서 일반적으로 사용되는 컨벤션 종류이다:
1. 파일 및 폴더 구조
- 폴더 구조의 일관성: 프로젝트의 폴더 구조는 일관된 규칙을 따른다. 일반적으로 컴포넌트는
components폴더, 페이지는pages폴더에 위치시키고, 각 기능별로 모듈화를 진행한다. - 폴더 분리 기준: 기능별로 폴더를 분리하거나, 컴포넌트별로 폴더를 생성하여 재사용성과 유지보수를 높인다. 예를 들어, 컴포넌트 내에서 하위 컴포넌트가 셋 이상 필요하면
components라는 하위 폴더를 추가로 생성하는 식이다.
2. 컴포넌트 명명 규칙
- PascalCase 사용: 컴포넌트 파일 및 컴포넌트 이름은 대문자로 시작하는 PascalCase를 사용한다. 예:
UserProfile,MovieCard. - 폴더명과 파일명 일치: 폴더명이 컴포넌트 이름과 일치하도록 하여 검색과 탐색이 쉽게 만든다.
3. CSS 및 스타일링
- CSS-in-JS 사용 시 규칙 정하기: Styled Components, Emotion 등 CSS-in-JS 라이브러리를 사용하는 경우 스타일 파일의 위치와 네이밍 규칙을 정한다.
- 클래스명 작성 규칙: BEM(Block, Element, Modifier)과 같은 명명 규칙을 사용하여 CSS 클래스명을 작성한다.
- Global Style과 Component Style 구분: 전역 스타일은 일반적으로 별도의 파일에서 관리하고, 컴포넌트별로 필요한 스타일은 해당 컴포넌트 내에서 정의한다.
4. 상태 관리 (State Management)
- 일관된 상태 관리 도구 사용: 프로젝트 전반에서 Zustand, Redux, React Context 등 하나의 상태 관리 라이브러리를 일관되게 사용한다.
- 상태 위치 정의: 공통 상태는 상위 컴포넌트나 전역 상태로 관리하고, 컴포넌트 내부에서만 사용하는 상태는 로컬 상태로 관리한다.
5. Hooks 사용
- 커스텀 훅 사용: 반복되는 로직은 커스텀 훅으로 분리하여 재사용성을 높이고 코드 중복을 줄인다. 커스텀 훅은 보통
use로 시작하는 이름을 붙인다. 예:useFetchData,useMovieSort. - 훅의 순서 준수: 리액트의 훅 규칙을 준수하여 조건문이나 반복문 안에서 훅을 사용하지 않도록 한다.
6. 코드 스타일 및 포맷팅
- ESLint와 Prettier 설정: 일관된 코드 스타일을 유지하기 위해 ESLint와 Prettier를 사용한다. 팀원 모두 같은 설정을 사용하도록 프로젝트에
.eslintrc,.prettierrc파일을 추가한다. - JavaScript/TypeScript 규칙: 팀에서 사용하는 언어에 대한 명확한 코드 컨벤션을 설정한다. TypeScript를 사용할 경우 타입 정의와 관련된 규칙도 일관되게 적용한다.
7. 커밋 메시지 컨벤션
- Git 커밋 메시지 규칙: 짧고 명확하게 작성하며, 예를 들어
feat,fix,refactor등의 prefix를 사용하여 커밋 목적을 명확히 한다. - 브랜치 네이밍 규칙: 브랜치 이름도 일관되게 정하며, 주로 기능 추가(
feature/), 버그 수정(fix/), 리팩토링(refactor/) 등과 같은 접두어를 사용한다.
8. 타입 시스템
- PropTypes 또는 TypeScript 사용: PropTypes를 사용하거나 TypeScript로 컴포넌트의 props와 상태에 대한 타입을 명시하여 컴포넌트 간 데이터 전달을 명확히 한다.
9. 테스팅
- 테스트 파일 구조: 컴포넌트와 같은 위치에 테스트 파일을 두거나, 별도의
__tests__폴더에 두는 등 일관된 테스트 파일 구조를 설정한다. - 테스트 범위와 기준 정의: 유닛 테스트, 통합 테스트 등 각 테스트의 범위와 작성 기준을 설정하여 코드 품질을 유지한다.
이러한 컨벤션을 지키면 프로젝트의 코드 품질을 유지하고, 팀원 간 원활한 협업을 이끌어낼 수 있다.
기록하자