WECODE - 1차 프로젝트 회고 [Tabom-Galagsin] / CloneCoding

SeungMin·2022년 8월 28일
0

WECODE

목록 보기
14/19

프로젝트 이름


프로젝트 팀

  • 팀 이름 : Tabom-Galagsin

브라질 사이트를 클론했기 때문에 브라질 말로 최고라는 뜻인 따봉
+FlipFlop 판매사이트 , 우리말로 가락신을 판매하는 사이트이기 떄문에 가락신
둘을 더해서 따봉 가락신 ㅎㅎ;; 입니다.

  • 팀원 :

    • FE

      박승민
      메인 페이지 , 장바구니

      송경용
      로그인 / 회원가입 페이지

      임채동
      메인 페이지, 상품 목록 페이지

      최슬기
      NavBar, 상품 상세 페이지

    • BE

      길성민
      제품 상세 API, 장바구니 API, 카테고리 API, 색상별 제품 조회 API

      문정진
      로그인/회원가입 API, 메인 페이지 API, 필터링, 추천 알고리즘 API, 구매 API


STACK

기술 스택

  • FE

  • BE


ERD


API Documentation

API Documentation


협업 도구 - Trello

현재는 프로젝트가 끝난 시점이라서 전부 Done 으로 넘어가있다..
각각의 Section 을 설명하자면

Backlog : 프로젝트에 끝내야 할 모든 티켓중 진행되고있지 않은 티켓이 위치한다.

To-Do : 이번 Sprint에 끝내야 할 티켓중 진행되고있지 않은 티켓이 위치한다.

InProgress : 이번 Sprint에 끝내야 할 티켓중 진행중인 티켓이.

InReview : 1차적으로 진행이 완료되고 PullRequest를 작성하고 merge를 기다리는 티켓이 위치한다.

Done : PR이 Submit 되어 Repositioy의 main에 merge된 상태인 티켓이 위치한다.

Minutes : Sprint첫날 PlanningMeeting 또는 DailyMeeting에서 이야기된 사안들을 기록해놓는다.

위의 Section들을 적극 활용하여 현재 진행률을 한눈에 파악하기 쉽게끔 정리하여
프로젝트 진행에 차질이 없게끔 진행하였다.


프로젝트 시연영상

이미지를 클릭하면 링크로 이동합니다!


구현 사항

  • 무한 캐러셀

일반적인 캐러셀은 마지막 슬라이드에서
다음 버튼을 누르면 처음 페이지로 돌아가는 모습이 보이거나
마지막 페이지에 위치할 때 다음 버튼을 비활성화 시켜버린다.

때문에 무한 캐러셀 ( 사용자가 바라볼 때 무한히 선순환하는 캐러셀 )을
구현할 때 고민이 많았던 기억이 있다.

내가 구현한 방식은 간단하다.

  1. 보여주고자 하는 슬라이드 배열을 앞뒤로 한번 복사해서 총 길이가 3배인 배열을 만든다.

  2. 마지막인덱스에서 그 이상으로 나아가려할 때 아래의 로직이 발동한다.
    1. transition을 0으로 바꾼 뒤 currentIndex를 -1로 이동한다.
    2. transition을 원상태로 돌려놓은 뒤 currentIndex를 0으로 이동한다.
  3. 첫번째 인덱스에서 그 이전으로 나아려할 때 또한 같은 로직으로 동작한다.

한마디로 눈속임을 이용한 로직이다.

transition이 0이된 시점에서의 화면 이동은 사용자가 알 수 있는 방법이 없기 떄문이다.

해당 동작을 구현한 코드는 아래와 같다.

      if (categoryPosition === -(categoryData.length / 3) - firstPosition) {
        setTransitionTime(0);
        setCategoryPosition(firstPosition + 1);
        setTimeout(() => {
          setTransitionTime(0.3);
          setCategoryPosition(firstPosition);
        }, 0);
      } else {
        setTransitionTime(0.3);
        setCategoryPosition(categoryPosition - 1);
      }

위의 코드는 이전 버튼을 눌렀을 경우이다.

setTimeout을 사용한 이유는
setState를 한번에 두개 이상 동작시킬 경우에는 비동기적으로 작동하기 때문에
눈속임 과정이 훤히 보이게된다.

  • 장바구니 페이지

장바구니에 부가적으로 달려있는 기능인 현재 담긴 상품 갯수가 있다.

해당 기능을 사용할 수 있는 페이지는

메인페이지 , 상품 리스트페이지 , 상품 상세페이지 , 장바구니 페이지
총 네가지가 있었다.

어려운점으로는 모든 페이지에서 위의 기능이 구현되는 Component
ImportNavbar Component 라는점이다.

때문에 고민끝에 한 로직을 설계했다.

위의 로직을 설명하자면

  1. DB에서 fetch로 로그인시 현재 접속된 ID가 장바구니에 담아놓은 상품의 갯수를 받아온다.
    해당 데이터를 LocalStorage에 저장하고 또 State에도 저장한다.

  2. 위에서 언급한 4가지의 페이지를 라우팅 할 때마다 위의 과정이 반복된다.

  3. 장바구니에 상품을 담게되는 버튼이 있는 자식컴포넌트인 Product.js
    setStateprops로 넘겨준다.

  4. Product.js에서 실행된 setStatelocalStorage.setItem의 변경사항을 반영할 NavBar.js에 넘겨준다.

1차 프로젝트에서는 Redux 를 사용할 수 없기 떄문에 전역으로 관리할 수 있는 변수가 없다.
떄문에 전역으로 관리되는 유일한 값인 DB 데이터와 LocalStorage 값을 활용한 로직이다.

다루고 싶은 코드는 많지만 회고에 다룰만한 주제는 이쯤 줄이고 각자의 프로젝트 후기를 다루려고 한다.


회고

FrontEnd

  • 최슬기

    • 내가 잘 한 부분 : 스텐드업미팅 회의를 주도하였다.

    • 내가 못 한 부분 : 실력이 많이 부족해서 웹사이트를 만드는데 많은 기여를 하지 못했다. 팀원들이 도와주신 부분들이 많았다. 다른 팀원들과 더 적극적으로 소통을 했으면 더 좋았을 것 같다고 느꼈다.

    • PM이 되었지만 PM 역할을 제대로 하지 못한 것 같다. 2차 스프린트 미팅을 하며 다음에는 더 잘 해야겠다고 생각했다.

    • 다음 프로젝트에서는 더 적극적으로 소통하고 시간관리 그리고 기록을 잘 해서 더욱 더 체계화되게 진행하고 싶다.

  • 송경용

    • 뿌듯했던 부분 - 개발자 커리어에서 첫 프로젝트였는데 결과물이 너무 이쁘게 잘 나오고, 프로젝트 진행하면서도 팀원들과 내내 밝은 분위기로 협업할 수 있어서 아주 기뻤다.

    • 아쉬웠던 부분 - 아무래도 역량부분에서 많이 떨어지는 상태였는데 나 혼자 그걸 매꾸려고 도움을 청하지 않고 최대한 혼자 해보려고 했다. 팀원분들의 배려로 겨우 결과물을 만들 수 있었지만 2차에서는 바로바로 블로커를 공유하고 해결해야겠다.

  • 박승민

    • 프로젝트를 처음 시작하며 Planning meeting 때 sprint 별 분량을 잘못 할당했다는 느낌이 너무 강했다, 첫주 스프린트를 수~목요일에 끝내고 다음 스프린트 티켓을 미리 가져와도 되는가에 대한 고민에서 그러지 않기로 했었는데, 애초에 첫주 스프린트에 할당된 분량이 너무 적었다고 생각한다.

    • 추가로 UI구현과정에서 여러 기능을 추가할 때 처음 사용해보는 기법이나 목표로했던 기능을 구글링으로 찾기 힘들었을 때 , 직접 구상하여 정말 무에서 유를 창조해서 기능을 구현했을 때 상당히 뿌듯했다, 그렇게 힘들게 구현한 기능에 대한 로직이라서 그런지 머리에 확실히 각인되었다.

  • 임채동

    • 일정 관리

      • 나에겐 { 1차 프로젝트 === 일정 관리 수습 기간 } 일 정도로 일정 관리가 아쉬운 점이다. 1차 스프린트에서 간단한 기능들을 구현하기로 티켓을 각자에게 배분하여, 모두 완성하고 역량을 모두 사용하지 못한 날이 이틀이나 되었다. 주말까지 포함하면 4일이나 되었다. 2차 스프린트의 티켓을 1차에서 사용하면 안될것이라 생각해서 티켓을 땡겨 오지 않은것이 실수였다.

      • 2차 스프린트 기간이 되니 1차에 비해 조금 더 작업량이 많은 티켓을 가져가게 되었고, 이로 인해 멘탈적으로 체력적으로 쉽지 않은 스프린트 기간이 되었다.

      • 다음 프로젝트 부터는 프로젝트 기간의 앞부분에 최대한 UI를 다 구현하고, 기능 구현도 해보는 방향으로 가야할것 같다. UI 다 짜두고 기능 픽스 하나씩 해나가는게 생산성이 훨씬 좋은 방향인것 같다.

    • 트렐로 사용

      • 티켓을 조금 더 세분화해서 올려야 할 것 같다. 그래야 진행 상황 공유가 더 잘될 듯.

      • UI 기능 따로 티켓 배분하고 등등 해야 할듯


BackEnd

  • 길성민

    • 좋았던 점
    1. 프런트분들이 필요한 데이터 정보를 정확하게 알려주셔서 response로 보내주어야 할 데이터를 어떤 구조로 보내드려야 할 지 빠르게 생각할 수 있어서 좋았습니다.

    2. 여러 팀 프로젝트를 많이 해보았지만 이번 프로젝트에서 최고로 소통이 잘되고 부족함이 잘 느껴지지 않을 정도로 원하는 기능들을 다들 잘 구현해주셔서 좋았습니다.

  • 아쉬웠던 점

    1. 프로젝트를 시작하는 초반에 프런트로 보내줄 데이터 형식과 변수명들을 정확하게 정하여 API문서를 먼저 작성하고 코딩작업을 수행하였다면, 더 빠르게 프로젝트가 진행되었을 것 같습니다.

    2. 데이터 구조(ERD)를 작성하는 과정에서 더 깊은 고민을 통해 정확한 구조를 작성하였으면, DB설계를 빠르게 했을 것 같습니다.

    3. AWS를 사용하지 못하였다는게 아쉽네요..

    4. 모듈을 사용하였다면 쿼리에 대한 스트레스와 가독성 좋은 코드 작성이 되었을 건데 아쉽습니다.

  • 문정진

    • 좋았던 점

      1. 팀 -> 팀 분위기가 너무 좋아서 부탁도 편하게 할 수 있고 서로서로 협력하자는 분위기가 너무 좋았다.

      2. 개인 -> 내가 만든 api를 실제 화면으로 볼 수 있어서 재밌었다

    • 아쉬웠던 점

      1. 팀 -> 데이터 양식 맞추기

      2. 개인 -> 초기세팅 잘하기

    • 배운 점

      1. 팀 -> 실제 통신을 하면서 배운 커뮤니케이션을 배웠다.

      2. 개인 -> 쿼리문과 서비스에러 상황에 대해서 배웠다.


마치며..

코딩을 공부하고 처음으로 진행해보는 팀프로젝트였다.

사실 우리조는 모든분이 맡은바 임무를 너무 잘 수행해주시고
제일 걱정이었다 백엔드와 프론트엔드의 소통 부분에서 차질이 전혀 없던
말 그대로 드림팀이었다.

원래 프로젝트의 기간은 공식적으로는 2주였지만.
우리 기수의 1차 프로젝트 기간의 첫 월요일은 광복절로사라지고..
첫날인 화요일은 프로젝트 초기셋팅 및 적응에 통째로 사라지고..
첫번째 주말은 서로의 스케줄이 어긋나서 협업이 없이 지나가고..
주번째주 금요일은 사실상 발표였기 때문에 준비 기간엔 포함되지 않았다.

사실상 프로젝트가 진행된 기간은 7일이 조금 넘는 기간이었다.

한가지 아쉬운점은 프로젝트가 전부 끝나갈 즈음에 조원분중 한분이
merge가 끝난 브랜치를 나중에 수정할 일이 생긴다면

fix/name 브랜치를 따로 생성해서 PR을 올리는것이 빠른수정에 도움이 된다고 알려주셨다.

확실히 PR 을 보는 입장에서 수정된 코드만 따로 볼 수 있기 떄문에
빠른 리뷰가 가능할 것같다.

2차 프로젝트가 다음주 월요일에 바로 시작되는데 적극적으로 활용해 볼 생각이다.

추가로 사소하지만 중요한 부분인데

merge 과정에서 제대로 네스팅되지 않은 scss 파일,곂치는 class명 등 예상치 못한 문제가 여러군데 에서 터져나왔을 때 대처하는 과정이 미흡하여 시간이 많이 뺏긴 감이 없지않아 있다..

이번 경험을 발판삼아 2차프로젝트, 이후에 실무에 나가서도 꼭 침착하게 대응해야겠다고 느꼈다.

profile
공부기록

2개의 댓글

comment-user-thumbnail
2022년 8월 28일

드림팀 보기 좋았습니다 ㅎㅎ 2차도 화이팅

1개의 답글