본문 바로가기
D.evelop/Projects

[Team project] ⚾️BBADDA 💢 - 회고

by Danne 2021. 10. 18.

기존 MLB korea 사이트를 프론트엔드는 React백엔드는 Django/Python를 사용해 재구성해보았습니다.

BBADDA 팀 프로젝트

📆 진행 기간

2021.10.05 ~ 2021.10.15

 

 

💻 기술

Front-end

  • View : React
    • Build Tool : Create React App
    • Library : react-router-dom
    • Code Quality Tool : ESLint, Prettier
    • Sass

Back-end

  • Python, Django, MySQL
  • Infrastructure : AWS

 

🖇 협업 툴

  • VCS : Git & Github
  • Communication : Slack
  • Task Management : Trello

 

 

⚾️ 팀원별 역할

Front-end  github

  • 공통 CRA 초기 세팅
> LifeCycle과 fetch함수를 이용한 데이터 통신
> 전달 받은 data를 조건부 랜더링을 통하여 출력
> 상수 데이터 활용

 

  • 강단  - 제품 상세 페이지
    • 제품 id를 Path Parameter로 사용해 해당 id를 가진 제품 api에 정보 요청
    • 제품 옵션 선택 - 컬러/사이즈 선택기능, 수량 카운터 기능
    • 선택 된 값을 state값으로 저장하여 POST요청을 통해 백엔드 서버에 전달

 

  • 김경현 - 회원가입, 로그인 페이지, 주문 페이지
    • 디자인 패턴에 따른 컴포넌트 생성 및 재사용을 활용한 화면구성을 이용한 회원가입 
    • 로그인 JWT 토큰, Local / Session Storage 를 이용한 로그인 기능
    • 엑세스 토큰을 이용한 회원 인가, 데이터 정보 요청

 

  • 하상영 - 제품 리스트 페이지
    • 카테고리별 상품 filter하여 출력
    • 상품 선택 시 동적 라우팅(Dynamic Routing)을 통해 해당 제품 상세페이지로 이동
    • Path Parameter를 사용한 제품 id 전달

 

  • 홍승균
    • 공통 컴포넌트
      • Nav 컴포넌트 - 카테고리별 하위메뉴 출력
      • Footer 컴퍼포넌트
    • 메인페이지 - carousel 슬라이드 구현, 섹션별 filter에 따른 제품 출력
    • 제품 상세 페이지 추가 구현 사항 지원 - carousel 슬라이드 구현

 

 

Back-end  github

  • 구본욱 , 박현우
    • User, Product, Order 각각의 테이블 생성
    • Query Parameter를 활용한 정렬 기능 및 페이지네이션 기능 구현
    • Q객체를 활용한 메뉴 필터링 기능 구현
    • 주문 기능에 transaction을 적용하여 특정 부분에서만 발생하는 에러 방지

 


📝 목표

[유저🙋‍♂️A]
메인페이지 접속 => 회원가입 => 로그인 => 제품 리스트 확인 => 제품 상세정보 확인 => 제품 옵션 선택 => 주문 



 

 

✔️ 뿌듯했던 점

사용자가 사이트 접속 시 회원가입 ~ 주문까지 하나의 루틴을 돌아 데이터에 반영되는 것까지 구현한 거의 유일한 팀이었다. 팀원 모두가 서로 욕심나는 기능 구현 있었음에도 가장 중요한 기준으로 잡았던 one turn!에 있어 우선순위가 되는 것에 집중해서 완성도 있는 결과물이 나와 뿌듯했다.

 

 

🥲 가장 어려웠던 코드 (리팩토링 필요)

제품 수량 체크

  •  '+ / -' 에 따라 수량이 카운팅 바뀌는 것은 쉽게 풀렸다.
  • 하지만 다양한 경우의 수(문자 입력, 음수, 재고 초과 등)를 '키보드 입력/마우스 클릭' 두 가지 이벤트에 따라 설정하는 부분이 미흡했다.
    if문을 사용해 각 조건을 두었지만, 적용되지 않아 '+ / -' 카운팅 기능, 숫자입력 기능까지 구현까지 진행하게 되어 아쉬움이 남았다.
  constructor() {
    super();
    this.state = {
      amount: 1,
    };
  }

  quantityValue = e => {
    const { setSelectedSizeQuantity } = this.props;
    const { amount } = this.state;
    if (amount > 1) {
      this.setState({
        amount: parseInt(e.target.value),
      });
    }
    setSelectedSizeQuantity(this.state.amount);
  };

  checkNumber = e => {
    if ((0 <= e.key && e.key <= 9) || e.keyCode === 8) {
      this.quantityValue(e);
    } else {
      alert('숫자만 입력해주세요');
      this.setState({
        amount: 1,
      });
      return;
    }
    console.log(this.state.amount);
  };

  plusCount = e => {
    const { amount } = this.state;
    this.quantityValue(e);
    this.setState({ amount: amount + 1 });
  };

  minusCount = e => {
    const { amount } = this.state;
    this.quantityValue(e);
    if (amount > 1) {
      this.setState({ amount: amount - 1 });
    }
  };

 

 

✔️ 아쉬웠던 점

[props와 state의 구성을 조금 더 계획한 후 진행하지 못한 아쉬움]

하위 컴포넌트에서의 state값이 상위 컴포넌트에서 props로 사용되야할 때 멘붕이왔다.

결국 상위컴포넌트의 state값을 추가하여, 하위 컴포넌트의 state값과 동일한 값을 갖도록 구성해야하는 경우도 생겼다.

// 자식 컴포넌트 였던 QuantityOption컴포넌트
constructor() {
    super();
    this.state = {
      amount: 1,
    };
  }

  quantityValue = e => {
    // 선택된 수량을 담기위해 상위 컴포넌트에 state로 선언해 props로 다시 불러와
    const { setSelectedSizeQuantity } = this.props;
    const { amount } = this.state;
    if (amount > 1) {
      this.setState({
        amount: parseInt(e.target.value),
      });
    }
    // 이렇게 갱신된 값을 argument로 사용했다.
    setSelectedSizeQuantity(this.state.amount);
  };

 

 

 

🙆‍♀️ 성장한 점

우선 '눈에 보이는 건 금방 구현 할 수 있지'라고 자만하며 하드코딩으로 해결 → 반복/연산이 필요한 작업을 함수로 수정해가는 방식으로 진행했었다.

이렇게 진행하는 과정이 스스로도 비효율적이라고 느껴졌다. 복잡한 함수가 아닌데 굳이 두 번 씩 작업하고 있다는 생각과 그 시간에 내 로직을 좀 더 다듬을 수 있을 것같다는 아쉬움. 하드코딩의 습관이 내 발목을 잡는 느낌이었다. 지금 이 습관을 고치지 않으면 기회를 놓칠 것같은 압박도 있었다.

코드리뷰와 팀원들의 방식을 참고해가며 '일단 타이핑하지 말고 어떤 로직으로 작성하는 게 좋을지 생각해보는 시간을 가져보자'고 습관을 고쳐보기로 했다.

몇 번 반복하다보니 list형식과 같이 반복되는 컴포넌트를 배열데이터로 사용할 때, <li></li>의 나열보다 map함수를 사용하는게 익숙해졌다.

 

 

주어진 10일간.

매일 오전 모든 팀원이 스탠드 미팅을하며 이슈 사항과 테스크를 공유했다.

첫 플래닝 미팅이 완료되고 서로 역할이 주어진 뒤, 첫 주에는 프론트엔드 팀원들과의 교류에 집중하고 두 번째 주에는 백엔드 팀원들과의 교류에 집중했다. 

프론트엔드 팀원들과 서로 어느 부분에서 막히는지, 어떤 방식으로 해결했는지 공유하며 함께 성장할 수 있었고

백엔드 팀원들과는 '용어'부터 시작해 어떻게 데이터를 주고 받을지 공유하며 새로운 성장을 할 수 있었든 프로젝트였다.

반응형

댓글