4명을 한 팀으로 하는 2주 프로젝트를 처음 해보면서 정말 많은 것을 배우고 느꼈다.
특히 개발에 온전히 집중해서 하나씩 일정대로 소화해 나가는 재미를 느꼈고, 프로젝트 결과 발표 전에 우리가 기획한 아이디어가 예쁘게 잘 동작하는 것을 보면서 보람차고 뿌듯함을 느꼈다. 팀장 역할이 처음엔 조금 부담이 되었지만 서로가 서로를 적극적으로 설득하고 존중하는 팀문화가 자연스럽게 정착된 것을 보고 느끼면서 이 또한 보람차고 좋은 팀원들을 만나게 되어 감사함을 느꼈다.
프로젝트 주제 확정
- 프로젝트 주제 정하는 첫날부터 벌어지는 시행착오
프로젝트 주제를 정할 때 가능하면 우리의 아이디어 들 중 가장 재미있으면서 2주 안에 결과물을 만들 수 있는 주제를 찾으려고 하루는 프로젝트 주제를 정하기 위한 아이디어 회의로만 썼다.
첫 날 결정된 주제로 Spotify라는 음악 API를 사용해보려고 했는데, API 설명이 친절히 되어 있어서 날씨 API처럼 단순히 API Key받고 사용만 하면 될 줄 알았다. 천천히 살펴보니 아니었다. 생각보다 API를 사용하는 법이 복잡해서 한 명은 API 사용법에 대해서만 최소 며칠은 공부해야만 했고 공부한다고 해도 실제로 사용이 가능하리라는 보장은 없었다. 그래서 급하게 늦은 밤 긴급 회의를 소집하고 외부 API 없이 구현할 수 있는 주제로 아이디어 3개만 추려서 내일 아침 원하는 아이디어가 있으면 아주 간략하고 자유로운 이미지를 준비해 주길 부탁했음.- 정해진 주제는 트렐로와 같은 칸반보드를 사용하는 협업툴 만들기. 그런데 단순히 프로젝트, To-Do List라는 용어로 앱을 만들기에는 너무 재미가 없고, 트렐로 기능을 어설프게 따라하는 클론 코딩 정도로 밖에 되지 않을 것 같다. 그래서 프로젝트 관리와 농장 경영의 요소를 추상화해서 서로를 매핑하는 작업을 했다.
- 프로젝트 : 농장, 팀원 : 농부, To-Do List : 농작물 씨앗, 완료 리스트 : 곳간
- 그래서 결정된 주제명은 FARM.
다음 프로젝트 부터는 이렇게 해야 겠다!
- 깃헙에서 Task 카드 만들 때, 클라이언트 내부에서 기능하는 파트와 서버통신, 그리고 css스타일링은 별도의 Task로 구분하자!
- 서버에서 주는 응답의 변수명과 클라이언트에서 다루는 변수명은 카멜 규칙을 따르자! (소문자로 시작)
- 모바일에서도 볼 수 있게 반응형을 구현할 시간을 따로 마련하자!
- 로그인 없이도 기능을 테스트할 수 있는 부분은 고민하자! 어디서부터 로그인이 필요할 지?
- 타입스크립트를 사용하자! 2주 프로젝트에서는 변수명을 정의할 때 타입을 앞에 명시하는 것을 팀룰로 정해서 진행했지만 그래도 런타임 단계에서 타입이 결정되며, 사람이기 때문에 실수할 수 있다. QA 테스트를 통해 발견될 버그나 오류를 컴파일 단계에서 조기에 발견할 수 있을 것이고 이제 곧 시작할 4주 프로젝트에서는 조금 더 규모가 커질 예정이기 때문에 버그를 조기에 발견하고 UX를 저해할 요소를 미리 차단하는 의미에서 도입하도록 하겠다.
- Footer에 팀원들의 깃헙 링크를 넣어주자!
- 프로젝트에 들어가기 전 쉬는 날을 이용해 미리 프로젝트 주제 아이디어 브레인스토밍 실시하자!