👉 데모 영상 전체보기
👉 웹 사이트 방문
프로젝트 소개
WASH KOREA
- WASH 제품 판매 및 구매 서비스 제공
- 스파 트리트먼트 안내 및 예약 서비스 제공
- 구매자들의 별점 및 후기 제공
- 가장 많이 찾는 제품군 검색 기능 제공
개발 인원 및 기간
- 개발기간 : 2021/11/1 ~ 2021/11/12
- 개발 인원 : 프론트엔드 3명, 백엔드 2명
- Frontend github 링크 : https://github.com/wecode-bootcamp-korea/26-1st-WASH-Korea-frontend
- Backend github 링크 : https://github.com/wecode-bootcamp-korea/26-1st-WASH-Korea-backend
프론트엔드 필수구현사항
- 회원가입, 로그인 기능
- 제품 카테고리별 리스트 - 카테고리 필터링 기능, 가격순 정렬 기능
- 제품 상세 페이지 - 카테고리별 페이지 이동 기능, 구매수량 반영 버튼, 탭 메뉴 스크롤 버튼, 리뷰작성 기능
프로젝트 Wrapup
내가 맡은 기능 : Navigation Bar / ProudctDetail Page
✔ Navigation Bar
- MouseEnter/Leave 이벤트를 이용한 메뉴 dropdown 기능 구현
- '제품'이 아닌 대메뉴에서는 SubMenu를 노출시키지 않도록 구현
- Link를 활용하여 세부 카테고리 메뉴를 클릭시 해당 페이지로 연결 기능 구현
- 상수데이터, map()를 활용한 코드의 간결화 및 가독성을 높이는 작업 진행
✔ Product Detail Page
- 적절한 컴포넌트화로 가독성 높임
- 상단 카테고리 필터링 기능을 통해 카테코리 click시 해당 페이지로 이동 기능 구현
- 구매 수량 버튼 클릭시 수량 반영 및 수량에 따른 가격 변동 기능 구현
- Back-end에서 넘겨받은 API 주소를 Path Parameter를 이용하여 특정 상품 클릭시 ProductDetailPage로 이동하도록 기능 구현
- 리뷰 기능 headers에 token을 담아서 인증된 사용자만 리뷰를 작성할 수 있도록 구현
- 리뷰 기능 POST/GET 방식을 활용하여 리뷰를 작성하고 버튼을 클릭 했을 때 작성한 리뷰 노출 기능 구현
- Git의 workflow를 익히고, 협업하는 기술
- Git을 통한 협업 과정에서 발생하는 Conflict 해결 능력
✔ Others
AWS 프론트 배포
Code Review
✔ 프로젝트 코드 리뷰
Code Review (1) : Navigation Bar
Code Review (2) : Product Detail Page UI
Code Review (3) : Fetch를 활용한 API 통신
프로젝트를 진행하면서
개인적으로 우리팀은 정말 화목한 팀이라고 자부할 수 있다. 백엔드와의 소통이 정말 잘 됐기 때문이다.
백엔드 팀원분들이 항상 프론트의 의견을 물어보고, 프론트 역시 백엔드에게 계속해서 물어보고, 데이터를 가져오는 형식에 대해 함께 고민하면서 문제를 해결해나가는 과정이 정말 재미있었다.
프로젝트를 마치며..
1차 프로젝트를 수행하면서 느낀 점은 확실히 프로젝트라는 하나의 이름으로 다양한 사람들과 협업했을 때 나오는 다양한 생각들과 커뮤니케이션은 내가 생각했던 것보다 컸다.
솔직하게 말하자면, 나만 잘하면 될 줄 알았다.
각자의 역할만 주어진 기간에 하면 되는거 아닌가? 라고 생각했다.
그게 다가 아니였다. 서로간의 끊임없는 소통이 필요했고, 각자의 속도가 다른 만큼, 주어진 기간에 필수구현을 하기 위해서는 함께 협업하여 프로젝트를 수행할 수 있어야 했고, 예상했던 것에서 벗어나는 변수들이 많았다. (Conflict 이슈, React 오류, 통신 오류 등)
곧 진행할 2차 프로젝트를 앞두며 몇 가지 다짐을 해보았다.
-
밸런스 관리는 확실하게 하자
한 가지에 온전히 몰입하는 것이 아주 중요하다. 그 만큼 쉬는 것도 중요함을 깨달았다. 너무 한가지에만 매몰되어 있어서 집착아닌 집착을 하게 되면, 할 수 있는 것도 더 뜻대로 되지 않음을 느꼈다. 항상 적절한 휴식시간을 가지기로 다짐한다. -
간단하게라도 오늘 한 일, 내일 할 일, Blocker에 대해서 잘 정리해두자
1차 프로젝트 때는 Trello 활용을 너무 못했다. 거의 사용하지 않았기 때문에 무용지물이라고 해도 무방할 정도이다.
Tool를 적절하게 활용하는 것도 개발자의 역량이라고 했다. 2차 프로젝트부터는 개별 진행상황을 세세하게 작성할 예정이며, 매 회의마다 Meeting Log도 작성하고, 매일 Frontend 끼리 혹은 Frontend와 Backend가 함께 소통했던 내용들을 요약하거나 블로그를 활용해서 기록할 계획이다. -
기능구현에 너무 집착하지 말고, 하나를 알더라도 완벽하게 알도록 할 것
1차 프로젝트를 진행하면서 제대로 개념정립이 안된(life cycle, fetch)것들을 붙잡고 혼자서 어떻게든 해보겠다고 4일 내내 끙끙댔던 기억이 있다.
결국 멘토님과 동기들의 도움을 받아 어찌저찌 꾸역꾸역 하기는 했지만, 이것이 온전히 나의 코드라는 생각이 들지는 않는다.
차라리 확실하게 코드를 뜯어서라도 이해하도록 노력하고 그 내용들을 블로그에 기록하는 방법등을 이용해서 리마인드 한 후에 기능구현에 들어가보자. 이렇게 하면 기능구현 시간이 훨씬 단축될 것이라는 생각이 들었다. -
더 적극적인 소통을 하자
팀프로젝트는 말그대로 나 혼자하는게 아닌데, 너무 내 기능 구현에 집착하느라 팀원들의 진행 상황이라던가 Blocker를 좀 더 함께 고민했으면 좋았을 걸.. 이라고 생각했다.모두 으쌰으쌰 할 수 있도록 서로에게 기운을 주는 것도 팀원으로서의 역할이지 않을까 생각해본다. 팀원 중 유독 마음 고생을 했던 분이 있다. 좀 더 함께 고민을 해보지 못했던 것에 대한 아쉬움이 크다. 함께 고민하고 해결해나가는 과정 또한 배움의 일원이라고 생각한다. 앞으로 더 협업하는 모두와 적극적 소통을 하기 위해 노력하겠다.
-
스스로 해결해낼 수 있는 능력을 기르자
코드를 작성하는데 있어서 너무 안풀리니까 나중에는 거의 타인의 도움을 기대하고 바랬던것 같다.
그럴때마다 멘토님께서 따끔하게 정신을 차리게 해주셨던 기억이 난다."이러한 오류를 하나하나 스스로 해결해 나가는 과정을 깨우쳐야 실력이 상승할 수 있다. 오류가 발생하면 어느 부분에서부터 발생했는지 확인해서 거슬러 올라가는 과정, 그 과정을 스스로 터득하는것이 중요하다"
처음에는 console을 어디에 쳐야 하는지 조차 몰랐던 기억이 난다. 그래도 이제는 다른 동기들, 그리고 멘토님들의 조언을 적극적으로 반영해서 여기저기 내가 원하는 데이터 값이 잘 나오는지 확인도 해보고, 이를 통해 오류를 수정해보기도 했지만 여전히 나에게는 어려운 과제인 것 같다.
2차 프로젝트 때는 오류가 발생했을 때 조급해 하지말고, 차분하게 대처하자!
-
질문은 구글링 20번은 해보고, 그 다음 일목요연하게 하자
프로젝트를 진행하면서 구글이든, 멘토님이든, 동기분들이든 어느 누구에게나 질문할 때 친절하게 질문하는 사람이 되어야 겠다고 생각했다. 두서 없이 정리가 안된 상태로 질문을 하게 되다보니 나도 내가 무슨 말을 하는지 모르겠고, 듣는 사람도 난처한건 당연한 일이다. 아주 불친절한 질문자가 될 수 밖에 없다...
회고를 하면서 어떻게 하면 질문을 더 잘 할수 있을까 고민해보았고 다음과 같은 규칙을 세워서 질문하기로 했다.① 어떤 flow에 따라 어느 기능을 구현하고 있었는지 정리하기
② 오류가 발생한 원인 찾기 (원인을 못찾을 경우 오류 자체를 검색해보기)
③ 이 기능 구현에 필요한 원론적인 개념을 알고 있는지 스스로 진단하기
④ 오류를 해결하기 위해서 어떠한 방법을 시도했고, 어떻게 검색해서 어떤 힌트를 얻었는지 정리하기
⑤ 힌트 또는 해결책을 얻은 부분을 적용해보아도 구현이 되지 않을 경우 (1~5번까지 정리해서) 질문하기이렇게 일목요연하게 질문한다면 친절한 질문자가 될 수 있고, 서로에게 보다 명확한 시사점을 제공할 수 있을 것이다. 운이 좋으면 1번부터 5번까지 수행하는 과정에서 스스로 답을 찾을 수도 있을 것이다!
앞서 말한대로 기능구현에 집착해서 급하게 무언가를 해결하려고 하지 말고 차근차근 step을 밟아가며 생각하는 능력을 쌓아보자!
