[CryptoMeter] 프로젝트 사전 준비

토깽이연구소 수석연구원·2023년 5월 14일
Codeit
0

CryptoMeter

목록 보기
2/6
post-thumbnail

저번 투두리스트에서 다소 원활하지 못했던 협업과정을 이번 크립토미터에서는 제대로 준비하고 들어가기로 했다. 최대한 현업과 유사한 환경을 만들기 위하여 디테일한 컨벤션부터 명확한 역할 분담을 하고, 정기적으로 회의를 하기로 했다. 이 모든 과정을 깃허브 위키와 깃허브 프로젝트, issue, 팀 노션에 기록하였다.

GitHub

CryptoMeter GitHub
CryptoMeter 위키

🌇 Cryptometer Project

1️⃣ Ground Rule

  1. 회의는 화(오프라인), 금(온라인)에 1시간씩 진행한다.
  2. 회의 시간을 지킵니다.
  3. 코드 리뷰는 24시간 내에 반드시 합니다.
  4. 컨벤션을 잘 지킵니다.
  5. 프로젝트 관련 논의 내용은 즉석에서 오프라인으로 이루어지더라도 반드시 “문서화” 합니다.
  6. 매일 스크럼 시간(오전 10시)에 칸반보드를 최신화 합니다.

2️⃣ Branching strategy & Work Flow

Work Flow

  1. Guthub 레포지토리 접속 https://github.com/codeit-bootcamp-frontend/0-crypto-meter-technokings
  2. 이슈 생성

Frame 29

  1. 이슈 번호 확인 (브랜치명에 필요)

Frame 30

  1. 브랜치 생성후 작업

    1. 현재 repo를 fork 딴다.
    2. 그럼 현재 repo가 upstream repo, 본인 repo에 있는 fork repo가 origin repo가 된다.
    3. fork한 origin repo를 로컬에 clone한 뒤
    4. dev 브랜치를 기준으로 feature 브랜치 등을 분기해서 작업을 끝내고 git push origin feature 후에
      • dev 브랜치를 기준으로 git switch -c feature/delete_irrelevants/#3 후에 git push origin feature/delete_irrelevants/#3
    5. origin feature 브랜치에서 바로 upstream dev로 PR 날린다. (개인 feature => 공용 dev로 PR)
    6. 코드리뷰를 받았다면,
    7. upstream repo의 dev와 origin repo의 dev 브랜치 싱크를 맞춰줘야 한다 (혹은 origin dev 브랜치에서 git pull upstream dev)

    4-1. 브랜치 생성후 작업(보다 자세한 설명)

    a. 개인 로컬 dev브랜치를 공용 dev브랜치와 sync

    b. 개인 로컬 dev(hotfix의 경우 로컬 main)브랜치에서 작업할 새 브랜치 생성

    git branch refactor/delete_irrelevants/#3
    git checkout(or switch) refactor/delete_irrelevants/#3
    OR
    git checkout -b refactor/delete_irrelevants/#3
    OR
    git switch -c refactor/delete_irrelevants/#3

    c. 작업 완료 후 push

    git push origin refactor/delete_irrelevants/#3

  2. PR날리기

작업한 브랜치 → 공용 레포의 dev 또는 main 브랜치

브랜칭 전략과 컨벤션

  1. main 브랜치: 프로덕션 브랜치(여기에 push하면 netlify의 CI/CD가 실행됨)
  2. dev브랜치: 버그 픽스가 아닌 모든 작업(꼭 새로운 기능이 아니라도 리팩토링, dev 브랜치 버그 픽스 등) + dev 브랜치도 netlify에 배포한다(개발모드)
  3. hotfix브랜치: 버그 픽스 브랜치, 현재 main브랜치에 있는 버그들을 바로 고치고 merge하는 hotfix 브랜치 역할

이렇게 3개의 브랜치로 운영한다. 당장은 dev 브랜치에서 모든 작업을 하므로, hotfix 브랜치를 쓸 일이 없지만, 이후 프로젝트가 끝나고 지속적인 유지/보수를 위해 일단 3개의 브랜치를 운영하는 것으로 한다. 현업처럼 release브랜치까지 나눠서 관리하기엔 규모가 작고 인원도 작아 오히려 유지보수하는데 어려울 것 같아서 과감하게 조금 더 가벼운 브랜치 전략으로 선택했다.

Work Branch Naming Rules

  • <category>/<description>/<issue-ref> 순으로 이름을 짓기로 한다.
    1. category: feature, bug, refactor로 구분
    2. description: 간략한 설명(너무 상세할 필요 X), kebab-case로 작성한다.
    3. issue-ref: 이슈번호
  • 예를 들어
    예시1) refactor/remove-unused-variables/#1✅ 리팩토링 작업 중 불필요한 변수를 제거하는 작업을 진행한 브랜치이고, 대응하는 이슈번호는 1번이다. 예시2)`bug/register-form-not-working/#3` ✅ 회원가입 폼 관련 버그(dev브랜치에서 발견된 버그)를 고치는 작업을 진행한 브랜치이고, 대응하는 이슈번호는 3번이다. 예시3)`feature/hover-text/#4` ✅ 호버 텍스트 기능을 구현하기 위한 작업을 진행한 브랜치이고, 대응하는 이슈 번호는 4번이다.

Merging Rules

⭐️⭐️ 작업 전후로 반드시 해야하는 upstream-fork sync 과정 ⭐️⭐️
image 6

  • 핵심은 공용 dev와 개인 dev를 항상 같은 상태로 유지시키는 것입니다.
  • 수시로 sync해줌으로써 conflict를 최소화할 수 있습니다.
  • 다음의 과정을 작업 전후로 항상 진행하는 것을 원칙으로 합니다.
    image 5
  1. 새로운 기능을 개발하는 경우 (개인 작업 브랜치 → dev로 머지)
    1. 깃허브에서 관련 내용의 이슈를 생성합니다.
    2. dev 브랜치에서 feature/hover-text/#4 와 같은 이름의 새 브랜치를 만듭니다.
    3. 새 브랜치에서 작업한 뒤, 리모트에 push합니다.
    4. dev 브랜치로 merge하는 PR을 생성합니다.
    5. 코드리뷰와 머지가 완료되면 이슈를 close하고 작업한 브랜치를 삭제합니다.
  2. main브랜치에서 발견한 버그를 고치는 경우 (공용 hotfix 브랜치 → main으로 머지)
    1. 깃허브에서 관련 내용의 이슈를 생성합니다.
    2. hotfix 브랜치로 이동한후, 새 브랜치를 만들 필요 없이 버그 수정 작업을 진행합니다.
    3. 작업이 완료되면 리모트로 push후, main으로 merge하는 PR을 생성합니다.
    4. 코드리뷰와 머지가 완료되면 이슈를 close합니다.
  3. 리팩토링 작업이 필요한 경우 (개인 작업 브랜치 → dev로 머지)
    1. 깃허브에서 관련 내용의 이슈를 생성합니다.
    2. dev브랜치에서 refactor/remove-unused-variables/#5와 같은 이름의 새 브랜치를 만듭니다.
    3. 새 브랜치에서 작업한 뒤, 리모트에 push합니다.
    4. dev 브랜치로 merge하는 PR을 생성합니다.
    5. 코드리뷰와 머지가 완료되면 이슈를 close하고 작업한 브랜치를 삭제합니다.
  4. dev 브랜치에서 발견한 버그를 고치는 경우 (개인 작업 브랜치 → dev로 머지)
    1. 깃허브에서 관련 내용의 이슈를 생성합니다.
    2. dev브랜치에서 bug/register-form-not-working/#7와 같은 이름의 새 브랜치를 만듭니다.
    3. 새 브랜치에서 작업한 뒤, 리모트에 push합니다.
    4. dev 브랜치로 merge하는 PR을 생성합니다.
    5. 코드리뷰와 머지가 완료되면 이슈를 close하고 작업한 브랜치를 삭제합니다.
  5. dev에서 의미 있는 기능 묶음들이 정상적으로 동작할 때(새 버전 릴리즈) (dev → main 으로 머지)
    1. 깃허브에서 관련 내용의 이슈를 생성합니다. (또는 release 생성)
    2. dev 브랜치에서 main 브랜치로 merge하는 PR을 생성합니다.
    3. 리뷰가 완료되면 merge합니다. (dev → main)
    4. hotfix 브랜치 최신화를 위해 main → hotfix merge도 해줍니다.

🚨 Merging Rules 주의
main으로 머지하는 경우는 hotfix, 새 버전 출시 말고는 없습니다.

PR Rules

리뷰어가 코드리뷰가 끝나면 Approve 마지막에 리뷰한 리뷰어가 Merge하도록 합니다.
리뷰어가 바로 Approve하지 않고 변경사항을 Request하는 경우 해당 PR을 올린 Assignee가 코드를 수정한 뒤 리뷰를 재요청하도록 합니다.

3️⃣ Convention & Rules

네이밍 컨벤션

변수

case

  • 일반변수: camelCase
  • 상수: SCREAM_SNAKE_CASE

convention

  • 명사로 작성한다.
  • 예외) boolean 변수는 is~ has~ includes~ 등의 현재형 동사로 시작한다.

함수

case

  • camelCase

convention

  • 현재형 동사 + 명사로 작성한다.
  • 핸들러함수: handle~로 시작한다.

컴포넌트

case

  • PascalCase

convention

  • 두 단어 이상의 조합으로 작성한다.
LoginPage.tsx
HomeButton.tsx
  • Styled Component: S~로 시작한다.
export const Sdiv = styled.`
// ...
margin-top: ${({mgt}) => mgt ?? '0'};
${({ct}) => css`display: flex; justify-content: center, align-items: center`};
// ....

파일

case

  • 컴포넌트: PascalCase.jsx
  • 일반 파일 : 전부 소문자로 작성한다. 단어와 단어 사이는 dot으로 구분한다.
axios.instance.js

폴더

case

  • 컴포넌트, 페이지 폴더: PascalCase
  • 일반 폴더: 소문자, 복수형, kebab-case (예: components, pages, hooks, …)

폴더 구조

	
 ├─ src/
 │  ├─ assets/
 │  │  └─ favicon.svg
 │  ├─ components/
 │  │  ├─ ToggleButton
 │  │  │  └─ ToggleButton.js
 │  │  ├─ FilterChip
 │  │  │  └─ FilterChip.js
 │  │  └─ index.js
 │  ├─ (contexts)
 │  ├─ data/
 │  ├─ services/
 │  ├─ styles/
 │  │  ├─ colors.js
 │  │  └─ styled.components.js
 │  ├─ utils/
 │  ├─ App.css
 │  ├─ App.jsx
 │  └─ main.jsx
  • assets: 이미지, 폰트 등
  • components: 컴포넌트
  • data: 정적인 고유 데이터 (mock.json, maps 등)
  • services: api 관련 기능들
  • styles: 공용 스타일 관련 폴더
  • utils: 공용 유틸리티 함수들
  • Main.jsx: 엔트리포인트
  • App.jsx: 메인 앱
  • App.css: 메인 앱 스타일 (reset 포함)

커밋 컨벤션

  • feat: 새로운 기능(기능 구현)
  • fix: 버그 수정
  • docs: documentation 변경
  • style: 코드 의미에 영향을 주지 않는, 코드 스타일에 관련된 변경 사항(포맷, 공백, 빼먹은 세미콜론, 함수 이름 변경, 줄간격, 파일 이름, 의미없는 주석 삭제)
  • refactor: 리팩토링에 대한 커밋(버그를 수정하지 않고 기능을 추가하지 않는 코드 변경)
  • chore: 패키지 매니저 설정할 경우, 코드 수정 없이 설정을 변경(eslint, prettier…패키지 설정), 이외에도 특정 영역에 들어가기 애매한 잡다한 작업들
EmojiCategoryDescription
🎉initStart a project.
✨featIntroduce new features.
✏️fixFix typos.
🐛fixFix a bug.
📝docsAdd or update documentation.
🎨styleImprove structure / format of the code.
♻️refactorRefactor code.
🔥choreRemove code or files.
💩poopWrite bad code.
🚚choreMove or rename resources
🍱choreAdd or update assets.
🔖feat/fixRelease / Version tags.
✨: 회원가입 기능 개발
🐛: 회원가입 시 사용자 이름이 안보이는 버그 수정

gitmoji 설치 및 작성 방법

> npm i -g gitmoji-cli # 글로벌 주의 
# or
> brew install gitmoji

git add . # (add 할 것들 스테이징에 올리고) 
gitmoji -c # 입력해서 이모티콘 선택하고 
#커밋 타이틀, 커밋 메시지 입력하고
git push ... #로 origin 브랜치에 넣기

코딩 컨벤션

  • 화살표 함수를 사용합니다.
  • if else 문 사용을 지양하고 early return 패턴을 사용합니다.
  • 스타일드 컴포넌트는 컴포넌트 하단에 작성합니다.
    • 이를 위해 .eslintrc의 rule에 "no-use-before-define": "off", 를 추가합니다
  • 조건부 렌더링 패턴
    • undefined 배열 처리 패턴: 가독성을 위해 옵셔널 체이닝을 사용합니다.
      array?.map(()=>{})
    • 양자 택일 렌더링 패턴: else를 최대한 지양하고, 코드의 의미 전달을 높일 수 있게 early return 패턴을 사용합니다.
      if (condition)
	return <ThisComponent />
return <ThatComponent />
    • 부분 조건부 렌더링 패턴:
      • 옵션이 2개 일 때는 삼항 연산자를 사용합니다.
      • 옵션이 3개 이상일 때는 object mapping을 사용합니다.
      • default value가 필요한 경우 nullish coallescing 문법을 사용합니다.
      <span>{title ?? "default"}</span> // 값이 없는 상황에 default 값을 보여줄 때
 <span>{isIncreased ? "going up!" : "going down hard.."}</span> // boolean일 때
 <span>{messageMap[message]}</span>  // object mapping 사용
  • 비동기 함수를 사용할 때는 콜백 헬 방지를 위해 async/await를 사용합니다.
  • import 경로
    • 절대경로를 사용합니다.
    • aliasing을 사용하여 src, components 등의 큰 폴더 경로의 별칭을 설정하여 사용합니다.
  • 컴포넌트안에서 props 객체는 구조분해 할당하여 사용합니다.
  • 커스텀 훅은 배열이 아닌 객체를 반환하도록 합니다.
  • eslint 설정
    • airbnb extends를 사용합니다.
    • import문은 외부 모듈과 내부 모듈로 분리합니다.
  • prettier 설정
    // .prettierrc
{
  "singleQuote": false,
  "semi": true,
  "useTabs": false,
  "tabWidth": 2,
  "printWidth": 80,
	"bracketSpacing": true,
  "arrowParens": "always"
}
  • CSS문 작성 규칙: 다음의 스타일 정의 순서를 지켜 가독성을 높이고 수정을 용이하게 합니다.
    const SInput = styled.input`
 /* 레이아웃 */
 display: ..
 visibility: ..
 ..
 /* Box model */
 width: ..
 height:..
 ..
 /* 폰트 */
 font: ..
 color: ..
 ..
 /* 기타 속성 */
 ..
`;
- 레이아웃 : display, visibility, overflow, float, clear, position, top, right, bottom, left, z-index
- BOX : width, height, margin, padding, border
- 폰트 : font, color, letter-spacing, text-align, text-decoration, text-indent, vertical-align, white-space
  • String concatenation은 +연산자 대신 템플릿 리터럴을 사용합니다.
    w + "px" // X
`${w}px` // O
  • 컴포넌트는 재사용성과 범용성을 위해 최대한 dumb하게 유지합니다.
    • 컴포넌트 외부 스타일에 영향을 미치지 않습니다(전체 마진 등)
    • 컴포넌트 안에서 api 호출을 하지 않습니다(app.js에서 호출)
  • Semantic 태그 사용을 지향합니다.
  • State로부터 파생된 state를 사용하는 경우, 원활한 동기화를 위해 reference를 사용합니다.
    const [coins, setCoins] = useState([
      {id: 1, name: "Bitcoin",},
      {id: 2, name: "Dogecoin",},
    ]);    
    // 파생된 값을 가진 상태(X)
    const [selectedCoin, setSelectedCoins] = useState({...});
    // 파생된 reference를 가진 상태 (○)
    const [selectedCoinId, setSelectedCoinId] = useState(2);
    ```

4️⃣ Tech Stack & Libraries

기술 스택

Language

  • Javascript
  • HTML5
  • CSS3

Framework

  • React v18

State Management

  • Zustand

CSS

  • styled components

Utils

  • react-date-picker
  • recharts

Ajax

  • axios

라이브러리 선정 기준

공통 선정 기준
1. 대중적으로 사용되어 학습 자료가 많고 기술 습득이 쉬운가
2. 커스텀화가 가능한가

Chart

CSS

  • styled-components
    • js 문법을 사용하여 props등의 자바스크립트 변수를 사용할 수 있어 생산성이 높아진다.
    • props를 적극 활용하여 디자인 시스템과 비슷한 환경을 구축할 수 있다.

상태관리 툴

  • Zustand
    • recoil과 유사한 수준의 쉬운 난이도를 자랑한다.
    • redux 다음으로 사용자가 많아 참고자료가 많다.

협업 툴

  • GitHub
    • 브랜치 관리, 백보드를 통한 task 상황 관리(Projects), 회의록 작성(Wiki) 등 다양한 기능을 사용할 수 있다.
    • 위 기능을 한 플랫폼으로 통합하여 협업의 능률을 높일 수 있다.

AJAX

  • Axios
    • 커스텀 인스턴스를 만들어 추상화 및 서비스에 맞는 요청과 응답 세팅이 용이하다.
    • 사용방법이 직관적이라 팀 프로젝트에 적합하다.

5️⃣ R & R

Chores

@케니

  • Netlify 배포 관리
  • README 업데이트
  • 노션, 슬랙 문서 관리
  • 슬랙 관리(운영질문, 학습질문, 프로젝트 관련 질문 담당)

@헨리

  • GitHub 위키
  • 공용 레포
  • GitHub 프로젝트(칸반보드, 로드맵)
  • 노션 내 프로젝트 때 새로 알게 된 것들(혹은 이건 뭐지 싶은 것들) 모음집 문서 관리 담당

@이안

  • 회의록 작성 및 업로드
  • 모든 질문 담당 (운영, 학습, 프로젝트 관련, 멘토링 등 질문 담당)

Development

1. 컴포넌트 스켈레톤 제작

  • 스타일 @케니
    • 디자인 시스템
    • 마이크로 컴포넌트 제작
    • 전역 스타일 지정
  • 인터페이스 설계 @헨리
    • mock.json
    • 각 컴포넌트 별 상태, prop 등 지정
  • 공통 컴포넌트 제작 @이안
  • 기타 정적인 컴포넌트 제작(차트 칸 기본 컴포넌트 등) @이안

2. 페이지 구성

  • 컴포넌트 조립
  • 반응형 레이아웃
    • 스타일
    • 추가 컴포넌트 (ex. 모달)
  • 애니메이션

3. 기능 구현

  • API
  • 페이지네이션
  • SNS 공유 링크
  • 전역 상태 관리
  • 차트

4. 테스트 및 배포

  • dev 서버 운영
    • 지속적인 테스팅
    • 버그 리포팅

6️⃣ 요구사항 분석

요구사항

  1. 사용자는 어떤 코인을 언제 얼마나(금액 기준으로) 샀는지 설정할 수 있다.
    1. 구매한 금액을 직접 입력할 수 있다.
    2. 구매한 날짜를 선택할 수 있다.
    3. 구매한 코인을 선택할 수 있다.
    4. 구매한 금액을 chip(5000원, 10000원 등)을 통해 설정할 수 있다.
  2. 사용자는 전체 코인의 현재 현황을 테이블로 확인할 수 있다.
    1. 보여지는 컬럼
      1. 화폐 이름(로고포함)
      2. 변동 폭
      3. 거래량
      4. 총 시가
      5. 현재가
    2. 테이블을 컬럼별로 정렬할 수 있다.
  3. 사용자는 선택한 코인의 정보를 차트로 확인할 수 있다.
    1. 기간별 차트를 선택할 수 있다. (일봉, 주봉, 월봉, 1년, 전체)
    2. 마우스로 차트상 특정 시점을 갖다대면 당시 날짜와 가격을 확인기능
  4. 사용자는 선택한 코인 정보를 SNS로 공유할 수 있다.
  5. 사용자는 한 번 계산된 과거와 현재 시세 차이를 다시 계산할 수 있다.
  6. 사용자는 기준이 되는 화폐 단위를 바꿀 수 있다.
  7. 사용자는 본인의 계산 기록을 확인할 수 있다.
    1. 계산 기록을 모두 지울 수 있다.

컴포넌트 구상

smart/dumb component architecture strategy (비즈니스 로직과 뷰 로직을 분리)

  • dumb(스타일 ⇒ 스타일드 컴포넌트 조합해서) smart(로직)

컴포넌트의 로직과 스타일을 분리시켜 효율적인 디버깅 및 수정을 가능하게 합니다.

export const HistoryButton = () =>{
// 로직을 통해 prop를 만들어
	const handleClickSearchRecord = ()=>{...};
	const containerProps = { onClick: handleClickSearchRecord,  };
	return (
		<ButtonContainer {...containerProps}/>	
	)
}
export const ButtonContainer = ({onClick, isDown?})=>{
	return (
		<SDiv pdt={40} ct onClick={onClick}>
			...
			<SText>{isDown ? "down" : "up"}</SText>
		</SDiv>
	);
}

7️⃣ Schedule Plan

컴포넌트 스켈레톤 제작(~5/16)

  • 스타일링
  • 인터페이스 설계
  • 공통 컴포넌트 제작
  • 기타 정적 컴포넌트 제작

페이지 구성(~5/19)

  • 컴포넌트 조립
  • 반응형
    • 스타일
    • 추가 컴포넌트 (ex, 모달)
  • 애니메이션

기능 구현(~5/23)

  • API
  • 페이지네이션
  • SNS 공유 링크
  • 전역 상태 관리
  • 차트
profile
토깽이연구소 수석연구원
Let's get after it
이전 포스트

[CryptoMeter] Project Intro

다음 포스트

[CryptoMeter] 스타일 시스템 구축하기

0개의 댓글