Immersive Course
Immersive Course(이하 IM)는 프로그래밍 교육기관 코드 스테이츠의 웹 개발 심화 코스이다. 아래 내용은 IM에서 배우고, 내가 찾아보고, 다른 수강생들이 전해 준 지식이다.
프로젝트 1 시작
이머시브 코스에서는 프로젝트를 총 두 개 진행한다. 그중 약 10일간 진행하는 첫 번째 프로젝트가 이번 주에 시작되었다.
프로젝트는 팀별로 진행하고, 팀원은 세 명에서 네 명이다. 수강생들이 각자 프로젝트 아이디어를 내고 발표한 후 마음에 드는 프로젝트에 지원한다. 팀 구성은 코드 스테이츠 측에서 간단한 지원서를 참조해 구성한다. 나는 '3 ideas'라는 지식인과 비슷한 Q&A 서비스 아이디어를 발표했고, 현재 두 명의 팀원과 함께 서비스를 만드는 중이다.
팀으로 일하기
내가 아이디어를 냈다는 점이 크게 작용하여 팀장이 되었다. 우선 팀원들과 이야기를 나누면서 아이디어를 10일 동안 만들어 낼 수 있는 분량으로 다듬고, 최소한으로 구현해야 할 기능 / 조금 더 부가적인 기능 / 도전적인 기능으로 나누었다. 10일 프로젝트는 지금까지 배운 것들을 복습하는 목적이 크기 때문에 너무 어렵거나 완전히 새로 공부해야 만들 수 있는 기능은 넣지 않았다.
서비스 사용할 기술 목록을 정한 후 데이터베이스 스키마 설계, UI 흐름, API, 린트 룰, 팀 룰 등을 정했다. 짧은 기간 동안 달성할 목표들을 세우고, 그 안에 각자 할 일들을 분배해서 스타트라인에 섰다.
구현하기
나는 프론트엔드를 담당하기로 했다. 리액트를 사용하기로 했기 때문에 컴포넌트 흐름을 간단하게 정하고 다른 팀원과 구조를 잡았다. 그리고 본격적으로 코드를 적기 시작하면서 여러 문제와 의문에 부딪혔다.
- 지금까지는 데이터베이스와 함께 리액트로 클라이언트를 작성하지 않아서, API로 데이터를 받아서 리액트에서 활용하는 방법을 잘 가늠하지 못했다.
- 팀으로 깃과 깃허브를 이용하는 방법을 처음 익혔기에, 어느 시점에 머지를 하는 것이 알맞은지, conflict는 어떤 때 일어나는지 잘 모른다.
- 클라이언트가 잘 돌아가는지 테스트를 하려면 API 요청을 모두 가짜 데이터로 대체해서 하던가, 모두 완성된 API 요청으로 해야 한다고 느꼈다. 가짜 데이터와 API 요청이 섞여 있으면 API 요청으로 state에 데이터가 입력되는 데까지 드는 시간이 가짜 데이터를 읽는 시간보다 느리기 때문에 정확한 테스트가 어려웠다.
- 혼자 일할 때도 물론이지만 팀으로 일한다면 함께 협업하는 사람과 공유하는 문서를 정확하게 만들고 실시간으로 수정하는 일이 중요하다. 사실 확인에 드는 시간을 줄일 수 있다.
- 컴포넌트 흐름은 최대한 상세하게 작성하고 코드를 작성해야 한다. 시간이 부족하다는 조급한 마음이 있었고, 한 명이 아닌 두 명이 작업하므로 각자 맡은 일을 해결하면 되겠다는 생각에 컴포넌트 설계를 소홀히 했으나 나중에는 결국 설계도 일부를 뒤집고 자세하게 작성하게 되었다.
등등 여러 난관이 있었지만, 팀으로 일해서 좋은 점은 위의 경험을 모두 해보고 있다는 점이다. 여러 문제에 부딪히면서 혼자 혹은 팀원과 함께 해결하고 만들어나가는 과정이 매우 재미있다.
한 번 작성했던 구조를 뒤엎고, Miro를 이용하여 컴포넌트 사이의 관계와 state, API 요청들을 새로 정리해 팀원과 공유했다.
팀원들과는 아침 미팅을 통해 어제 한 일과 오늘 할 일을 간단히 이야기하고, 의견을 종합해서 일을 분배했다. 개인적으로는 구현할 기능 한 가지마다 todo list를 작성해서 하나씩 체크하며 진행했다.
Git Flow
팀으로 작업하면서 처음으로 공동작업을 위한 Git Flow를 익히고 따랐다.
- 모두가 함께 사용할 마스터 레포지토리를 마련한다. 마스터 레포지토리는 관례로 upstream이라고 부른다. upstream에는 마스터브랜치와 여러 브랜치가 있을 수 있는데, 대부분 '개발 중'에 사용하는 브랜치는 (역시 관례적으로) dev라고 명명한다. 팀에서는 항상 upstream의 dev브랜치 내용을 최신 내용으로 업데이트하도록 관리하기로 약속한다.
- upstream을 내 공간으로 fork 해온다.
- fork 해 온 레포를 내 로컬에 clone한다.
- upstream과 로컬을 연결한다 - 로컬의 remote로 upstream을 추가한다.
git remote add upstream https://github.com/username/repository-name.git- 로컬에서 새로운 작업을 시작하려고 할 땐 최신 코드를 베이스로 해야 하기 때문에, 브랜치를 새로 만들기 전에 upstream의 dev 브랜치 내용을 로컬의 dev 브랜치로 pull 하여 가져온다.
git pull upstream dev- 그렇게 pull 해온 최신버전의 코드를 베이스로 해서, 새로운 기능을 만들 새로운 브랜치(예 : feature)를 로컬에 생성한다. checkout -b명령은 새로운 브랜치 생성과 더불어 새로 만들어지는 브랜치로 head가 이동된다.
git checkout -feature- 새로 만든 브랜치 (feature)에서 새로운 기능을 개발한다. 일정한 단계마다 커밋한다.
- 기능 구현이 끝나면 해당 브랜치(feature) 를 나의 레포(origin)에 push한다. 구현 중간중간에 해도 된다.
git push origin feature- upstream에 내가 새로 구현한 기능이 담긴 브랜치(feature) 내용을 Pull Request 한다.
- upstream 관리자가 Pull Request를 확인하고 문제가 없다면 머지한다. 그러면 upstream의 dev 브랜치에 내가 새로 만든 기능 코드가 합쳐진다.
- 이후 또 다른 기능을 개발할 때, dev의 최신상태를 베이스로 해야 하므로 다시 5번부터 시작하여 5~10을 반복한다.
