공통: 코드스테이츠_Project_준비

윤뿔소·2022년 12월 16일
0

프로젝트

목록 보기
2/4

프로젝트 시작을 위해 필요한 내용을 학습해보자!

Github

깃헙 레포지토리를 열고 기획 단계나 개발 단계 후 필요한 것들을 추가해보자

레포 열기

  1. 자신의 레포지토리에서 New 버튼 누르기
  2. 이름은 로컬 리포지토리 디렉토리 이름과 같게 설정
  3. 오픈소스가 아니라면 private
  4. owner가 자신의 아이디인지 재확인
  5. Add a README file: README.md 생성 할거야 말거야
  6. Add .gitignore: gitignore파일 생성 할거야 말거야
    • 근데 이건 편함 Java / Node.js 템플릿이 있어 자동으로 기입해줌
  7. Choose a license: 라이센스 파일을 생성할 수 있음
    • private은 코드 공개가 아예 안돼 필요 x
    • 근데 오픈소스의 경우 제약이 적은 MIT 라이센스나 Apache License등을 적용하여 많은 개발자가 쉽게 코드를 사용하고 기여할 수 있도록 함

README.md

레포에 꼭 필요한 파일, 생성했으면 꼭 넣어야할 내용들을 기입하자.

  • 프로젝트 이름
  • 프로젝트 핵심 기능 소개
  • 팀원 소개
  • Wiki로 링크

예시

# My Todo App

Todo 관리를 위한 웹 애플리케이션입니다.

## Features

- 편리한 UI로 Todo를 쉽게 생성하고 삭제할 수 있습니다.
- Todo에 기한과 카테고리를 설정할 수 있습니다.
- create-react-app으로 간편한 번들링과 배포가 가능합니다.
- Spring Boot로 쉽게 서버 배포를 할 수 있습니다.

## Contributors

- FE: 김코딩, 박해커
- BE: 나서버, 최디비

## Project Wiki

프로젝트 팀 정보, 기획, 아키텍쳐에 대한 자세한 안내입니다.
(링크)

FE 프레임워크 선택 및 설치

필수

  • Node.js: 브라우저가 아닌 다양한 환경에서 동작하는 JS 런타임
    • 백엔드(서버) 개발
  • Node.js 패키지 매니저
    • npm, yarn 선택
  • 버전 관리 시스템 / 형상 관리 시스템 + 원격 리포지토리 서비스
    • Git, Github
  • 프론트엔드 프레임워크(라이브러리)
    • 리액트-CRA: 번들링이나 배포, 테스트를 위한 기본 설정이 모두 되어있음
    • 스벨트, 뷰 등 선택
  • CSS
    • CSS 네이밍 컨벤션
      • BEM
      • Utility-First (Tailwind, Bootstrap)
    • CSS 프레임워크(라이브러리), 관리 방법
      • CSS-in-JS 라이브러리를 사용하여 컴포넌트로 묶어 관리: Styled-Component, Emotion
      • Utility-First CSS: Tailwind CSS, Bootstrap
      • CSS 파일 따로 관리
      • SASS 사용
      • UI 프레임워크 사용: Material UI, Chakra UI, Radix UI(간편하지만 CSS 학습을 충분히 한 뒤에 사용)
  • 린터: 문법 에러나 코드 스타일 규칙에 맞지 않는 코드를 찾아주는 툴
    • eslint, prettier

선택

꼭 쓰지 않아도 되지만 통일하여 FE 개발자간 1개만 사용!

  • HTTP 요청: API 요청/응답 처리
    • Fetch API & isomorphic-fetch
    • Axios
    • React Query (TanStack Query)
    • SWR
  • 상태 관리: props-drilling 문제 및 상태의 효율적인 관리
    • Redux(toolkit)
    • Recoil
    • Zustand
  • TypeScript: 정적 타입 언어처럼 사용할 수 있게 변수나 함수의 리턴값에 타입을 지정
    • TypeScript는 초기 설정도 어렵고 학습에도 시간이 오래 걸려 충분한 학습과 협의 必
  • 번들러
    • webpack
    • esbuild
    • vite
    • parcel
  • 테스트 프레임워크
    • Jest, React Testing Library
    • Cypress

참고: BE

Firebase, AWS + github actions 등 배포와 express.js, next.js 등의 서버 개발도 선택하자 혼자면

시작

나는 보통 FE이고, CRA로 개발을 시작한다.

npx create-react-app {원하는 디렉터리 경로}

그다음 선택한 프레임워크/라이브러리들 중 설치할 것들을 설치하자. 나는 보통 리덕스 툴킷과 스타일컴포넌트를 사용한다.

npm install @reduxjs/toolkit react-redux
npm install --save styled-components
...

그다음 린터도 많이 사용한다. eslint, prettier 두개 다 설정하고, VSC 확장프로그램도 2개 다 깔자. 좋다!

npm install -D eslint-plugin-import eslint-plugin-jsx-a11y eslint-plugin-react eslint-plugin-react-hooks eslint-plugin-prettier eslint-config-prettier

나는 학원에서 배웠던 것처럼 .eslintrc.json , .prettierrc.json에 설정을 적용할 것이다. 팀원이 있다면 팀원과 협의해서 맞춰야겠지?

# .eslintrc.json
{
  "settings": {
    "import/resolver": {
      "node": {
        "extensions": [".js", ".jsx", ".ts", ".tsx"]
      }
    }
  },
  "env": {
    "browser": true,
    "es2021": true
  },
  "extends": [
    "eslint:recommended",
    "plugin:react/recommended",
    "plugin:import/recommended",
    "plugin:jsx-a11y/recommended"
  ],
  "parserOptions": {
    "ecmaFeatures": {
      "jsx": true
    },
    "ecmaVersion": "latest",
    "sourceType": "module"
  },
  "rules": {
    "react/react-in-jsx-scope": 0,
    "react/jsx-uses-react": 0
  }
}
# .prettierrc.json
{
  "singleQuote": true
}

이렇게 하면 FE 세팅은 거의 끝났다. 자신만의 방법으로 더 추가해보자

프로젝트 관리

기본적인 세팅은 끝났으니 스케쥴 관리나 나중에 열어보더라도 어디까지 했는지 알 수 있는 칸반 보드를 통한 시각화와 브랜치를 각 이름에 맞게 나눠 분리를 해보자!

칸반

다양한 칸반 툴들이 있다. 깃헙, Jira, 네이버웍스 등등

팀과 조직이 작업을 시각화하고, 업무의 병목 현상리소스 낭비 해결하는 업무 관리 방법

또한 칸반에서는 각 업무 단계에 Work In Progress(WIP) 제한을 둘 수 있음, 왜냐면 100% 리소스를 활용하던 도중 추가되면 업무가 과부하되어서 업무 효율이 떨어지기에 직무 처리 속도가 느려진다. 신호등 같은 존재!

애자일 방법론을 이용하면서 매일매일 스프린트하고, 데일리 스크럼을 통해 목표를 정하는데 칸반은 그와 함께 쓰이는 실용적인 방법이다! 이거 좋은듯?
쨌든, 칸반을 잘 활용하기 위해서는 정책을 설정해야 한다.

  1. 칸반의 열을 정의하고 WIP limit을 세우는 것
  2. 언제 회의를 하고 어떻게 의사결정을 할지 명확한 정책을 수립
  3. 정책 수립 시에는 팀원이 모두 모여서 합의를 이뤄야 함
  4. 합의한 정책은 향후 업무 진행 상황에 따라서 팀원들이 모여서 언제든지 다시 조정 가능

또한 프로젝트가 본격적으로 시작하기 전에 정하면 좋을 정책은 아래와 같다.

  • 회의 시간 및 해당 회의에서 논의할 내용
  • 팀원 간 소통 원칙
  • 칸반 티켓을 언제, 어떻게, 누가 추가할지
  • WIP 제한

칸반 회의 원칙

데일리, 주간 보충

칸반을 사용한다면 보통 데일리 칸반 회의와 주간 보충 회의를 진행한다.

데일리 칸반 회의는 업무의 상태 및 흐름을 관찰하고 추적한다. 어떻게 하면 구현하고자 하는 기능을 좀 더 빠르게 구현할 수 있을지, 업무가 끝난 인원이 다른 업무를 당겨올 수 있는지 등을 정할 수 있다.
예를 들면, 프론트엔드 개발자 A가 게시판 CRUD 사용자 인터페이스를 모두 다 구현해서 시간이 충분한 경우, 백로그에 있는 다른 프론트엔드 작업을 가져와서 하거나, WIP에 있는 다른 프론트엔드 개발자 B의 업무를 도와 집중하여 끝낼 수 있게 돕는다던지의 의사결정을 할 수 있다.

주간 보충 회의에서는, 칸반 보드에 추가할 만한 업무가 있는지 확인하고, 다음 주에는 어떤 업무를 할 것인지 정할 수 있다.
예를 들면, 프로젝트 진행 상황이 매우 원활하여, 추가로 구현하기로 했던 기능을 구현할 수 있게 된 경우에는 주간 보충 회의를 통해 해당 기능 구현 티켓을 칸반 보드에 추가할 수 있다.

추가로 격주, 혹은 월간으로 KPT 회고를 진행할 수도 있는데, 지금까지의 진행 상황에 대해서 솔직하게 회고하고, 어떻게 하면 좀 더 잘할 수 있을지 개선점을 찾을 수 있다.

실천법

  • 업무 시각화
  • 진행 중인 업무 제한
  • 흐름 관리
  • 명확한 프로세스 정책
  • 피드백 루프 구현
  • 협력적인 개선, 실험적인 발전

이렇게 실천해서 원칙을 지키는 것이 중요하다.

원칙

  1. 하던 업무를 칸반 보드에 올려두는 것부터 시작
  2. 점진적인 변화를 추구
    • 칸반을 위해서 갑작스럽게 업무 방식을 극적으로 변화X
    • 업무 내용이나 방향성을 유지
  3. 직위에 관계 없이 리더십을 발휘
    • 충분히 제안하고 의견을 나눌 수 있음
    • 각 팀원도 WIP 제한 조절, 새 업무 티켓 발행 등 수행 必

깃허브의 칸반

깃헙의 Issue(task card), mildstone, project 등을 이용해서 스케쥴을 짤 수 있다. 위에 배웠던 칸반형식이다.

전체적인 칸반 설정 로직

1. Issue에서 태스크 작성하기

  1. 이슈 템플릿(setting-General-Get organized with issue templates)을 설정한 뒤 작성
  2. 작성한 뒤 오른쪽 속성 설정하기
    • Assigness: 해당 태스크를 맡은 사람을 지정해주시면 됨. assign yourself를 누르면 자신의 태스크로 만들 수 있음
    • Labels: 태스크 카드에 라벨링 설정
    • Projects: Projects를 지정
    • Milestone: Milestone을 지정

2. Github 마일스톤 작성하기

여러 이슈들을 묶거나 하나의 이슈가 너무 커지면 마일스톤으로 분리하는 식으로 작성

  • Issue 탭에서 milestones 카테고리에서 읽고 작성
    여기에선 하나의 마일스톤을 여러 이슈로 쪼갰음

3. Github Project(칸반)

지금까지 생성한 Github 이슈와 마일스톤을 칸반으로 쉽게 관리할 수 있다.

  1. Projects 탭에서 맨 아래를 눌러 새 프로젝트 생성
  2. 설정하기
    1. 이름 변경
    2. Manage Access해서 읽기, 쓰기, 관리자 권한 조정
    3. 팀원 초대도 가능!
  3. 작성하기
    • Issue연결하기: # 으로 자신의 레포지토리를 찾고 Add multiple items로 모두 불러오기
    • 각 이슈들의 상태(Todo, In Progress, Done 등), 칼럼(Labels, PR, Reviewers, Repository, Milestone), Assignees등 설정 가능
    • 마지막으로 레포지토리와 Issue, milestones 각각 연결됐는지 확인
  4. 보기 설정
    • Table, BoardGroup으로 그룹핑 하여 볼 수 있음

정리

이런 식으로 여러번 스프린트를 1주로 나눠 실행하고 토론하고 스크럼하고 그렇게 한다.

브랜치

브랜칭, 기존 개발중인 메인 개발 코드를 그대로 복사하여 새로운 기능 개발을 메인 개발 코드를 건드리지 않고 할 수 있는 버전 관리 기법

다양한 브랜칭 전략이 있기에 자신이 놓여진, 기업의 개발 방향과 문화에 따라 브랜치도 다양해진다.

브랜칭 전략

효율적인 개발 프로젝트 코드 관리를 위해 브랜치의 종류를 나눠서 관리하는 전략

Git flow, Github flow, Gitlab flow, Coz’ Git flow 등이 있다. 난 Coz’ Git flow를 썼어서 거기에 대한 방법론을 서술하겠다.

Coz’ Git flow

핵심 브랜치로 main, dev 브랜치가 있다.

main 브랜치

사용자에게 언제든 제품으로 출시할 수 있는 브랜치

회사에 따라서 master, prod, production등 다양하게 불린다. “언제든 배포할 수 있다"의 의미는 회사 별로, 팀 별로 다를 수 있다만, 최소한의 기준을 세워볼 수 있다.

  • 대표적인 기능이 완성되었다.
  • 기존 기획했던 레이아웃이나 전체적인 디자인이 얼추 완성되었다.
  • 클라이언트, 서버, 데이터베이스가 공개된 웹에서 정상적으로 통신할 수 있다.
  • 최소한의 보안이 마련되었다.
    • 브라우저에서 개발 버전에서 사용하던 secret이나 유저의 비밀번호가 노출되는가?
    • 유저의 기밀 정보 조회를 위해 인증 토큰, 세션이 꼭 필요한가?

이렇게 기준을 일정 충족했고 바로 배포할 수 있다면 main의 자격을 얻는다.

dev 브랜치

다음 버전 배포를 위한 "개발 중!"인 브랜치

main 브랜치에서부터 브랜칭을 하는게 보통이며, 가능하면 프로젝트 전반의 결과를 확인 가능하게! CI/CD 파이프라인이 잘 구축되어 있다면 dev 브랜치의 코드도 배포를 해두고 수시로 확인할 수도 있다.

main 브랜치와 dev 브랜치는 Github 리포지토리에 늘 업데이트 돼있어야하고, 팀원의 코드 리뷰를 받고 진행하는 것이 정석이다. 엄밀한 코드 리뷰가 어렵다면, 같이 모여서 코드에 대해서 이야기를 나누고, 배포 상황을 점검하는 스텐드업 회의를 열어도 좋다. 가능하면 모든 팀원이 확인 가능하게 “어떤 코드의 어디를 왜 이렇게 바꿨으면 좋겠다.”라는 코멘트를 Github Pull Request에 남기는 것을 권장한다! 나중에 딴말 없기!

팁: Approval 기능 추가

그래서 브랜치에 PR을 날리면 몇명 이상의 승인을 받아야 머지하게 만드는 정책도 세울 수 있다.

여기서 Add해서 Require a pull request before merging를 가고 Require approvals 메뉴에서 인원을 정할 수 있다.

Branch name pattern에는 기본적인 브랜치 네임을 입력하는데 만약 feat/todo 브랜치가 있다면 저기에 feat/*하고 *를 붙인다면 저걸로 시작하는 브랜치는 정책에 모두 해당되게 할 수 있다! 개꿀팁!

보조 브랜치: feat

기능 개발, 리펙토링, 문서 작업, 단순 오류 수정 등 다양한 작업을 기록하기 위한 브랜치

보통 여기서 커밋 메세지도 prefix와 같이 지정한다. 참고

feature 브랜치는 기능 개발을 위한 브랜치이기 때문에 2명 이상 같이 작업하는 경우가 드물어서, 브랜치 생성이나 삭제에 대해서 너무 두려워 할 필요는 없다. 자주 커밋해서 코드리뷰를 자주 받는 것도 중요.
또 회사에 따라서 커밋 기록을 남기는 일반적인 rebase-and-merge, 기능마다 깔끔하게 커밋을 남기기를 원해서 커밋 기록을 정리하는 squash-and-merge등 다양한 merge 전략이 있다. 잘 선택해보자

브랜치 설정 및 사용법

설정

둘 중 하나 골라서 명령하자. switch는 최근에 나온 개념으로 checkout은 다용도로 쓰기에 기능을 분해하여 나온게 switch다.

# feature라는 브랜치를 새로 생성하는 경우, -c를 붙임
git switch -c feature
# checkout이라는 명령어도 사용할 수 있음
git checkout -b feature

# 기존에 있던 main 브랜치로 HEAD를 변경하려면, -c를 붙이지 않음
git switch main
git checkout main

사용법

변경 내역을 확인할 수 있는 PR을 통한 Merge가 좋기에 직접 머지하는 git merge보다 git push해서 PR하자!

# 기능 개발이 진행
git commit -m "기능1의 세부 기능1"
git commit -m "기능1의 세부 기능2"
git commit -m "기능1 개발 완료"
# Github 리포지토리로 푸시.
git push origin feat/todo
# Github에서 Pull Request하기.

예시

만약 머지를 하고 기능 개발도 끝난 feat/~브랜치가 남아있다면 삭제토록 하자!

참고 내용

깃 대처하기

이런 순서로 프로젝트 진행

  1. 사용자 요구사항 정의서
  2. 통신 테스트(api 통신 되는지)
  3. 업무 분장
  4. Github 설정
  5. 칸반보드 관리
  6. 이슈 담당자 배치 및 마감일 지정
profile
코뿔소처럼 저돌적으로

0개의 댓글