코드스테이츠의 Pre코스 HA테스트를 지나 정신이 나가 버릴 같은 난이도와 양에도 포기하지 않고 버텨왔고, 중간 여러 차례 검증 테스트를 치뤘었다. 어떻게든 달려들어 그 모든 테스트를 통과하고 드디어 배운 내용들을 기반으로 랜덤으로 편성된 4인 팀에서 프로젝트를 진행하게 되었다.
2주라는 짧은 시간의 프로젝트
지난 PRE때나 IM과정에서 같이 페어프로그래밍을 했었던 동기들을 프로젝트에서 만났지만 여전히 어색한 분위기로 시작했다. 그곳에서 팀장을 정하고, 2주간의 짧은 기간을 진행해야하기 때문의 퀄리티는 상관 없으니 어느정도 완성도를 갖춘 간단한 프로젝트로 공통된 의견으로 맞춰졌다.
정말 다양한 아이디어가 나왔는데 모니터에 대한 정보를 담은 웹페이지, 실시간 위치를 알려주는 홈페이지, 실시간 날씨를 알려주는 웹사이트, 내 할일 목록들을 기록하는 ToDoList 등 아이디어 하나를 정하는데 꽤 많은 시간을 소비했다.
수 많은 의견 끝에 정해진 프로젝트 주제
결국 고심끝에 간단히 작업 하기 좋은 일정관리를 도와주는 ToDoList를 제작하기로 했다. 그러나 웹페이지 구성을 어떻게 잡을지 감이 잘 오지않아 학습 과정에서 우연히 마주쳤던 구글 확장프로그램인 Momentum 컨셉으로 디자인 제작하기로 결정했다.
모멘텀 설치
결국 모든 주제는 정해졌고 프로젝트는 아래와 같은 컨셉을 맞췄다.
프로젝트 역할 분담
팀장의 주도로 역할 분담을 주제로 의견을 나눴었는데.. 서로 원하는 포지션이 겹치지않아 프론트 2인 백엔드 2인으로 역할이 정해졌다.
프로젝트 역할
프론트엔드 - 익명, 본인
백엔드 - 익명, 익명
이제 다음 과제가 남았으니 바로 프로젝트 주제에 대한 목업 설계와 Github의 계획 및 이슈카드 작성
사용할 라이브러리 및 프레임워크 선정, 구글 문서를 활용하여 프로젝트에 관한 모든 내용을 담는 Readme 작성 등 정말 많은 과정을 경험해야 했다.
나름 철저하게 준비된 계획
코드스테이츠의 IM과정을 마치고 막 프로젝트를 시작하던지라 매우 어수선했다. 하지만 시간이 빠르다는걸 느꼈고 완성도 있는 프로젝트 결과물을 보여주고 싶은 마음이 간절하여 계획을 철저하게 수립하게 되었다. 백엔드 쪽의 익명이 문서를 잘 다루어서 빠르게 시작할 수 있었다.
본인 역할은 프론트엔드였으니 해당 역할로만 작성하려한다.
A. Google 문서로 계획 선정
첫번째로 작업한 내용은 구글 문서를 통해 구현가능한 기능들을 3가지 난이도로 나눴다.
이 문서는 서로 공유하여 작업했으며, 본격적인 프로젝트에 진행하면서 중간에 회의 및 추가 구현할 기능들을 제시할 때마다. 새로운 문서페이지에 기록하였다.
B. Miro를 활용해 MockUp 설계
우선 내가 한 일은 Momentum의 구조를 대강 파악해야만했다. 위 이미지에서와 같이 Momentum은 큰 구조를 잡아 5~7 단계로 나누었고, 세세한 자료들은 CSS 옵션을 어떻게 줬는지, HTML 문서 구조를 파악했다.
어느정도 파악된 구조로 설계를 진행했었고, 아래는 실제 적용했을때 예상도와 부족한 내용들을 보완하여 추가작업을 하였다.
C. 흐름(Flow) 차트 제작
사실 중간 중간에 여러번 수정하긴 했는데 Mockup 다음으로 진행되서 이 위치에 작성했다.
팀장이 기본 틀을 잡아 완성 후에 나는 빠진 일부분을 보완하여 제작했다.
E. 스택 선정
SPA기반 페이지를 제작할 프레임워크부터 ToDoList 및 모멘텀의 각종 효과를 구현하기 위해서 필요한 라이브러리 선정을 시작했다.
이 때는 정말 급해서 우리가 배웠던 스택을 기반으로 작성되었다.
React를 사용한 이유: 가장 큰이유는 배운 프론트엔드 프레임워크로는 React라서 그렇다. hook을 다룰즐 알아서 더 좋았다.
REDUX를 사용한 이유: 상태 관리를 Store에서 해주는게 가장 큰 매력이다. Store에 상태를 담아두고 어느 컴포넌트에서든 가져다 쓸 수 있다는게 큰 매력이었다.
F. 코드 스타일, 변수, git branch 기준 등 가이드 작성
정말 편리함과 동시에 작성함과 동시에 마크다운을 배울 수 있는 Git Issues 탭에 작성되었다.
지금 보니 너무 시간에 쫒긴다는 핑계로 대충 잡은 것 같다. 아무튼 이 내용들은 Github 레파지토리에
Wiki 페이지에 다시 정리되어 있다.
백엔드 팀과 서로 소통하여 양식을 맞춰나갔다.
G. 프론트엔드에서의 역할
그렇게 피곤하고 빡쏐던 계획이 마무리 되고, 프론트와 백엔드팀은 각각 줌으로 나뉘어 작업을 시작했다.
처음엔 기능 구현을 반반 분활하여 작업을 시작했다. 하지만 Redux의 사용법이 익숙치 않았던 나는 Store로 상태를 저장하고 가져오는 부분에서 많이 애먹어 시간을 잡아먹는 것을 꺠달았다.
더 이상 지체할 수 없어 내가 어느정도 자신있던 CSS로 디자인 위주로 작업하고, 필요한 부분을 보충한다고 팀장에게 의견을 제시했고, 다행히 기능부분을 맡아주셨다.
결국 아래의 포지션으로 남은 기간을 진행했다.
팀장 : 프로젝트의 주 기능들을 담당
본인 : 프로젝트의 UI/UX 디자인 담당.
CSS 작업하면서 황당한 실수들
css작업도 정말 쉬운게 아니었다. 어떻게 깔끔하게 보일지, 모멘텀과 비슷하면서도 차별화 된 디자인을 생각해야 했었고, 실제 배치도 엉망이었다.
- 폰트 사이즈가 그대로인 상황
header{
display: flex;
justify-content: center;
align-items: center;
}
header .header_txt {
font_size: 2.5rem
.
.
.
}임시 배포는 성공했고, 작업 마무리가 다가왔을 때 메인 페이지의 폰트 사이즈를 수정해야 하는 일이 발생했다.. 그런데 선택자.header_txt의 font-size를 아무리 수정해도 그대로 였다.
이런게 좀 많았는데 알고보니..
<div className="대충 클레스 네임"></div>className이나 ID의 오타나 css에서 클래스 선택자를 지정할 때 . 을 빠트렸다던가 별거 아니지만 시간 잡아먹는 골때리는 일이 있었다.
2. 생각과는 전혀 다른 엉뚱한 위치의 컨텐츠들
본인 사용하는 노트북은 15.6inch의 16:9 화면 비율을 가진다. FHD에선 분명 멀정했는데 width,height 값 때문인지 따로 쓰는 32인치 QHD모니터에선 완전 엉뚱한 방향에 배치되어 있었다.
그 다음 프로젝트에서는 %를 주어 비율을 맞췄었는데.. 일일히 맞추느라고 고생했다.
3. 호버링 효과
CSS기술력이 정말 한참 부족하다는 것을 느꼈다. 호버링 효과를 좀 더 재밌게 주기위해
span:hover {
}단순히 이렇게만 사용했었는데 뭔가 많이 허접하다. 버튼에 애니메이션 효과를 달기위해선 다음과 같은 옵션을 줘야 하더라
<button>
<span className="btn_effect_a"></span>
<span className="btn_effect_b"></span>
<span className="btn_effect_c"></span>
</button>강좌 영상들을 보니깐 효과를 주기위해 <span>태그를 적극적으로 활용한다.
span:after
span:before{
content: "";
}
span:hover:after{
transition: 0.3s linear
}대충 이런식으로 작성하여 효과를 줘야해서 버튼하나 디자인 하는것도 기술이 필요하다. 특히 transition 으로 효과의 시간을 조절 한다는걸 썼었는데 엉뚱한걸 쓴 것같다.
4. 문제의 에니메이션 효과.
사실 별다른 에니메이션 효과는 없다.
부끄럽지만 버튼이나 글자의 호버링 효과를 주기위해
@keyframe animationName{
from {
}
to {
}
}이런걸 작성해서 줘버렸다.. 사실 슬라이드 캐로셀 같은 곳이나 메인 화면에 떠다니는 모양들의 에니메이션 기능을 넣기위해 사용하려 했지만 현실은 버튼 호버링에나 쓰이고 말았다.
고생 끝의 결과물
작업 도중 어떤 기능이 안되는 버그도 있었고, AWS로 첫 배포를 시작해서 테스트 했을때 잘됬는데 갑자기 안되는 경우도 있었다. 정말 다행인 점은 프로젝트 진행 과정에서 팀원간의 불화 없이 재미있게 진행했다는 점이었다. 그렇게 훈훈한 분위기에 마무리되었고 최종 결과물은 아래와 같다.
지금은 배포된 페이지가 닫혔지만(아마존 무료기간 풀려서 ㅋ) 기록물은 그대로 남겨져있어서 다행이다.
프로젝트
빌드업 깃허브
