JavaScript의 프로젝트 환경

Node.js 기반의 JavaScript 개발 환경으로 범위를 좁혀 팀으로 함께 일할 때 어떻게 협업하고 개발하는지 예제 프로젝트를 통해 살펴봅니다.

https://barnraisersllc.com/2017/10/surprising-facts-collaboration-workplace/

프로그래밍은 다양한 문제를 해결할 수 있는 한 가지 방법입니다. 하지만 해결해야 하는 문제가 크고 복잡해지면서 혼자 소프트웨어를 만들며 프로그래밍으로 문제를 해결하기는 불가능합니다.

소프트웨어를 완성하려면 팀이 함께 일해야 합니다. 팀이 함께 일할 때에는 여기저기 흩어져 있는 복잡한 문제를 단순하게 정리하고 지속적으로 유용하게 관리할 수 있는 협업 공간이 필요하고, 개발 환경도 되도록 동일하게 유지해야 합니다.

이 글에서는 Node.js 기반의 JavaScript 개발 환경으로 범위를 좁혀 팀으로 함께 일할 때 어떻게 협업하고 개발하는지 예제 프로젝트를 통해 간략하게 살펴봅니다.

Git과 GitHub를 활용한 협업 공간으로 개발 시작하기

소프트웨어를 팀과 함께 완성하려면 여기저기 흩어져 있는 복잡한 문제를 단순하게 정리하고 지속적으로 유용하게 관리할 수 있는 협업 공간을 먼저 준비하는 것이 좋다. Git은 소규모 프로젝트부터 대규모 프로젝트에 이르기까지 소스 코드의 버전 관리를 신속하고 효율적으로 처리할 수 있게 설계된 도구이다. 협업하는 과정에서 발생하는 대부분의 문제는 Git을 통해 해결할 수 있다. GitHub 는 손쉽게 Git의 원격 저장소를 생성하고 관리할 수 있는 기능을 제공하며, 이슈와 pull request를 중심으로 요구 사항을 관리하고 코드 리뷰를 효과적으로 할 수 있는 기능을 제공한다.

Git 저장소 만들기

다음은 Git 명령어로 로컬에 Git 저장소(repository)를 만드는 예이다. 이 글에서는 awesome-javascript 라는 이름으로 Git 저장소를 만들어 사용하겠다.

$ mkdir awesome-javascript
$ cd awesome-javascript
$ git init
Initialized empty Git repository in /Users/user/github/awesome-javascript/.git/

Git을 설치하고 사용하는 방법은 이 글에서 설명하지 않는다. Git과 Git 사용 방법에 관한 자세한 내용은 “ Pro Git”을 참고한다.

GitHub의 계정에 같은 이름의 새로운 저장소를 생성한 뒤 다음과 같이 git remote 명령어로 원격 저장소를 추가한다.

이 글에서는 https://github.com/stunstunstun/awesome-javascript 경로를 원격 저장소로 사용한다.

$ git remote add origin https://github.com/stunstunstun/awesome-javascript
$ git remote -v
origin https://github.com/stunstunstun/awesome-javascript (fetch) origin https://github.com/stunstunstun/awesome-javascript (push)

GitHub에서 저장소를 생성하는 방법은 이 글에서 설명하지 않는다. GitHub 사용 방법에 관한 자세한 내용은 GitHub 도움말 을 참고한다.

GitHub에 이슈 등록하기

코드를 작성하기에 앞서 요구 사항이나 해결해야 하는 문제를 명확하게 정의하는 것이 좋다. GitHub의 이슈 관리 기능을 활용하면 협업하는 동료에게 쉽게 공유될 뿐만 아니라 기록이 남아 짧게는 며칠에서 길게는 1년 후에도 참고할 수 있는 좋은 기록이 된다.

GitHub 저장소의 Issues 탭에서 New issue를 클릭하면 다음 예 와 같이 새로운 이슈를 작성할 수 있다.

GitHub에서는 이슈와 pull request 요청에 작성하는 글의 형식을 템플릿으로 관리할 수 있다. 이슈와 pull request는 자주 사용하기 때문에 템플릿 기능을 활용하기를 추천한다. 템플릿은 마크다운 형식으로 작성한다.

템플릿을 생성하고 적용하는 더 자세한 방법은 “ Manually creating a single issue template for your repository” 문서와 “ Creating a pull request template for your repository” 문서를 참고한다.

Node.js와 Yarn으로 개발 환경 설정하기

JavaScript는 브라우저에서 바로 작동하는 코드로 사용되기 시작했지만 현재는 더욱 복잡한 애플리케이션을 개발하는 데에도 사용된다. JavaScirpt로 애플리케이션을 개발할 때에는 Git을 통한 협업 환경뿐만 아니라 코드 검증과 테스트, 빌드, 배포 등의 과정에서 만나는 문제를 해결할 수 있는 개발 환경도 설정해야 한다.

JavaScirpt 개발 환경을 설정할 때에는 Node.js와 npm, Yarn, webpack, Lerna 등 다양한 도구를 활용할 수 있다. 이 글에서는 Node.js와 npm, Yarn으로 JavaScript 개발 환경을 설정하는 방법을 살펴보겠다.

Node.js와 npm, Yarn

Node.js와 npm은 JavaScript가 거대한 오픈소스 생태계를 확보하는 데 결정적인 역할을 했다. Google이 만든 JavaScirpt 엔진인 V8 로 빌드된 Node.js는 JavaScript가 브라우저 이외의 환경에서도 작동하게 만드는 JavsScript 런타임 환경이다.

Node.js를 설치하면 포함되는 npm은 패키지의 저장소뿐 아니라 프로젝트에 npm 패키지를 추가하는 등 다양한 명령을 제공하는 패키지 관리 도구이다.

Yarn은 Facebook이 개발한 패키지 매니저다. 점점 거대해지는 프로젝트에서 npm을 사용하며 일관성, 보안, 빌드 시 성능 등에 문제를 겪은 Facebook은 npm을 대체할 새로운 패키지 관리 도구인 Yarn을 개발했다. 이 글에서도 프로젝트의 생성과 관리에 Yarn을 사용할 것이다.

Node.js와 Yarn 설치

프로젝트를 생성하는 Yarn 명령어는 yarn init 이다. 아직 Node.js와 npm, Yarn이 설치되지 않았다면 다음과 같은 오류 메시지가 출력된다.

$ yarn init
bash: yarn: command not found

Node.js와 npm은 다음과 같이 Node.js 버전 관리 도구인 nvm 으로 설치한다. 이 글에서는 2019년 4월을 기준으로 최신 LTS(long term support release, 장기 지원 버전) 버전인 Node.js 10.15.3(npm 6.4.1 포함)을 설치했다.

$ curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.8/install.sh | bash
$ nvm install 10.15.3
$ node -v && npm -v
v10.15.3 6.4.1

Node.js와 npm이 설치되면 npm 명령어를 사용해 Yarn을 전역으로 설치한다.

$ npm install yarn -g

프로젝트 생성

Yarn 설치가 완료되면 yarn init 명령어를 실행한다. 프로젝트의 기본 정보를 입력하면 새로운 프로젝트가 생성된다.

$ yarn init
yarn init v1.12.3 question name (awesome-javascript): question version (1.0.0): ... 
success Saved package.json
✨ Done in 5.68s.

package.json 파일과 패키지 관리

프로젝트가 생성되면 프로젝트의 최상위 폴더에 다음 예와 같은 내용의 package.json 파일이 생성된다.

{
    "name": "awesome-javascript",
    "version": "1.0.0",
    "main": "index.js",
    "repository": "https://github.com/stunstunstun/awesome-javascript",
    "author": "stunstunstun",
    "license": "MIT"
}

package.json 파일은 프로젝트에 관한 모든 정보를 담고 있는 파일이다. package.json 파일에서 가장 중요한 속성인 dependencies 속성은 프로젝트와 패키지 간의 의존성을 관리하는 속성이다. Yarn의 CLI 명령어로 패키지를 설치하면 package.json 파일의 dependencies 속성이 자동으로 변경된다.

다음은 HTTP 요청을 위해 node-fetch 모듈을 yarn add 명령어로 설치하는 예이다.

$ yarn add node-fetch

node-fetch 모듈이 설치되면 package.json 파일의 내용이 다음과 같이 변경된다.

{
    ...
    "main": "index.js",
    "dependencies": {
        "node-fetch": "^2.3.0"
    },
    ...
    "license": "MIT"
}

dependencies 속성의 ^2.3.0 은 이 프로젝트에서 사용하는 node-fetch 모듈의 버전이 2.3.0 이상이고 3.0.0 미만이라는 의미이다. 새로운 node-fetch 모듈의 버전이 이 범위에 해당하면 프로젝트에 설치된 node-fetch 모듈이 자동으로 업그레이드된다.

캐럿(^)으로 버전 범위를 표기하면 Semantic Versioning의 규약을 신뢰한다는 가정하에서 패키지를 관리한다. 마이너 버전과 패치 버전 은 하위 호환성이 보장되므로 새로운 버전으로 업그레이드해도 된다. 즉, 다음 표와 같이 1.x 버전의 마이너 버전과 패치 버전이 모두 설치된다.

버전 범위를 물결표(~)로 표기했다면 프로젝트에서 사용하는 패키지의 버전이 X.Y.Z와 같은 버전의 마지막 자리인 Z 에 해당하는 버전이라는 의미이다.

예를 들어 ~2.3.0 으로 버전 범위를 표기했다면 프로젝트에 설치된 패키지의 버전은 2.3.0 이상이고 2.4.0 미만이어야 한다. node-fetch 2.3.1이 새롭게 릴리스되었다면 node-fetch 2.3.1이 자동으로 설치된다.

물결표 표기보다는 하위 호환성을 보장할 수 있는 캐럿 표기를 사용하기를 추천한다.

패키지의 버전 범위 표기와 관련된 더 자세한 내용은 “ Outsider’s Dev Story, npm package.json에서 틸드(~) 대신 캐럿(^) 사용하기” 문서와 “ npm-package.json — Specifics of npm’s package.json handling” 문서의 ‘ dependencies’ 항목을 참고한다.

yarn.lock 파일과 패키지 일관성

애플리케이션을 개발하는 도중이나 애플리케이션을 배포할 때 프로젝트에서 사용하는 패키지가 업데이트될 수 있다. 또한 협업하는 동료의 로컬 시스템이나 개발 시스템마다 다른 버전의 패키지가 설치될 수도 있다.

Yarn은 모든 시스템에서 패키지 버전을 일관되게 관리하기 위해 yarn.lock 파일을 프로젝트의 최상위 폴더에 자동으로 생성한다. 사용자는 이 파일을 직접 수정해서는 안 되며 CLI 명령어를 사용해 관리해야 한다.

다음은 node-fetch 모듈을 설치한 다음 자동으로 생성된 yarn.lock 파일의 예이다.

# THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY.
# yarn lockfile v1
node-fetch@^2.3.0: version "2.3.0" resolved "https://registry.yarnpkg.com/node-fetch/-/node-fetch-2.3.0.tgz#1a1d940bbfb916a1d3e0219f037e89e71f8c5fa5" integrity sha512-MOd8pV3fxENbryESLgVIeaGKrdl+uaYhCSSVkjeOb/31/njTpcis5aWfdqgNlHIrKOLRbMnfPINPOML2CIFeXA==
...

프로젝트 공유

Node.js와 Yarn을 사용해 생성한 JavaScript 프로젝트는 Git의 원격 저장소에 반영해야 협업하는 동료와 공유할 수 있다. 프로젝트에 생성된 package.json 파일과 yarn.lock 파일도 원격 저장소에서 관리해야 많은 사람과 애플리케이션을 안정적으로 운영할 수 있다.

프로젝트를 원격 저장소에 공유할 때 모듈이 설치되는 node_modules 폴더는 제외한다. 폴더의 용량이 클 뿐만 아니라 yarn.lock 파일을 통해 동기화되기 때문에 Git 저장소에서 관리할 필요가 없다. 다음과 같이 node_modules 폴더를 .gitignore 파일에 추가해 Git 관리 대상에서 제외한다.

$ echo "node_modules/" > .gitignore

다음은 이슈 해결과 관련된 브랜치를 생성하고 프로젝트를 GitHub의 저장소에 푸시하는 예이다.

$ git add .
$ git checkout -b issue/1
$ git commit -m 'Create project with Yarn'
$ git push -u origin issue/1

원격 저장소인 GitHub 저장소에 issue/1 브랜치가 푸시되면 pull request를 생성한다. pull request는 작성한 코드를 master 브랜치에 병합하기 위해 협업하는 동료들에게 코드 리뷰를 요청하는 작업이다. GitHub 저장소의 Pull requests 탭에서 New pull request 버튼을 클릭해 pull request를 생성할 수 있다.

pull request를 생성할 때에는 다음 예와 같이 리뷰를 하는 사람에게 충분한 정보를 제공해야 한다. 새로운 기능을 추가했다면 기능을 사용하기 위한 재현 시나리오와 테스트 시나리오를 추가하는 것이 좋다. 개발 환경이 변경되었다면 변경된 내역을 반드시 포함해야 한다.

• pull request 작성 예: https://github.com/stunstunstun/awesome-javascript/pull/2

README.md 파일 활용

pull request를 생성해 공유하는 프로젝트는 CI(continuous integration) 서버와 협업하는 동료의 로컬 시스템을 포함한 다른 개발 관련 시스템에서도 작동되어야 한다. pull request에 프로젝트 환경을 구축하는 방법을 설명할 수도 있지만 항상 반복하는 내용은 README.md 파일에 작성해 공유하는 것이 좋다. 다음은 이 글에서 사용한 README.md 파일의 예이다.

• README.md 파일 작성 예: https://github.com/stunstunstun/awesome-javascript/blob/master/README.md

Jest로 테스트 환경 설정하기

지금까지 협업 공간과 개발 환경을 구축하고 JavaScript 프로젝트를 생성해 GitHub에 공유했지만 아직 의미 있는 구현 코드를 작성하지 않았고 코드를 검증하는 테스트 환경도 설정하지 않았다.

GitHub의 REST API v3을 사용해 특정 GitHub 사용자의 정보를 가져오는 코드를 작성하면서 테스트 환경을 어떻게 설정하는지 살펴보겠다. 이 글에서는 JavaScript 테스트 도구로 널리 사용하는 Jest 를 테스트 도구로 사용한다.

테스트 코드 작성

구현 코드를 작성하기 전에 구현하려는 기능의 의도를 테스트 코드로 먼저 표현해 본다.

다음은 테스트 코드를 저장할 폴더(__tests__)와 구현 코드를 저장할 폴더( lib), 테스트 코드( github.test.js)를 생성하는 예이다.

$ mkdir __tests__ lib
$ touch __tests__/github.test.js

Jest의 문서를 참조해 github.test.js 파일에 다음과 같이 테스트 코드를 작성했다. GitHub에서 ‘stunstunstun’ 계정의 사용자 정보를 가져왔는지 확인하는 코드다.

Jest 설치

일반적으로 Yarn에서 테스트 코드를 실행하는 명령어는 yarn test 이다. 아직 Jest가 설치되지 않았다면 다음과 같은 오류 메시지가 출력된다.

$ yarn test
yarn run v1.12.3
error Command "test" not found.

다음과 같이 Yarn 명령어로 Jest를 설치한다.

$ yarn add jest --dev

Jest 설치가 끝나면 package.json 파일을 수정해 테스트를 위한 명령을 scripts 속성에 설정한다.

{
    "scripts": {
        "test": "jest"
    },
    "dependencies": {
        "axios": "^0.18.0"
    },
    "devDependencies": {
        "jest": "^23.6.0"
    },
}

테스트를 위한 패키지를 설치할 때 설치 명령어에 --dev 옵션을 추가하면 devDependencies 속성에 패키지를 추가한다. --dev 옵션으로 설치된 패키지는 애플리케이션이 실행되는 런타임 환경에는 영향을 미치지 않는다.

구현 코드 작성

Jest의 설치가 완료되었다면 다시 테스트를 실행한다. 아직 구현 코드가 없어 테스트가 실패하고 ../lib/github 모듈을 찾을 수 없다는 오류 메시지가 반환된다.

$ yarn test
FAIL __tests__ / github.test.js
● Test suite failed to run
Cannot find module '../lib/github'
from 'github.test.js'
>
    1 |
    const GitHub = require('../lib/github')

구현 코드( lib/github.js)를 작성한다.

$ touch lib/github.js

다음은 github.js 파일에 작성한 구현 코드의 예이다.

const fetch = require('node-fetch')
class GitHub {
    constructor({
        accessToken,
        baseURL
    }) {
        this.accessToken = accessToken
        this.baseURL = baseURL
    }
async getUser(username) {
        return fetch(`${this.baseURL}/users/${username}`, {
            method: 'GET',
            headers: {
                Authorization: `token ${this.accessToken}`,
                'Content-Type': 'application/json',
            },
        }).then(res => res.json())
    }
}
module.exports = GitHub

테스트를 통한 구현 코드 수정

테스트를 실행했지만 다시 테스트가 실패했다.

$ yarn test
FAIL __tests__ / github.test.js
Integration with GitHub API
✕ Get a user(731 ms)
● Integration with GitHub API› Get a user
expect(received).toEqual(expected)
Expected value to equal:
    ObjectContaining {
        "login": "stunstunstun"
    }
Received: {
    "documentation_url": "https://developer.github.com/v3",
    "message": "Bad credentials"
}

API 요청 시 다음과 같은 Bad credentials 오류가 발생한 이유는 테스트 코드에서 GitHub 객체를 생성할 때 process.env.ACCESS_TOKEN의 값이 undefined 이기 때문이다.

HTTP / 1.1 401 Unauthorized {
    "message": "Bad credentials",
    "documentation_url": "https://developer.github.com/v3"
}

process.env.ACCESS_TOKEN의 값이 없다면 HTTP 요청 전에 예외를 발생하도록 다음과 같이 github.js 파일을 수정했다.

class GitHub {
    ...
    async getUser(username) {
        if (!this.accessToken) {
            throw new Error('accessToken is required.')
        }
        return fetch(`${this.baseURL}/users/${username}`, {
            method: 'GET',
            headers: {
                Authorization: `token ${this.accessToken}`,
                'Content-Type': 'application/json',
            },
        }).then(res => res.json())
    }
}

또다시 테스트가 실패했지만 반환되는 오류 메시지로 실패 원인을 파악할 수 있게 되었다.

$ yarn test
FAIL __tests__/github.test.js
Integration with GitHub API
✕ Get a user (8ms)
● Integration with GitHub API › Get a user accessToken is required.

다음과 같이 테스트 코드에서 참조하고 있는 시스템의 환경 변수에 GitHub의 token 값을 추가하고 다시 테스트를 실행한다. 구현 코드가 원하는 방식으로 작동하고 테스트가 성공했다.

$ ACCESS_TOKEN=cc3ff9c5b84a40889faf3331082885edc54b6801 yarn test
PASS __tests__/github.test.js Integration with GitHub API
✓ Get a user (206ms)
Test Suites: 1 passed, 1 total
Tests: 1 passed, 1 total
Snapshots: 0 total Time: 1.771s,
estimated 2s Ran all test suites.
✨ Done in 3.09s.

테스트 환경 공유

테스트 코드와 구현 코드 작성이 완료되면 README.md 파일에 테스트 관련 정보를 추가한다.

• README.md 파일 예 : https://github.com/stunstunstun/awesome-javascript#test

테스트 환경을 공유할 수 있게 변경된 내용을 GitHub에 반영한다.

$ git add .
$ git commit -m 'Configure testing environments with Jest'
$ git push -u origin issue/1

Travis CI를 활용해 리뷰 환경 개선하기

동료와 협업해 애플리케이션을 개발하는 과정은 pull request를 생성해 공유한 코드를 리뷰하고 함께 개선하는 과정이라고 볼 수도 있다. 위에서 공유한 코드를 리뷰한 리뷰어가 지적한 다음과 같은 문제를 해결하면서 더 효율적으로 프로젝트를 리뷰하는 방법을 살펴보겠다.

README.md를 참고해 테스트 명령을 실행했지만 실패한다.

리뷰어가 지적한 문제는 구현 코드를 작성한 로컬 환경에서는 테스트 케이스에 정의된 테스트가 성공했지만 다른 환경에서는 실패해서 일어난 문제이다. 테스트 케이스에 정의된 테스트를 실행하는 일은 애플리케이션을 개발하는 과정에서 반복되는 작업이다. 이런 반복 작업은 리뷰어가 매번 실행하게 하는 것보다 CI 도구가 자동으로 실행하게 하는 것이 좋다.

Travis CI를 활용한 테스트 자동화

GitHub의 CI 연동 기능을 사용하면 CI 도구의 빌드 프로세스에 정의한 작업이 성공해야 master 브랜치에 소스 코드가 병합되도록 제약 조건을 추가할 수 있다. 저장소의 Settings 탭에서 Branches를 클릭한 다음 Branch protection rules 에서 이 기능을 설정할 수 있다.

대표적인 CI 도구는 Jenkins이지만 Jenkins로 CI 서버를 구축하고 운영하는 것은 비용이 드는 일이다. 이 글에서는 간편하게 사용할 수 있는 CI 도구인 Travis CI 를 연동해 활용하겠다.

이 글에서는 GitHub와 Travis CI를 연동하는 자세한 방법은 설명하지 않는다. Travis CI 연동 방법과 사용 방법에 관해서는 “ Travis CI Tutorial” 문서를 참고한다.

Travis CI에는 다음과 같은 작업을 위임한다. 리뷰어는 Travis CI의 검증 결과와 테스트 결과를 신뢰해야 한다.

• ESLint를 통한 코드 컨벤션 검증
• Jest를 통한 테스트 자동화

Travis CI의 연동과 설정이 완료되면 pull request를 요청한 소스 코드가 Travis CI를 거치도록 다음과 같이 GitHub 저장소의 Branch protection rules 항목을 설정한다.

위에서 작성한 구현 코드와 테스트 코드로 pull request를 요청하면 Travis CI 서버에서 자동으로 테스트를 실행한다.

애플리케이션의 설정 정보 관리

Travis CI와 연동하고 테스트를 자동으로 실행했지만 테스트 결과는 다음과 같이 실패로 나타난다.

애플리케이션 실행에 필요한 환경 변수인 ACCESS_TOKEN 의 값이 전달되지 않았기 때문이다.

프로젝트의 설정 정보를 환경변수에서 벗어나 관리할 수 없을까?

애플리케이션 실행에 필요한 정보를 환경 변수로 관리할 수 있지만 Git 저장소에서 설정 정보를 관리하고 값의 유효성을 검증하는 것이 더 좋다. 단, 보안 문제로 Git 저장소에서 공유될 수 없는 정보가 있다면 다른 해결 방법을 고민해야 할 수도 있다.

dotenv 모듈과 joi 모듈을 사용하면 .env 파일에 원하는 값을 다음과 같이 시스템 환경 변수로 등록하고 값에 대한 유효성을 검증할 수 있다.

ACCESS_TOKEN=e23cd8c92925530651ba625f3376a9eeae3cd79c

다음은 Yarn으로 dotenv 모듈과 joi 모듈을 설치하고 .env 파일을 생성하는 예이다. 생성한 .env 파일은 GitHub에 푸시한다.

$ git branch * issue/1 master
$ yarn add dotenv joi
$ touch .env
...
$ git add .
$ git commit -m 'Integration with dotenv and joi to manage config properties'
$ git push

변경 내역으로 issue/1 브랜치에 pull request를 생성하면 다음과 같이 Travis CI의 테스트 결과가 성공으로 표시되는 것을 확인할 수 있다.

GitHub 저장소의 커밋 기록을 살펴보면 .env 파일을 등록하는 과정에서 무엇이 변경되었는지 확인할 수 있다.

Node.js 버전 유지

현재는 문제가 없지만 시간이 지나면 개발자의 로컬 시스템과 CI 서버, 빌드 서버의 Node.js 버전이 달라질 수 있다.

내 로컬환경의 Node.js 버전이 다른데 괜찮나요?

더 많은 모듈이 추가되고 의존성이 복잡해지면 애플리케이션이나 서비스를 안정적으로 관리하기 위해 개발자의 로컬 시스템과 CI 서버, 빌드 서버의 Node.js 버전을 일관적으로 유지하는 것이 좋다. package.json 파일의 engines 속성과 nvm을 활용하면 Node.js의 버전을 일관되게 유지할 수 있다.

package.json 파일에 다음과 같이 engines 속성을 추가한다.

"engines": {
    "node": ">=10.15.3",
},

.nvmrc 파일을 추가하고 nvm use 명령어를 실행하면 engines 속성에 설정한 버전의 Node.js를 사용하게 된다.

$ echo "10.15.3" > .nvmrc
$ git add .
$ nvm use
Found '/Users/user/github/awesome-javascript/.nvmrc'
with version < 10.15 .3 >
Now using node v10 .15 .3(npm v6 .4 .1)
...
$ git commit -m 'Add .nvmrc to maintain the same Node.js LTS version'

마치며

지금까지 JavaScript 프로젝트를 예로 들어 팀으로 함께 일할 때 어떻게 협업하고 개발하는지 간략하게 살펴보았다. Git과 GitHub를 활용해 협업 공간을 구성하는 것으로 프로젝트를 시작했다. 그다음에는 Node.js를 기반으로 하는 개발 환경과 테스트 환경을 설정했다. 설정된 개발 환경을 협업 공간인 GitHub에 공유하고 리뷰하면서 발생한 문제를 해결하며 리뷰 환경을 개선했다.

팀으로 협업하며 일할 때에는 지속적이고 성공적인 코드 리뷰를 위해 다음과 같은 작업은 CI 도구나 GitHub의 webhook 기능으로 자동화하는 것이 좋다:

• ESLint와 같은 도구를 통한 코드 컨벤션 검증
• Jest와 같은 테스트 도구를 통한 테스트 자동화
• Codecov와 같은 점검 도구를 통한 코드 커버리지 점검
• GitHub의 webhook API를 통한 코드 리뷰 요청

위와 같은 작업을 자동화하면 협업하는 개발자는 다음과 같은 일에만 신경을 쓰며 코드를 리뷰하고 개선할 수 있다:

• 코드의 의도가 표현된 커밋 메시지 작성, 적절한 커밋 범위 요구
• 코드의 의도를 나타낸 테스트 케이스 요구
• 복잡한 비즈니스 로직에 대한 주석 요구
• 불필요한 코드 또는 중복된 코드에 대한 의견 제시

협업하며 개발하는 과정에서는 코드를 작성하고 pull request를 생성해 병합하기까지 많은 검증이 필요합니다.

테스트 코드는 이 과정에서 예상하지 않은 문제가 발생할 확률을 줄일 뿐만 아니라 구현 코드의 의도를 효과적으로 전달할 수 있게 만듭니다. 코드 리뷰를 할 때에도 단순히 코드 컨벤션을 검증하는 것이 아니라 비즈니스 로직에서 발생하는 문제를 함께 고민할 수 있었으면 합니다.

이 글이 좀 더 효율적으로 협업하며 소프트웨어를 개발하고 싶어 하는 분들에게 작은 도움이 되기를 바라면서 마칩니다.