GitHub README.md

깃허브

https://github.com/Mjj4682/36-1st-TabomGalagsin-backend

시연영상 LINK

👉화면을 클릭하면 영상으로 이동합니다.

클론 사이트 : 하바이아나스 https://havaianas.com.br/

팀원 소개 (가나다 순)

• FE

  박승민

  메인 페이지, 장바구니

  송경용

  로그인/회원가임

  임채동

  메인 페이지, 상품 목록 페이지

  최슬기

  NavBar, 상품 상세 페이지

• BE

  길성민

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

  문정진

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

기술 스택

• FE

• BE

ERD

API Documentation

API Documentation

프로젝트 회고록

• 길성민
  • 좋았던 점
    1. 프런트분들이 필요한 데이터 정보를 정확하게 알려주셔서 response로 보내주어야 할 데이터를 어떤 구조로 보내드려야 할 지 빠르게 생각할 수 있어서 좋았습니다.
    2. 여러 팀 프로젝트를 많이 해보았지만 이번 프로젝트에서 최고로 소통이 잘되고 부족함이 잘 느껴지지 않을 정도로 원하는 기능들을 다들 잘 구현해주셔서 좋았습니다.
  • 아쉬웠던 점
    1. 프로젝트를 시작하는 초반에 프런트로 보내줄 데이터 형식과 변수명들을 정확하게 정하여 API문서를 먼저 작성하고 코딩작업을 수행하였다면, 더 빠르게 프로젝트가 진행되었을 것 같습니다.
    2. 데이터 구조(ERD)를 작성하는 과정에서 더 깊은 고민을 통해 정확한 구조를 작성하였으면, DB설계를 빠르게 했을 것 같습니다.
    3. AWS를 사용하지 못하였다는게 아쉽네요..
    4. 모듈을 사용하였다면 쿼리에 대한 스트레스와 가독성 좋은 코드 작성이 되었을 건데 아쉽습니다.
• 문정진
  • 좋았던 점
    1. 팀 -> 팀 분위기가 너무 좋아서 부탁도 편하게 할 수 있고 서로서로 협력하자는 분위기가 너무 좋았습니다. 팀원 개인 개인에 실력이 뛰어나서 더욱 완성도 있는 결과물을 만들어 낼 수 있었습니다.
    2. 개인 -> 개인 프로젝트에서는 할 수 없었던 실제 사이트를 프런트엔드와 같이 만들어 낼 수 있어서 좋았습니다. 제가 만든 API를 실제 결과물로 볼 수 있어서 좋았습니다.
  • 아쉬웠던 점
    1. 팀 -> 처음에 맞췄던 데이터 양식이 바뀌면서 코드를 처음부터 작성했던 경험이 있는데 어쩔 수 없는 상황이었지만 처음부터 맞췄다면 더욱 생산적이고 효과적인 프로젝트가 될 수 있었다고 생각합니다.
    2. 개인 -> 처음 테이블 구조를 잘못 설계했는데 나중에 많은 어려움이었습니다. 테이블 구조와 초기 세팅에 중요성에 관해서 알게 되었습니다.
  • 배운 점
    1. 팀 -> 팀 프로젝트가 처음이었는데 실제 통신을 하면서 커뮤니케이션을 배웠습니다. 여러 명이 하나의 결과를 보고 달려가는 경험을 하면서 스프린트에 중요성에 관해서 알게 되었습니다.
    2. 개인 -> 복잡한 쿼리 문과 테이블, API를 다루면서 코딩 실력을 높일 수 있었습니다. 에러 핸들링을 하면서 에러 상황에 대해서 배울 수 있었습니다.
• 최슬기
  • 내가 잘 한 부분 : 스텐드업미팅 회의를 주도하였다.
  • 내가 못 한 부분 : 실력이 많이 부족해서 웹사이트를 만드는데 많은 기여를 하지 못했다. 팀원들이 도와주신 부분들이 많았다. 다른 팀원들과 더 적극적으로 소통을 했으면 더 좋았을 것 같다고 느꼈다.
  • PM이 되었지만 PM 역할을 제대로 하지 못한 것 같다. 2차 스프린트 미팅을 하며 다음에는 더 잘 해야겠다고 생각했다.
  • 다음 프로젝트에서는 더 적극적으로 소통하고 시간관리 그리고 기록을 잘 해서 더욱 더 체계화되게 진행하고 싶다.
• 송경용
  • 뿌듯했던 부분 - 개발자 커리어에서 첫 프로젝트였는데 결과물이 너무 이쁘게 잘 나오고, 프로젝트 진행하면서도 팀원들과 내내 밝은 분위기로 협업할 수 있어서 아주 기뻤다.
  • 아쉬웠던 부분 - 아무래도 역량부분에서 많이 떨어지는 상태였는데 나 혼자 그걸 매꾸려고 도움을 청하지 않고 최대한 혼자 해보려고 했다. 팀원분들의 배려로 겨우 결과물을 만들 수 있었지만 2차에서는 바로바로 블로커를 공유하고 해결해야겠다.
• 박승민
  • 프로젝트를 처음 시작하며 Planning meeting 때 sprint 별 분량을 잘못 할당했다는 느낌이 너무 강했다, 첫주 스프린트를 수~목요일에 끝내고 다음 스프린트 티켓을 미리 가져와도 되는가에 대한 고민에서 그러지 않기로 했었는데, 애초에 첫주 스프린트에 할당된 분량이 너무 적었다고 생각한다.
  • 추가로 UI구현과정에서 여러 기능을 추가할 때 처음 사용해보는 기법이나 목표로했던 기능을 구글링으로 찾기 힘들었을 때 , 직접 구상하여 정말 무에서 유를 창조해서 기능을 구현했을 때 상당히 뿌듯했다, 그렇게 힘들게 구현한 기능에 대한 로직이라서 그런지 머리에 확실히 각인되었다.
• 임채동
  • 일정 관리
    • 나에겐 { 1차 프로젝트 === 일정 관리 수습 기간 } 일 정도로 일정 관리가 아쉬운 점이다. 1차 스프린트에서 간단한 기능들을 구현하기로 티켓을 각자에게 배분하여, 모두 완성하고 역량을 모두 사용하지 못한 날이 이틀이나 되었다. 주말까지 포함하면 4일이나 되었다. 2차 스프린트의 티켓을 1차에서 사용하면 안될것이라 생각해서 티켓을 땡겨 오지 않은것이 실수였다.
    • 2차 스프린트 기간이 되니 1차에 비해 조금 더 작업량이 많은 티켓을 가져가게 되었고, 이로 인해 멘탈적으로 체력적으로 쉽지 않은 스프린트 기간이 되었다.
    • 다음 프로젝트 부터는 프로젝트 기간의 앞부분에 최대한 UI를 다 구현하고, 기능 구현도 해보는 방향으로 가야할것 같다. UI 다 짜두고 기능 픽스 하나씩 해나가는게 생산성이 훨씬 좋은 방향인것 같다.
  • 트렐로 사용
    • 티켓을 조금 더 세분화해서 올려야 할 것 같다. 그래야 진행 상황 공유가 더 잘될 듯.
    • UI 기능 따로 티켓 배분하고 등등 해야 할듯