팀으로 일하는 법 + 개발자의 기본기

Overview

요즘들어 기본기를 중요시 해라 라는 말을 많이 들었다. 볼링을 칠때 주변사람들한테, 기술 이사님한테, 운동을 배울때.. 벌써 3번이나 들었다. 그런데 이번 원티드 프리온보딩도 ‘개발자의 기본기’ 에 관한 세션이 있었다.

기본을 잘 알아야 어떤 것이든 잘 할수 있다 « 내가 내린 결론이다. 기본기가 없으면 결국은 무너지게 마련이며, 그 위에 쌓인 지식은 활용할 수 없는 것 같았기 때문이다. 이번 세션을 통해 보강한다는 의미로 블로깅을 하게 되었다. 다음단계로 갈려면 기반을 잘 다지고 가야겠다.

Git & GitHub 를 사용하면서 지켜야 할 것

Git & GitHub 정의

Git은 분산버전 관리 시스템
Github 은 Git 의 원격 저장소. 나만의 Git 을 다른사람과 공유 가능. ‘ 문서 & 협업 툴 ‘

⭐️Commit Message⭐️

다른 개발자의 코드를 분석할 때 이 코드가 어떤 목적을 가지고 언제 작성되었는가를 확인하기 위해 가장먼저 확인하는 것은 Git 의 Commit Message 다.
그렇기에 팀 내에서 일관된 커밋 메시지 규칙을 정하는 것은 필수적.
참고자료

Commit Message Guidelines

How to write Good Commit Messages: A Practical Git Guide

History 관리 및 브랜치 관리 전략

작업중일때는 원하는 만큼 커밋을 남기되, 최종적으로 브랜치의 작업이 완료되고 PR을 통해서 master(혹은 main) 에 머지요청을 하기 전 시점에 적절하게 원하는 형태로 커밋을 정리해주면 된다.
Git 에서는 squash 를 통해서 여러 커밋들을 하나로 합칠 수 있다.
squash 단독으로는 수행할 수 없다.
rebase 동작을 하면서 interactive 모드를 이용해서 squash 를 진행해준다.
참고자료 Git 스쿼시 커밋

ESLint , Prettier, Git Hook 을 이용한 팀의 능률 올리기

1. Lintter & Code Formatter

코딩스타일을 통일 시켜줌 -> 코드 작성 자체에 집중할 수 있음 !
Linter 는 ESLint
Code Formatter 로는 Prettier

2. ESLint

일관되고 버그를 피할수 있는 코드를 짜기 위해서 만들어진 코드 분석 툴
작성된 코드의 구문을 분석 -> 버그가 발생할 여지가 있거나, 불필요한 코드, 보안상 위험한 코드에 대해 경고해줌

3. Prettier

Code Formatting tool
룰을 커스터 마이징 가능 -> 팀원간의 룰을 정할 수 있음

4. 설치

eslint
- npm install eslint --save-dev
- CRA 의 경우 내장되어 있음.
prettier
- npm install prettier --save-dev
eslint-config-prettier
- eslint는 linting 기능, prettier 는 formatting을 담당하는 구조가 이상적
- eslint 에는 일부 formatting 관련된 rule도 포함됨
- 이러한 rule 이 prettier 와 다른설정을 가지고 있으면 설정충돌 발생
- 따라서 eslint 에서 formatting 관련 rule 들을 모두 해제해야할 필요가 있다 -> 수동으로 할수도 있지만 이를 적용해주는 eslint plugin 이 존재
- npm install eslint-config-prettier --save-dev

5. 설정

팀원들간의 규칙을 적용해보자

5-1. Prettier 설정

루트 디렉토리에 .prettierrc 파일을 통해 설정 가능.
설정파일의 확장자 형식은 다양하게 지원함 ( JSON, TAML, JS, TOML)
포맷팅에만 관련되어 있어서 비교적 설정 룰들이 간단한 편
참고자료 Options - Prettier

5-2. ESLint 설정

eslint 설정은 커스터마이징 할 수 있는 부분이 많다.
언어별(js, ts), 환경별 (web, node, react, next) 세팅 해줘야 함
다른사람이 정의해둔 config 를 설치한 후 확장해서 사용가능.
참고자료 Rules - EsLint Configuration Files - EsLint Plugins - EsLint

6. Husky

6-1. 왜 쓰는걸까?

위에서 우리는 prettier 와 eslint 를 설치하고 설정까지 다 했다. 근데 왜 또 husky 를 쓰는걸까? 단순히 설치만 한다고 자동으로 formatting 을 해주지 않는다. 명령어를 써야 해주는 것인데, 이거를 매번 사용자가 할거라는 보장이 없다. –> 자동화를 통해서 특정상황에 강제로 적용이 된다면? 휴먼에러가 없을 것임!

6-2. Git hook 도입

git hook 이란? Event 발생하기 전, 후로 특정 hook 동작을 실행하게 하는 것 (ex. commit, push)
근데 git hook 설정은 까다롭다. 모든 팀원들이 사전에 repo를 클론하고 메뉴얼하게 사전과정을 수행해야지만 hook 이 실행됨을 보장할 수 있음

6-3. Husky

Modern native git hooks made easy

git hook 설정을 도와주는 npm package
설정이 편함 + npm install 과정에서 사전에 세팅해둔 git hook을 다 적용시킬 수 있어서 모든 팀원이 git hook 실행이 되도록 하기가 편함
husky 를 통해서 pre-commit, pre-push hook 설정 가능

6-4. Husky 를 통한 Git Hook 적용

npm install husky --save-dev
(처음 세팅하는 사람만 실행 필요) npx husky install a. npx husky install : husky 에 등록된 hook 을 실제 .git 에 적용시키기 위한 스크립트 b. add postinstall script in package.json - 이후에 clone 받아서 사용하는 사람들은 npm install 후에 자동으로 husky install 이 될 수 있도록 하는 설정

  
// package.json

{
	"scripts": {
		"postinstall": "husky install"
	},
}

scripts 설정

  
// package.json

{
  "scripts": {
    "postinstall": "husky install",
		"format": "prettier --cache --write .",
		"lint": "eslint --cache .",
  },
}

add pre-commit, pre-push hook a. npx husky add .husky/pre-commit "npm run format" b. npx husky add .husky/pre-push "npm run lint"

6-5. 참고사항

git hook 에서 eslint 에러가 발견하면 실행중인 script가 종료되기에 이 rule 에 대해서 error 로 설정할 지 warn 으로 설정할 지 잘 고려해야함
- 예시)
  - 아래와 같이 되어있으면 console.log 코드가 있어도 푸쉬가 되지만
    - "no-console": ["warn", { "allow": ["warn", "error", "info"] }]
  - error 로 설정할 경우 console.log 가 하나라도 있으면 푸쉬가 안됨
    - "no-console": ["error", {"allow":["warn", "error", "info"] }]
- 참고사항)
  - 린트에서 warning도 엄격하게 하나도 허용하지 않으려면
  - eslint --max-warnings=0 으로 옵션을 붙여서 스크립트를 실행하면 됨

  
// package.json

{
  "scripts": {
    "lint": "eslint --cache --max-warnings=0"
  }
}

출처

원티드 프리온보딩

[기타] 팀으로 일하는 법 + 개발자의 기본기