NAWEKE 프로젝트 회고

NAWEKE 프로젝트가 끝났다.

우리팀은 나이키를 모델링한 나위키를 제작하였다.
프론트엔드 4명/ 백엔드 3명으로 구성하였다.

나이키에서 각자의 아이디어를 더해 더 다양하고 편리한 UI/UX를 위해
해당 상품과 같이 코디하면 좋을 코디를 추천해주는 룩북을 만들자는 의견도 나왔고
로그인/회원가입을 하나로 합치고 회워가입시 자동으로 로그인되는 것도 구현하기로 했다.

NAWEKE github link
시연 영상 링크

일단 느낀점과 블로커를 작성해보겠다.

느낀점

1. 개발자는 소통을 잘해야한다.
   커뮤니케이션 등의 소프트 스킬이 좋은 개발자가 되려면 꼭 필요하다고 했다.

이번 프로젝트를 통해 그 이유를 확실히 깨달았다.

초반 2일을 기획하고 브랜드의 가치, 브랜딩등에대해 생각하며 회의 했다.

이때 명세, 각 엔드포인트 등의 통신에 필요한요소들과 기획을 ppt로 직접 작성하면서 시각화 해놓으니 중간에 기획이 꼬이지도 않았다.

또한 기획 변경사항이 있을때도 수정, 수정요청 사항을 확실히 반영하고 기획 할 수 있었다.

2. 현재 내가 하고자하는 서비스의 방향성이 무엇인지 소비자의 니즈가 무엇인지, 기업의 브랜딩이미지와 가치를 정확히 판단하는것이 매우 중요하다.

기업의 방향성을 알고 커스터머의 니즈를 파악하고 충족하는것이 결과적으로 소비를 이끌어내는 어렵지만 가장 빠르고 확실한 방법이기 때문이다.

3. 레이아웃과 기능은 따로 구현해야하며 현업에서 페이지 단위가 아닌 컴포넌트 단위로 개발을 분담하는 이유를 알았다.

레이아웃과 기능을 동시에 구현하니 레이아웃이 머지되지않아
페이지에서 페이지로 동적 라우팅되는 기능을 구현하는데에 혼동이 있었고
배포 전날 머지가되는 상황이 발생하였다.
컨벤션을 최대한 지켜가며 진행하였음에도 컨플릭트와 css 수정하는데에 4-5시간을 소요했다.

만약 현업에서 수개월이상의 프로젝트를 진행할때 이런식으로 하면 기한내에 과업을 완수하지 못 할 것이라는 것을 배웠다.

컴포넌트 단위로 개발을 할 수 없는 상황이라면
최대한 큰 틀이라도 레이아웃을 머지 시켜놓고 기능 개발을 하도록 하자.

Blocker

nav 드롭다운을 만들때 처음엔 transform을 사용해 위치값만 변경시키는 로직을 생각했다.

하지만 그렇게되면 불필요한 랜더링이 계속해서 쌓이게 된다는 생각을 하여
display : visiblity / none 또는
opacity값을 사용하려고 했다.

하지만 useState('none')을 주고 css상에서 visiblity: visible을 사용해 상태관리를 하려고 하니
passing 에러가 떴다.

랜더링 순서가 꼬여서 그렇다는 판단을 내리고

isSubMenuOpen이라는 state를 선언해주고 기본값 false를 부여해 아예 랜더링을 시키지 않는 방식을 사용해봤다.

이런식으로 nav 링크에 마우스가 진입 할 때에만 랜더링이 되어 나타나고 다른곳에 진입하면 상태값이 다시 false로 바뀌는 방법을 사용하니 해결됐다.

아래는 프로젝트에 관한 상세한 내용/회의록이다.

프로젝트 스케쥴/회의록

1/2일차때는 플래닝 미팅을 시작하며 트렐로와 팀노션을 작성하고 슬랙/깃허브를 통해 소통하기로 했다.

트렐로

팀 노션페이지

프론트엔드 깃허브

다른팀과 비교했을때 2주라는 짧은 시간에 비해 2일을 통으로 플래닝 미팅을 하는데 사용했다. 정할것도 많고 다들 나오는 의견마다 한번 해보죠 라는 마인드였어서 그랬던 것 같다.
하지만 결과적으로 봤을때 초반에 미팅을 오래했어도 세부적으로 잘 나누고 분담을 확실하게 했던것이 프로젝트 진행에 속도를 붙게해준 중요한 포인트가 아니었다 싶다.

프로젝트 일정

기획 2일
레이아웃 구현 1일
기능 구현 5일
코드 리뷰 및 리팩토링 2일

이렇게 결정됐다.

3일차 회의

• 진행상황 :
• api 역할 분담 :
• db 이번주까지 입력
• 필수 api 이번주까지
• 구현할 기능 정리 후 프런트와 상의
• 유저 결제내역 조회 구현(추가구현)
• 검색 기능(추가구현)

4일차 회의

데이터에 들어갈 사진 구하기

5일차

• 진행상황 공유
• 결제 완료 후 주문 내역 페이지(이전 구매 기록까지)
• 바로구매 x
• FE - 주문 내역 페이지(이전 구매 내역 포함) - 레이아웃 구현 예정
• FE - 검색 기능 구현(전체 데이터 필요)
• FE & BE - 필터링 된 데이터를 통해 상품 리스트 표시하는 것
• FE & BE - 로그인 회원가입 통신 해볼 예정

2차 스프린트

1일차
백엔드 진행상황:

• 필수 기능 리뷰 받는 중
• 이후 선택 기능 개발 중

프론트 진행상황:

• 필수기능 pr리뷰 받고 수정 중
• 메인 페이지 거의 완성

지난주 회고

• 형진님: 페이지의 기능 구현에서 부족함을 느꼈다. 소통을 적극적으로 했어야 한다는 점이 아쉽다.
• 지영님: 처음 회의 때 너무 많은 기능을 하기로 결정한 느낌이 들었다. 그러나 결정한 기능을 모두 구현하기 위해 노력했다.
• 명석님: api 명세를 프런트와 소통하기 쉽게 만들지 못한 것이 아쉬웠다.
• 한솔님: api 명세 ~ / 어려운 기능을 맡아 부담이 있었는데 팀원과의 소통으로 업무 분담을 통해 부담을 덜 수 있었다.
• 호준님: 몰랐던 부분에 대해서 공부할 수 있는 기회가 생겨서 좋았다.
• 석현님: 개발 중간에도 맡은 업무를 팀원과 소통하여 많은 양을 처리 할 수 있었던 것이 좋았다.

멘토님 미팅

• 장바구니 체크박스 구현
• 사용자 입장 고려
• 주고받을 데이터가 무엇일지 예상 못함 → 필요없는 로직 추가됨 (결제시 무조건 장바구니를 거쳐야함)
• 직접 결제 기능 추가
• api 명세 작성
• aws

2주차 첫날에는 백엔드/프론트엔드가 서로의 진행상황을 확인하는 것으로 시작했다.

진행 상황을 체크하는것은 매우 중요하다.

진행 상황/ 각자의 세부 진행 상황까지 자주 확인하는것이 프로젝트의 목표지점을 그때그때 설정하는데에 많은 도움이 됐다.

1주차 회고에도 나와있듯이 개발 중간에도 맡은 업무를 팀원과 소통하여 많은양을 처리 할 수 있었던것.

팀원들간 소통을 통해 기간안에 처리 할 수 있는 기능을 제외하고는 중간중간 추가/배제를 할 수 있었다.

2일차:

• 유저 프로필 페이지 추가
• 로그아웃
• 바로구매
• 리뷰(보류)

3일차:
초기 기획에서 이날까지는 모든 기능을 완성하고 배포를 하기로 했었다.

하지만 서버와 통신을 시작하면서 에러가 생기기 시작하고 하루 미루기로했다.

따라서 오류수정의 날이 되었다.

4일차:
백엔드는 배포를 위한 과정을 시작했다.

프론트는 모든 컴포넌트 머지 후 수정을 시작했다.

컨플릭트가 너무 많이 발생해서 수정하는데에만 4-5시간정도 소요된것 같다.

되도록이면 레이아웃과 기능은 나눠서 구현 하도록 하자.

종료

이렇게 프로젝트 NAWEKE는 마무리가 되었다.

좋은 팀원들에게 도움도 많이 받았고 나도 도움을 줄 수 있었다.

또한 팀원들간에 화합도 잘됐고 그때문에 활발히 소통하여 프론트와 백간에 싱크도 잘 맞게 개발이 가능했다.

프로젝트를 한개씩 진행 할때마다 배울점이 너무 많다는걸 느끼고있다.

다른 사람들에게 도움을 줄 수 있는, 내가 가진 기술로 다른 사람의 인생에 도움이 될 수 있는 개발자가 되겠다는 목표를 이루기 위해 더 노력해야겠다.