🍫 허쉬 프로젝트 회고록

🐾 들어가며

---

지난주 금요일에 프로젝트 발표를 마친 🔥러쉬코리아 클론 프로젝트🔥에 대한 회고를 시작해보려고 해요. 저희 4팀은 러쉬코리아의 LUSH를 HUSH로 변경해 샤워용품이 아닌 디저트류를 판매하는 사이트를 만들었어요(저작권 절대 지켜👊🏻). 러쉬와 발음이 유사한 허쉬(Hershey)초콜릿에서 영감을 받았답니다!

이렇게 프론트와 백이 모여 제대로 프로젝트를 진행한 건 처음이었기에 여러 방면에서 제 자신에 대한 부족함을 많이 느꼈고 그래서 배울 점이 참 많았던 첫 프로젝트였어요. 협업 방식, 일정 관리, 리액트 렌더링, 통신 등.. 모든 면에서요! 이번 1차 프로젝트를 회고하며 개선해야할 부분에 대해 정리하고, 더 성장한 모습으로 2차 프로젝트를 시작해보려고 해요!

📆 작업 기간

2주가 이렇게 짧았던 적이 있었나 싶어요. 정말 눈깜짝할 사이에 2주가 지나있었어요. 레이아웃이나 기능 구현은 1주차에 거의 마무리가 됐었고, 그 이후로는 코드를 수정/개선하고 통신하는 데에 시간을 보냈어요.

2주 (22년 09월 19일 ~ 22년 09월 29일)

🔨 기술 스택

프론트엔드 4명(강루비, 김대호, 양석문, 주혜린), 백엔드 3명(김정훈, 정승렬, 정다영)이 함께 프로젝트를 진행했어요.

Front-end

React, SASS
◽ CRA(Create-React-App)을 통한 리액트 개발 환경 세팅
◽ 함수형 컴포넌트 사용
◽ ESLint, Prettier 설정

Back-end

Node.js, Express.js, MySQL

co-work

Github, Slack(소통), Trello(일정관리), Notion(회의록)

✅ 일정 관리

일정 관리는 Trello를 사용했어요. This sprint에는 이번 주까지 해야할 일을, In progress는 지금 진행 중인 작업을, In Review는 PR을 올리고 리뷰를 받고 있는 작업을, Done은 리뷰까지 반영돼 merge완료된 작업을 올렸어요. 레이아웃 구현과 기능 구현은 다른 티켓으로 나누어 올려 구분지었답니다.

아쉬운 점이 있다면, 기능 구현하기에 급급해 업데이트된 내용을 반영하지 않은 날도 있다는 것이었어요. 지금이야 도착하면 팀원들이 가까이 모여 프로젝트를 진행하지만, 현업에 가면 재택을 하는 것과 같이 서로의 상황을 제대로 알 수 없을 수 있겠더라구요. 2차 프로젝트에는 매일 도착하자마자 Trello를 확인하고 업데이트/관리하는 것을 기본 중의 기본으로! 가져가고자 해요.

Trello로 일정 관리를 하기는 하지만, 아날로그틱한 갬성으로 계획짜는 것을 좋아하는 저는 그 날 그 날 해아할 일이나 기억해야할 사항을 적어놓는데 플래너를 사용했어요. 하지만, 이런 플래너는 저만 알 수 있기 때문에 최대한 Trello에 더 디테일한 내용을 쓰고자 노력해야겠단 생각이 들어요.
(노트에 떨어져 있는 자국은 코피 자국이었으면 좋았겠지만..커피 자국..☕코피 자국이 되는 그날까지..🏃🏻‍♀️)

✨ 주요 구현 기능

---

저희 팀 프론트는 페이지별로 나눠 담당했어요. 저는 색으로 표시한 것과 같이 회원가입, 로그인, 장바구니, 찜목록을 담당해 구현했답니다.

1. 회원가입, 로그인

• 이메일 중복 확인
• 비밀번호 유효성 검사

2. 메인 페이지

• nav, footer
• 이미지 슬라이드
• 애니메이션 효과

3. 제품 페이지

• 카테고리탭 별 이동
• 페이지네이션
• 가격 필터링(높은 순, 낮은 순)

4. 상세 페이지

• 수량 조절
• 상품 후기 작성
• 메뉴탭 이동

5. 장바구니 페이지

• 장바구니 목록 불러오기
• 제품 단일 선택/전체 선택 주문
• 제품 단일 선택/전체 선택 삭제
• 수량 조절
• 제품 합계 금액

6. 찜 목록 페이지

• 찜 목록 불러오기
• 제품 단일 선택/전체 선택 삭제

7. 결제 페이지

• 결제 상품 불러오기
• 주문자 정보 불러오기
• 배송 메시지 저장

👩🏻 내가 맡은 기능

---

1. 회원가입

회원가입 시, 이미 회원가입 된 이메일은 사용할 수 없도록 중복 확인 기능을 넣어주었어요. 중복 확인을 하지 않고 회원가입 버튼을 누르면 중복 확인을 하라는 alert창이 뜨도록 만들어주었답니다.

잠깐!🖐🏻 기억에 남는 코드가 있다면?

중복확인을 했는지, 안했는지를 isCheckEmail이라는 state로 관리해주었어요. 그래서 중복 확인하는 API요청에서 성공 메시지를 받으면 isCheckEmail을 true로 바꿔주었고, 그렇지 않으면 false로 바꿔주었죠.

const [isCheckEmail, setIsCheckEmail] = useState(false);

그리고 최종적으로 회원가입 form을 제출할 때 isCheckEmail이 true일 때는 회원가입 데이터를 서버에 보냈고, 그렇지 않을 경우에는 alert를 띄웠어요. 아래와 같이 if...else문을 사용했죠.

const submitForm = e => {
  if (isCheckEmail) {
    fetch('http://000.000.000.000:3001/user/signup', {
  	  // 생략  
  	});
  } else {
    alert('이메일 중복을 확인해주세요.');
  }
};

코드 리뷰를 받으며 if...else문보다 직관적으로 작성할 수 있는 법을 알게 되었어요. 이메일 중복 확인에 실패하면 바로 alert를 실행하고 return함으로써 함수를 끝내버리는 방법이었죠! 이메일이 중복된 경우라면 쓸데없이 if문의 긴 코드를 읽어내려갈 필요가 없으니 미리 끝내버리는 효율적인 코드라고 생각했어요.

const submitForm = e => {
  if (!isCheckEmail) {
    alert('이메일 중복을 확인해주세요.');
    return;
  }
  fetch('http://000.000.000.000:3001/user/signup', {
  	// 생략  
  });
};

2. 로그인

이메일이나 비밀번호를 다르게 작성했을 때, 그에 맞는 alert창을 띄워주었어요.

잠깐!🖐🏻 기억에 남는 코드가 있다면?

요청에 대한 응답 메시지에 따라 access token을 저장하거나 alert창을 띄우게 만들고자 했어요. if...else if로 나누어주면 되겠다고 생각해 아래와 같이 나누어주었죠.

if (data.message === 'ACCESS_SUCCESS') {
  localStorage.setItem('accessToken', data.accessToken);
  alert('로그인 성공');
} else if (data.message === 'WRONG_EMAIL') {
  alert('이메일 다시');
} else if (data.message === 'WRONG_PASSWORD') {
  alert('비밀번호 다시');
}

하지만, 아까 기억에 남는 코드 첫번째의 경우와 같이 if...else if로 코드를 쭉 나열할 필요가 없었어요. 만약 로그인 성공이라면 바로 return함으로써 쓸데없이 밑의 코드를 읽어갈 필요가 없게 할 수 있었죠.

if (data.message === 'ACCESS_SUCCESS') {
  localStorage.setItem('accessToken', data.accessToken);
  alert('로그인 성공!');
  navigate('/');
  return;
}
if (ERROR_MSG[data.message]) {
  alert(ERROR_MSG[data.message]);
  return;
}
alert('로그인 실패!');

또한, 에러 메시지 같은 경우는 아래와 같이 상수 데이터로 관리해줄 수 있어요.

const ERROR_MSG = {
  WRONG_EMAIL: '이메일을 다시 작성해주세요.',
  WRONG_PASSWORD: '비밀번호를 다시 작성해주세요.',
};

3. 장바구니

장바구니에 담긴 상품 목록을 불러와 수량을 조절하고 선택 주문 및 삭제가 가능한 장바구니 페이지를 만들었어요. 이 페이지를 만들며 정말 다양한 어려움이 있었고, 그래서 배운점 역시 많았어요.

⚡ 어려움1. setState()는 비동기적으로 처리된다는 것

첫 번째 어려움은 checkbox로 선택한 상품을 배열에 담는 데에서 생겼어요. 해당 배열을 state로 관리해주었었기 때문에, 선택 상품을 클릭하면 setState로 배열에 상품을 추가해주었죠. 이 때, 저는 setState가 실행되는 별도의 함수 안에서 console로 배열에 담긴 상품을 확인했어요. 그랬더니 한 박자씩 느리게 상품이 담기는 것을 확인할 수 있었죠.

setState와 같은 state 변경함수는 비동기적으로 처리된다는 사실을 인지하고 있지 못해 엄청 헤맨 경우였죠. setState는 비동기적으로 처리되기 때문에 setState가 실행되자 마자 state가 바로 변경되는게 아닌데 말이에요. 해당 setState가 오래 걸리는 작업이면, 밑의 다른 코드부터 실행한다는 것 잊지 않기!

⚡ 어려움2. 데이터를 불러오기도 전에 화면이 그려지는 것

이 문제는 통신을 하며 알게 됐어요. 제품 상세페이지에서 상품을 장바구니 페이지에 담으면, 바로 담기지 않는 문제였죠. 어떨 때는 바로 담기기도 했구요. 한 템포가 느렸어요. 장바구니에 담긴 데이터를 불러오는 것보다 화면이 먼저 그려지기 때문에 발생한 문제였어요.

제품 상세페이지에서 상품을 장바구니에 담으면 alert창💥을 띄워주자 문제가 해결됐어요. alert창으로 인해 데이터를 불러오는 시간이 생겨 해결된거였죠. 다음 프로젝트 때는 데이터를 불러올 때 loading중이란 것을 알 수 있도록 UI를 보여주도록 구현해보고 싶어요.

4. 찜목록

장바구니와 동일하게 단일 선택/전체 선택 삭제가 가능한 찜 페이지를 만들었어요.

잠깐!🖐🏻 기억에 남는 코드가 있다면?

처음 찜목록을 받아올 때와, 품목을 삭제했을 때, 이렇게 2번 찜목록 데이터를 fetch요청을 받아와요. 그래서 각각의 경우에 모두 동일한 fetch 요청 코드를 작성했었답니다. 그런데 코드 리뷰를 통해 해당 fetch요청을 함수로 묶어 사용해주면 된다는 것을 알게됐어요. getData라는 함수로 묶어 재사용해주었답니다!

const getData = () => {
  fetch('http://000.00.00.0:3000/user/like', {
    headers: {
      authorization: accessToken,
    },
  })
    .then(response => {
      // 생략
    })
    .then(data => {
      setProductData(data.likes);
    });
};

느낀점

---

👍🏻 잘한 점

# 소통
통신을 하는 과정에서 변경사항이 있거나 맞추면 좋겠는 부분이 있으면 지체없이 대화해 조율했다는 점이 잘한 점이라고 생각해요! 예를 들어, 장바구니에서 수량을 조절했을 때 서버에 조절한 수량 자체를 전달할 수도 있고, +1인지 -1인지만을 전달할 수도 있었어요. 어떻게 전달하고 받을것인지에 대해 맞춰보아야 했죠. 이런 부분에 있어서 서로 감정 상하는 일 없이 소통하고자 노력했고, 그 결과 통신까지 잘 이어질 수 있었단 생각이 들어요

그리고 소통의 연장선상에서 깨달은 점이 있다면, 설명의 중요성이에요. 제가 요청하고 싶은 데이터가 있다면 왜 필요하고 어떻게 사용할 것인지 대해 명확히 알고 백엔드분께도 충분히 납득할 수 있게 설명할 수 있어야함을 느꼈어요. 누구나 알아들을 수 있게 설명할 수 있는 능력을 키우자는 다짐을 합니다🤗

🤔 아쉬운 점과 개선방법

# 초기세팅
초기세팅을 성급하게 했다는 점이 아쉬워요. 공통으로 적용할 style들을 중간에 수정하고 추가하는 일도 생겼고, ESLint 경고메시지가 계속 뜨는 번거로움도 있었어요. 팀원들이 clone 받아 작업을 진행할 때 이러한 이유로 작업이 지체되는 일이 없도록 초기세팅을 꼼꼼하게 체크할 생각이에요.

또, 저는 branch 속에 branch를 만들어 각 branch의 commit이 합쳐진채 PR이 올라간 현상을 보기도 했답니다,,저 아래 이미지의 초록 가지가 보이시나요😖 결국 이렇게 branch에서 가지쳐진 branch들을 삭제하고 다시 master에서 branch를 만들고 push해서 해결할 수 있었어요. 깃허브 commit 이력이 꼬이지 않게 꼭 신경쓰기!

# 스케줄 관리
코드 리뷰를 받고 merge되는 시간까지 고려해서 스케줄을 짜지 못했어요. 기능 구현만 하면 된다고 생각했었죠. 2차 프로젝트 때는 코드 리뷰를 받고 수정해 merge되는 시간까지 고려할 생각이에요. 그러기 위해서 기능 구현을 최대한 빨리 마무리해 리뷰를 받고 수정/보완해나갈 생각입니다!

# 렌더링
React 렌더링에 대한 부분을 꼼꼼하게 고려하지 않아서 막상 전체 통신을 했을 때 한 템포 느리게 데이터를 보여주는 일이 많았어요. 개별 통신때는 잘 구현되었기에 더 멘붕이었던 것 같아요. 기능 하나하나에 집착하느라 큰 그림을 보지 못한거라고 생각해요. 사전에 이에 대한 부분을 충분히 고려해 코드를 짜야겠다는 다짐을 해봅니다🤧

# 나홀로 갇혀있지 말기
잘 구현되지 않는 기능이 있을 때, 혼자서 끙끙거리는 시간이 너무 길었던 점이 아쉬워요. 이걸로 기능 구현에 걸린 시간이 제 예상보다 좀 더뎠던 것 같아요. 프로젝트 기간이 짧았기 때문에 도저히 안되겠단 판단이 서면, 함께 고민해 빠르게 해결할 수 있었을텐데 말이에요. 뭔가 조금만 더 하면 구현될거같단 생각이 컸던 것 같아요😩 내가 맡은 파트는 도움 없이 내가 책임지고 해결해내야한단,, 그런 생각,,?

다음 프로젝트 때는 나홀로 갇히지 않으려구요! 잘 해결되지 않는 부분이 있다면 어떻게 하면 해결할 수 있는 지에 대해 충분히 공유하려고 해요.

마치며

---

팀원분들과 함께라서 마지막까지 힘내서 프로젝트를 잘 끝마칠 수 있었어요🎉 2주 동안 계속 달리니 2주차 막바지 가서는 체력적으로 쉽지 않더라구요ㅠㅠ 그런데 서로 잘 되지 않는 부분이 있으면 도와주기도 하고 도움받기도 하며 같이 으쌰으쌰한게 큰 힘이 됐던 것 같아요. 그리고 먹는거에 진심인 팀원분들을 만나 중간중간 맛난 식사하며 에너지 충전할 수 있어 넘 좋았습니당(◍ᐡ₃ᐡ◍) 역시 한국인은 밥심..!🍚

이제 내일부터는 2차 프로젝트 시작이에요. 기대가 되면서 어떤 어려움이 기다리고 있을지 무섭기도 하지만!!!!! 그러한 어려움이 절 더 강하게 만드리라 믿습니다~!~! 다 덤벼~!~!👊🏻 내일을 시작으로 2주 뒤의 저는 또 어떤 모습으로 성장해 있을지 둑흔둑흔 설레는 마음으로,,회고를 마칩니다💞