Project1 — Day1

코드스테이츠 2주 프로젝트

(사실 월요일부터 시작했는데 노션에 정리만 해놓고 블로그를 작성하지 못했닿)

2020.05.18
드디어!! 프로젝트 시작. 내 생에 첫 웹앱 개발 프로젝트!
그 전주에 간략하게 프로젝트 아이디어를 내고 주말동안 설문을 통해 후보 아이디어 중 반정도 채택이 되었는데 ... 두둥!!! 그 안에 내것도 있었다 ><

준비할 시간이 진짜 없었는데 밤잠을 설치며 생각한 아이디어라서 설레기도 했고, 사실 프로젝트 전날 밤 아이디어가 채택된 사실과 팀 구성도 알아버려서 5시가 되어서야 잠이 들었다.

이건 급하게 만들었던 나의 기획서 https://www.notion.so/13-5e18cb7a8edd4b0cb6501d08fc8e10ca

내가 기획한 아이디어인만큼 책임감을 가지고 열심히 해봐야겠다.

첫째날 해야하는 일은 다음과 같았다.

• 팀장 선정
• 팀명, 프로젝트명 정하기
• 역할 정하기 (프론트엔드 백엔드)
• Git flow에 대해 배우고 실습하기
• 기능 기획하고 단계를 3개로 설정하기 (Bare Minimum, Advanced, Nightmare)
• 노션문서 정리하고 팀 규칙 정하기
• flow chart 만들고 목업 만들기

감사하게도 팀장을 시켜주셨다!! 코드는 내가 제일 못할 것 같지만 화합을 너무 좋아하기 때문에 가운데서 중재의 역할이나, 분위기 메이커, 으쌰으쌰 같은 역할을 잘 해보고 싶다. 다들 한 번 씩 페어 프로그래밍을 해본 적 있었던 분들이라 넘 반가웠다. 4주 프로젝트때는 프론트를 해보고 싶기 때문에 나는 Backend를 맡았다.

Git 협업 플로우

협업을 위해서 Git을 잘 활용하는게 중요한데, 굉장히 복잡한 구조였다.
간단하게 요약해보면

코드스테이츠

UpStream: codestates에서 만들어준 repository
Origin: 내 깃헙
Local: 내 로컬 컴퓨터

1. 코드스테이츠 repo에서 바로 로컬에 클론을 한 후 초기 셋팅을 한다. 그 후 Dev 브랜치를 만들어서 push 를 한다. (팀 중 한 명이 진행 ) 우리팀은 push 하기 전에 eslint설정이나 기본적으로 필요한 모듈들을 설치해서 넘겼다.

git clone <코드스테이츠 깃헙 레포 주소> — 한 명의 로컬에 클론
git push origin master — 초기 셋팅 후 push (이 때의 origin이 나중엔 upstream이 된다) npm init ! .gitignore 추가 등등.
git checkout -b Dev — Dev 브랜치 만들기 (우리팀은 이 때 linting 설정과 필요한 모듈들을 설치해서 넘겼다)
git push origin Dev — Dev 브랜치에 push

2. 모든 팀원들이 코드스테이츠 repository 를 각자의 오리진에 fork 로컬에 clone 한다. 그리고 코드스테이츠 repo를 upstream으로 추가한다.

git clone <포크해온 자신의 깃헙 레포 주소>
git remote add upstream <코드스테이츠 깃헙 레포 주소>— upstream 추가

이 때 중요한 건 Dev 브랜치를 잘 받아와야 한다는 것.
npm install— 필수!

3. 로컬의 Dev 브랜치를 기준으로 기능별 브랜치를 또 생성한다.

git checkout Dev — Dev 브랜치로 이동, 없으면 만들어준다
git checkout -b [ 기능_1 ]— 구현할 기능 브랜치 생성

4. 기능이 완성되면 commit 한 다음 origin의 동일 브랜치로 push !

git status— 커밋해야하는 파일확인
git add 해당파일 — add 후
git commit -m ‘커밋메세지'— 커밋
git push origin 기능_1— origin으로 push

5. 본인의 깃헙 에서 코드스테이츠 Dev 브랜치로 Pull request을 날린후 검토 후 merge!

그럼 이제 upstream의 Dev를 다른 팀원들이 local의 Dev로 pull 해와서 사용한다!

우리 팀은 커밋메세지를 이 레퍼런스를 참조하기로 했는데, 직관적이고 좋은 것 같다.
https://blog.ull.im/engineering/2019/03/10/logs-on-git.html

이렇게 Git 연습을 마치고, 본격적 기획에 들어갔다.

내가 낸 아이디어이기도 하고, 다른 아이디어들을 다양하게 들어보고 조율하는 작업이 나는 제일 재밌었다.

• 어떤 컨셉으로 갈 것인지 를 맞추고
• 어떤 기능들이 있으면 좋겠는지 자유롭게 의견을 내보고
• 그 중 꼭 필요한 기능들은 뭔지, 서비스를 더 좋게 만들기 위해 더 시도해 볼 만한 것들은 뭔지, 없어도 상관 없지만 있으면 좋겠는 기능들은 뭔지 를 기준으로 프로젝트의 최소 요구사항 (Bare Minimum), Advanced, Nightmare로 프로젝트 목표를 설정했다.
• 그 후, 우리에게 주어진 시간들과 프론트 백엔드가 맞춰나가야 하는 일정들을 고려해서 작은 sprint 단위로 구성하고
• 각 sprint마다 개인이 할 task들을 작은 카드로 분류해 노션에 칸반보드를 만들었다.

아이디어 내는 작업은 너무너무 행복하고 즐거웠는데, 막상 주어진 시간안에 할 수 있는 것들로 구성하다보니 프로젝트 자체는 굉장히 기본에 충실한 친구가 되었다ㅎ

하지만 애초에 기획할 때 학습을 위한 프로젝트로 지금까지 공부했던것들을 복습하고 scratch 밑바닥부터 만들어보는 것에 포커스를 두었고, 화려한 스택들이 올라간 것 보다 최소한의 기능들이 잘 구동되는 완성품을 만드는 것이 목적이기에 팀 모두 만족스러운 기획이 되었던 것 같다.

Flow chart

구현할 기능들을 정한 후 flow chart를 팀끼리 만들었다. 생각보다 오래걸리고 몇번의 수정을 걸쳐서 완성이 되었다. 첫날 만든건 사실 더 단순했었는데, 저장해놓은 사진이 없다.

피그마

피그마 목업은 다음과 같이 구성했다. 팀에 디자이너 능력자가 계셔서 도움을 아주 많이 받았다. 나는 메인페이지에 그냥 월 리스트만 나오게 구성했었는데, 모듈로 여러가지가 보이고, 누르면 페이지 이동해서 리스트를 따로 볼 수 있게 구성했다. 진짜 존재하는 서비스 같아 보인다 ㅎㅎ 2주는 정적 웹앱으로 하지만, 시간이 된다면 어플이나 반응형 웹을 구성해보면 좋겠다는 피드백을 받았다. 피그마 만드신 분 누구냐고 하는 칭찬들이 많이 나왔다 ㅎ 내가 만든건 아니지만 같은 팀으로서 뿌듯 ^^

첫 날 어려웠던 부분은, 아무것도 없는 화면에서 디렉토리 구조부터, 컴포넌트 분리, API 설계 등을 해야하기 때문에 각 task의 예상 시간을 잡는것이었다.

로그인 api 구현 이런 것들은 한 번 해봤으니까 1시간이면 하겠지 했는데,
왠걸 서버 디렉토리 구성 하고 api만드는데만 하루가 소요됐다.
풀스텍을 배우고 나니 endpoint, 라우팅 이런 개념부터 헷갈리기 시작했던게 문제가 되었다. 프론트에서 하는 일과 서버에서 하는 일이 모호하게 구분되어 있지 않았었다. ( 추후에 프로젝트를 진행 하면서 조금씩 감이 왔다)