[frontend] 협업 환경/컨벤션 정리

협업할 때 사용하고 있는 툴과 컨벤션을 문서로 정리해보았다.

 

✔️ 작업 환경 설정

코딩 스타일을 팀원과 같게 유지하기 위해 아래의 도구를 사용한다.

yarn

npm과 yarn은 모두 package.json 에 버전을 명시하고 의존성을 추적 관리하는 패키지 매니저이다. 이중 패키지 매니저는 yarn으로 통일한다. 이유는 다음과 같다.

• 여러 패키지를 설치할 때 npm은 순차적으로 설치되는 반면, yarn은 병렬로 처리돼 설치 시간 단축
• yarn은 npm과 달리 패키지를 중복으로 설치하는 경우가 없음

패키지를 설치할 때는 '개발용' 구분을 명확히 한다. 개발용일 경우 아래의 커맨드로 '개발의존성(Devdependencies)' 수준으로 추가한다.

yarn add -D[or --dev] [package_name]

 

Prettier

Prettier란 정해진 규칙에 따라 자동으로 코드 스타일을 정리 해주는 도구다. 아래와 같은 커맨드로 설치한다.

yarn add -D prettier

.prettierrc.js는 다음과 같이 통일한다.

module.exports = {
  semi: true,
  printWidth: 120,
  endOfLine: 'auto',
  singleQuote: true,
  useTabs: false,
  tabWidth: 2,
  trailingComma: 'all',
  arrowParens: 'always'
};

• semi: true - statement 마지막에 세미콜론을 찍음
• printWidth: 120 - 선호되는 한 줄의 길이
• endOfLine: 'auto' - 파일의 마지막에는 EOL을 보장
• singleQuote: true - 쌍따옴표가 아닌 홑따옴표를 사용
• useTabs: false - 탭을 사용하지 않고 스페이스를 사용
• tabWidth: 2 - 탭을 할 경우 2 스페이스
• trailingComma: 'all' - 여러줄로 나뉘었을 때는 쉼표를 사용
• arrowParens: 'always' - 화살표 함수에서 괄호 사용 의무화

➰ 더 많은 설정을 알고 싶다면 문서를 참고할 것.

 

ESlint

ESLint는 자바스크립트에서 문법적 에러를 표시해주는 도구이다. 아래와 같은 커맨드로 설치한다.

yarn add -D eslint

추가적인 설정을 위해 다음과 같은 플러그인을 추가로 설치한다.

yarn add -D eslint-plugin-import
yarn add -D eslint-config-airbnb-base
yarn add -D eslint-config-prettier eslint-plugin-prettier

• eslint-plugin-import: ES2015+의 import/export 구문을 지원
• eslint-config-airbnb-base: airbnb사의 코딩스타일
• eslint-config-prettier, eslint-plugin-prettier: 앞선 prettier를 ESLint와 연결하기 위한 플러그인

프로젝트의 .eslintrc 는 아래와 같이 통일한다.

module.exports = {
  env: {
    browser: true,
    es2021: true,
  },
  extends: ['airbnb-base', 'plugin:prettier/recommended'],
  parserOptions: {
    ecmaVersion: 12,
    sourceType: 'module',
  },
  rules: {
    'no-new': 'off',
    'no-console': 'off',
    'no-alert': 'off',
    'no-plusplus': 'error',
    'no-param-reassign': 'error',
    'no-underscore-dangle': 'off',
    'no-return-assign': 'error',
    'max-depth': ['error', 2],
    'max-lines-per-function': ['error', 15],
    'import/extensions': ['off'],
    'import/prefer-default-export': 'off',
    "no-restricted-syntax": ["error", "ForInStatement", "LabeledStatement", "WithStatement"]
  },
};

• env는 프로젝트의 사용 환경이다.
• parserOptions에는 자바스크립트 버전, 모듈 사용 여부 등을 설정할 수 있다.
• extends 부분에는 확장 설정을 넣어준다. airbnb사의 코딩 스타일을 따르며 prettier을 반영하도록 설정했다.
• rules에는 extends와 plugins에 대한 세부 설정을 변경하는 코드를 넣을 수 있다. 값을 0으로 주면 에러 검출을 하지 않고, 1로 주면 경고, 2로 주면 에러를 표시한다. 상세한 룰은 문서 에 담겨져 있다.

 

Lint-staged & husky

앞서 prettier과 ESLint를 열심히 설정해놓았지만, 급한 경우 이를 제대로 돌려보지도 않고 커밋해버리는 불상사가 발생한다. 설정해 놓은 의의와 달리 형식이 맞춰지지 않은 코드로 레포가 더럽혀진다. 이러한 일을 방지하기 위해 ESLint를 통과하지 못하면 커밋하지 못하도록 설정한다.

Lint-Staged 는 staged 단계에 있는 파일에서 lint를 확인해, lint:fix를 통과하지 않은 파일은 커밋하지 않게 도와준다. 전체 파일이 아닌 '변경사항'에 대해서만 lint 검사를 한다. 설치법은 다음과 같다.

yarn add -D lint-staged

Husky는 git hooks를 npm을 통해서 관리할 수 있게 도와주는 라이브러리다. 다음과 같이 설치한다.

yarn add -D husky

참고: 이 두가지는 git hooks를 바탕으로 이뤄진다. git에서 어떤 이벤트가 생겼을 때 우리가 원하는 스크립트를 끼워넣을 수 있도록 이벤트 사이에 갈고리를 걸어주는 것이 git hooks다. husky를 설치하지 않는다면 .git/hooks에 들어가서 스크립트를 작성해 사용할 수 있다. 이러한 방식으로 사용할 경우, 해당 파일은 git으로 기록되지 않아 따로 관리해야 한다는 단점이 있다. 또한 npm 기반의 명령어를 활용하기 어렵다.

설치한 Lint-Staged와 Husky를 package.json에서 설치한다. 사용하는 라이브러리와 언어에 따라 lint-staged를 적용할 소스파일의 확장자를 수정한다.

    "husky": {
        "hooks": {
            "pre-commit": "lint-staged"
        }
    },
    "lint-staged": {
        "*.{js,vue}": [
            "eslint --fix",
            "prettier --write",
            "git add"
        ]
    }

cypress(optional)

사용 여부는 기능 분석 단계, 즉 프로젝트 극초기에 결정한다. 다음과 같은 경우에 사용한다.

• 구현사항에 대한 테스트가 필요할 때: 기능이 다양한 상황에서 코드 수정 이후 기존의 기능이 정상적으로 작동하는지 확인한다.
• 팀의 협의로 TDD를 진행할 때: 이 경우 cypress에 테스트 케이스를 먼저 작성한 후 코드 개발을 시작한다.

아래와 같이 설치한다.

yarn add -D cypress

cypress/integration에 js 파일로 테스트 코드를 작성한다. cypress:open 을 커맨드라인에 입력하면, 테스트를 선택할 수 있는 GUI가 나타난다. 선택해 테스트를 진행한다. cypress 테스트 코드 작성에 있어서 구체적인 문법이 궁금한 경우 문서를 참고한다.

 

 

✔️ 개발 일정 및 리소스 배분

👩‍🏫 구현 기능 분석

개빌 일정과 리소스 배분은 '구현 기능'에 대한 분석이 이뤄진 뒤 진행한다.

1. 프로젝트 가장 상위 디렉토리에 REQUIREMENTS.md를 생성한다.
2. 과제에 필요한 요구사항을 분석, 기능별로 세분화해 앞서 생성한 문서에 기입한다.
3. 이때 기능은 핵심 기능과 이에 속하는 세부 기능으로 분류한다.
4. ex. 메인 페이지 구현: 핵심 기능 - 검색창 구현: 세부 기능
5. 분석한 기능을 진행 순서대로 나열한다.

 

⏰ 개발 일정

개발 일정은 '구현 기능'을 중심으로 수치화한다.

3. REQUIREMENTS.md 각 기능별로 소요 기간을 분석한다. 기간은 다음과 같은 세 가지 경우로 나눈다.
   A. Best: 오로지 해당 기능 구현에 시간을 쏟고 어떠한 돌발상황도 발생하지 않았을 때 예측되는 기능 구현 시간
   B. Normal: 일상적으로 흔히 나타나는 변수를 반영한 기능 구현 시간
   C. Worst: 예기치 않은 상황들이 겹친 최악의 상황에서 걸리는 기능 구현 시간으로 가장 보수적
4. 각 기능별 소요 기간을 합산해 전체 개발 일정을 산출한다. 전체 개발 일정 또한 세 가지 경우를 기술한다.
   A: Best: 모든 기능 구현이 순조롭게 이뤄지는 최고의 상황
   B: Normal: 일상적으로 흔히 나타나는 변수를 반영한 보통의 상황
   C: Worst: 예기치 않은 상황들이 겹친 최악의 상황
5. 이 중 Normal과 Worst 사이로 개발 기한을 설정한다. 즉 Normal의 기간에 약간의 버퍼를 더한다.
6. 핵심 기능 단위로 중간 점검일을 설정해, 일정대로 개발이 이뤄지고 있는지 확인한다.
7. 설정한 개발 기한에서 벗어나지 않을 것으로 예상되는 경우, 다음 중간 점검일을 자유롭게 조정할 수 있다.

 

📋 리소스 배분

리소스 배분 또한 '구현 기능'을 중심으로 진행한다. 배분 기준의 예시는 다음과 같다.

• 진행 순서에서 선순위 기능을 먼저 배분한다.
• 여럿이 프로젝트를 진행할 경우, 가급적 서로 독립적인 기능을 맡는다.
• 처음해보거나 구현해보기 복잡한 기능일 경우, 가능하다면 페어코딩한다.

 

 

✔️ 이슈 트레킹 및 협업 프로세스

🪡 이슈 트레킹

협업에 있어서 github의 기본 Issue 기능과 칸반보드 기능을 적극적으로 활용한다.

Issue로 맡은 기능 공유하기

• 맡은 기능 구현 / 버그 수정이 있을 경우 이슈를 생성한다.
• Assignees에 자신을 할당한다.
• Labels에는 상위 기능을 표기한다.
• 칸반보드와 연결하기 위해서 Projects에 진행 단계를 표기한다.

 

칸반보드로 전체 현황 공유하기

칸반보드의 예시는 위와 같다. 우리가 사용할 칸반보드의 분류는 다음과 같다.

• 신규 이슈: REQUIREMENTS.md에 명기된 세부 구현사항이나 아직 배정된 사람이 없는 경우 / 새롭게 구현해야할 사항 / 수정해야할 버그
• 진행 중: 신규 이슈에서 Assignees가 설정돼 담당자가 태스크를 수행하고 있는 경우
• 도움 요청: 담당자가 혼자의 힘으로 해결할 수 없어 도움을 요청하는 경우
• 이슈 종결: 유효하지 않은 이슈 / 머지돼 해결된 이슈

 

💾 커밋

커밋의 기준

커밋은 REQUIREMENTS.md에 기술된 '하나의 기능' 단위로 한다.

커밋 컨벤션

커밋 명령어는 다음과 같이한다. 괄호 안이 해당 명령어가 적용될 상황이다.

feat (feature)
fix (bug fix)
docs (documentation)
style (formatting, missing semi colons, …)
refactor
test (when adding missing tests)
chore (maintain) i.e. git, linter, code formater

참고: Angular Git Commit Message Conventions

 

👨‍🔧 풀리퀘스트

레포지토리에 코드를 반영하기 위해서는 풀리퀘스트를 필수적으로 진행해야 한다. 풀리퀘스트의 규칙은 다음과 같다.

• 풀리퀘스트는 포크를 통한 방식이 아닌 브랜치를 생성해 이뤄져야 한다.
• 브랜치의 이름은 구현할 기능의 이름으로 한다.
• 풀리퀘스트가 머지되기 위해서는 최소 1명 이상의 코드 리뷰를 통한 Approve가 필요하다.

🤝 협업툴

vscode liveshare

원격으로 페어코딩을 진행할 경우 사용한다. 아래 discord를 더해 음성 소통을 진행한다.

 

discord

소통채널은 디스코드로 한다. '소통'과 '아카이빙'이 주 목적이다. 각 채널의 역할은 다음과 같다.

• random: 주제 없이 어떤 얘기든 가능
• archive: 과제에 대한 아티클을 공유하며, 쓰레드를 올릴 때 추후 검색해보기 좋도록 #(해쉬태그)를 단다.
• meeting: 음성통화를 위한 채널

 

figma

figma는 협업 인터페이스 툴로, UI 설계를 공유하기 위해 사용한다. 팀프로젝트를 생성해 프론트엔드 코드를 작성하기 전 UI를 디자인한다.