팀 프로젝트
- 수강하던 코딩온 수업에서 2치 풀스택 프로젝트를 진행하게 되었다.
- 프로젝트 소개와 주제 선정 배경 보다,프론트엔드를 다루면서 겪게된 트러블들, 그리고 그 트러블들을 해결한 트러블 슈팅에 중점을 두는 나만의 기록이다. Keep Problem Try 회고방법론을 통해서 적으려한다.
- 이번 프로젝트를 통해서, 어떻게 작업을 해야할지 조금더 명확하게 깨닫게 되었다.
프로젝트와 주제
- 조원들중 프론트/백엔드로 나뉘어 작업을 시작했다. 프로젝트는 다른 조원의 의견을 빠르게 수렴하여 작업을 시작했다.
. GPT를 이용한 멀티랭귀지 학습 기능 사이트
. 기능 사용에 중점을 두도록 대시보드 스타일의 웹페이지를 구현
기억나는 ...진행과정...
주제를 듣고...
- 백엔드와 프론트 팀원들과의 머릿속 동기화(?) 를 위해 빠르게 와이어프레임을 진행
- 백엔드에선 백엔드대로 진행, 프론트팀은 바로 작업에 들어갔다.
- 첫번째 기획에선, 모바일사이트를 먼저 제작후 PC웹페이지를 만듬
- 레퍼런스 참고를 위해 자료조사 단계를 가졌다.
- 프론트팀원은 모바일 디자인 레퍼런스 조사 / 나는 pc화면 레퍼런스 조사
- 모바일 페이지 디자인 완성 (trouble 1)
7 . 코딩작업에 있어서 내가원하던 atomic design으로 폴더구조를 잡음 - 사용할 라이브러리를 조사하고, atoms 컴포넌트를 제작 trouble
- styled-components 를 사용하기 위해 디자인토큰 작업 착수 troulble
- 회원가입 로그인 세팅 페이지 제작 css없이 레이아웃만 trouble
- 노반응형으로 전환
- 인터랙션 ui 를 위해 각 세부 컴포넌트에 Lottie 작업 (하루)
- 스켈레톤 UI 컴포넌트 생성,다크모드 생성,채팅리스트 컴포넌트
- 카카오 로그인 api 서버연결 시도
- 마지막날에 부족했던 회원가입과 로그인 CSS 작업
- 서버배포과정
자기 피드백
1. 디자인작업에 너무 시간이 지체 되었다.
- 뭔가 제대로 하고 싶은 마음에 피그마를 통해 디자인 과 레이아웃을 잡고.
디자인 토큰까지 활용 하여 CSS 에서 부담을 덜으려고 했으나
작업 시간에 이유로, 서둘러서 코딩작업에 들어간것. 중간중간 디자인상 변경사항으로인해 디자인토큰을 만들었으나 효율적으로 사용하지 못했다.
K:
피그마를 이용해서 한눈에 어떤식으로 작업해야할지. 눈으로 보면서 코딩을 작업 할 수 있었다. 확실히 이점이 있었다. 눈에 보이지 않고 머릿속에서만 구상했을 땐 중간중간 어떻게 만들까 라는 생각을 하면서 시간을 보냈는데... 피그마를 사용하니 눈에 보이는 결과물을 코딩하기만 하면되서
코딩과정에서 많이 시간단축이 있었다....
또 한가지 장점은 피그마의 핸드오프기능으로 인해
프론트 작업에서 CSS부분에서 시간단축이 있었다.
P:
- 피그마 내에서의 디자인작업속도가 너무 느려서. 전체적인 프론트엔드 작업진행에 뒤쳐졌다. 코딩과정에서 시간단축은 되었지만, 정작 프로젝트기간의 시간지체가 되었음.
- 섣부른 디자인 토큰 : 필요없었다. 결과론적으로 디자인이 바꼈기 때문에. 하루가 날라갔다.
- 프론트 팀원과의 디자인적 소통이 적었다. 소통이 적어서 디자인통일이 되지않았고 또 그 결과적으로 분업이 실패하였고 시간낭비 즉 비용이 생겼다.
- 프로젝트의 핵심기능을 먼저 제대로 디자인을 하고 그다음에 살을 붙이는게 맞았던거 같다. 정작 프로젝트 진행중 핵심 디자인인 채팅과 리스트에서 시간지체가 되었다.
- 일단 디자인하기전. 백엔드와 소통을 통해 웹페이지에서 필요한 오브젝트를 미리 설계 하고 시작했어야했다.
결과적으로 시간단축을 위해 사용하려던 피그마가 시간지체가 많이생김
T:
- 디자인 통일감을 위해, 한명은 세부 컴포넌트 먼저 만들기 시작하거나, 최대한 빠르게 레퍼런스를 참고 해야 할 거 같다.
- 디자인을 시작하기전, 백엔드와 충분한 회의로 설계를 더 단단히 해야한다.
- 중간에 노선을 바꾸지 말것 제일중요
- 디자인토큰은 나중에 CSS작업때 생각해봐도 될 것 같음.
- 피그마 활용능력을 기를것. 확실히 도움이 되는 부분이 있었기 때문.
2. ATOMIC DESIGN 에 시간이 너어무 할애됨.
- 프론트엔드 작업으로 보여줄 무언가는 클린코딩과 코드스플리팅 폴더구조라 생각해서.. 작업에 들어가기전 우리 팀은 ATOMIC DESIGN 을 이용하여 컴포넌트를 제작 하자고 했다.
ATOMIC DESIGN 자체를 이해하는데 시간이 걸렸고. 작은 아티클 하나하나 만들고 조합하는 과정에서 오래걸렸다
K :
아토믹디자인은 너무좋았다. 마치 레고와 같이 초반에 더디다는점은 아쉬웠지만, 나중에 페이지를 조합할 때 있어서 금방 페이지하나를 뚝딱뚝딱 할 수 있다. 추가로 컴포넌트를 제작할 때 어떻게 제작해야할지 감이 잡히기도하고 유지보수에 특히 좋았다. 어느페이지의 어느버튼이 문제네 ! => atoms 에 버튼 수정.
P :
- ATOMIC DESIGN 을 온전히 이해하는데 걸리는 시간이 있었다.
- 팀원간에 잦은 회의로 아토믹 디자인 설계를 빠르게 정립했어야했지만,
시간이 모자라 밀린 작업이 아토믹 디자인에 맞지 않았다. - 내실수 : 시간이 모자르고 작업을 빠르게 하기위해 컴포넌트명을 대충 지었다. 그리고 또 나중에 수정을 했어야하지만. 그게아닌 다른 팀원도 내가 대충 지은 컴포넌트명을 따라시작하면서... 나중에 난리가 났다.(이게 무슨컴포넌트지...?)
- 백엔드 팀원들도 이해못하는 폴더구조였다.
- 아토믹디자인을 사용하려면 리덕스가 필수인거같다!!!!!
프로퍼티 드릴링에 미쳐버렸었다. 더러워진 App.js 더러워진 프롭스...
T:
1.아토믹디자인 계속 써야한다. 모자란 리덕스도 공부해서 매꿔야한다.
사용해보니 진정한 리액트를 사용하는 느낌이었고 확실히 후에 유지보수에서 확실히 편리하였다.(느린거는...)
2.컴포넌트명,변수명을 대충지으면 안된다. 진짜 안된다. 당장에 다음주에 나도 못알아본다. 원래 하지 않는 행동이나 급해서 생긴 실수.
3. 팀원들 회의에서 한번이라도 아토믹디자인을 언급해 넘어가서 전부 이해하는게 좋을거같다.
4. 리덕스를 배우고나면 아토믹디자인이 너무 깔끔해질거같은 생각.
3. 회원가입과 로그인 사이트 구현
- 프로젝트 기획상 프론트엔드가 보여줄만한 부분이 많이 없었다.
그래서 처음부터 해보고싶은 로그인과 회원가입 페이지에 시간을 투자했다.
CSS는 최대한 미루고 서버 연결관련과 인터랙티브 기능에 대해서 작업했다.
K:
회원가입과 로그인에서 시도한 결과물은 나쁘지 않았다. 이번 프로젝트로 어떻게 다뤄야할지도 알았고, 몇몇기능은 회원가입/로그인 폼에서 계속 사용가능한것이니. 토이프로젝트로 다시 만들어 사용해도 될거같다라는 생각을 했다. 특히 비슷한 기능을 많아 커스텀훅으로 포장해도 좋을것 같았다.
카카오톡 로그인 API 를 이용해서 카카오로그인 기능 구현도 괜찮았다.
P:
- 여기에 신경 쓰면 안됐다. 내가 회원가입과 로그인폼에 작업을 몰두한동안. 프론트 팀원도 다른것에 몰두하느라. 정작 프로젝트에 제일 중요한 핵심 기능의 프론트단이 완성되지 않았다.
- 기본적은 CSS 는 만들어뒀어야했다. 나중에 몰아서 하겠단 생각으로 인터랙티브 기술만 하려다. 나중에 CSS 에서 허점이 많았다.
- 중간에 백엔드에서 제작한 카카오톡 로그인 API 는 JAVASCRIPT SDK 였기 떄문에 리액트환경에서는 사용하기 매우 어려웠다. 더군다나 시간이 걸리는 일이었으면, 내가 이어서 했으면 안됐다. 서버쪽이나 프론트쪽이나 어느곳에서든 연결할 수 있는거였으면, 백엔드 팀원이 마저 작업하던지 과감하게 삭제했어야했다.
T:
- 로그인과 회원가입 페이지는 사용자가 제일 많이 방문하는 페이지중 하나 아닐까 싶다. 마이크로 인터랙션은 계속 유지하는게 좋을 것 같다.
- 핵심기능 먼저 구현하여 그 이후로 살을 붙이는 방법으로 페이지를 제작하는게 좋을 것 같다. 이 사이트에 핵심은 로그인/회원가입/인덱스가 아닌 채팅창이니...
- 카카오톡 API 사용방법은 이제 깨달았으니 다음 작업물에서는 온전히 사용할 수 있을것 같다.
그래서 ?
-
이번 프로젝트를 통해서 알게된 정보들이 너무 많고, 내가 또 어떻게 해야할지 감이 잡힌 아주 소중한 프로젝트였다. 완성된 결과물보다 그 과정이 더중요한것같다.
-
다음글은 작업하면서 마주하게된 Error/Trouble과 해결/우회 방법을 기록하려한다.
