ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 1차 프로젝트 회고:: converse 클론 프로젝트
    개발일기 2020. 8. 2. 22:57

    프로젝트 실시하는 2주간 약 3-4회 바뀌었던 메인페이지. 컨버스 디자인, 개발자팀 존경합니다👏🏻

    1차 프로젝트:: converse 클론 후기

     

    1. 프로젝트 소개


     

    1) 주제👆🏻

    • 전세계적으로 사랑받는 스포츠웨어 패션 브랜드 컨버스(Converse) 웹사이트 클로닝 👟
    • React.js와 Git, Trello로 협업하여 이루어진 두 번째 팀 프로젝트 (협업👨‍👩‍👧‍👦으로는 첫 번째 프로젝트)

     

    2) 개발인원 (프론트 3명, 백엔드 1명)

    • 프론트 3명 (김신영, 김효식, 이병수)
    • 백엔드 1명 (손수정)

     

    3) 개발기간 

    • 2020.07.20(월) ~ 2020.07.31(금)  약 2주 / 총 12일

     

     

     

    2. 사용된 기술


    1) 프론트엔드 👩🏻‍💻

    • JavaScript (ES6)
    • React.JS (첫 프로젝트로 리엑트 생명주기를 더 직관적으로 인식하기 위해 Class형 컴포넌트 사용)
    • React-Router
    • React-Slick
    • Sass

     

    2) 백엔드 👩🏻‍💻

    • Python, Django web framework
    • Bcrypt
    • jwt
    • MySQL
    • AWS EC2, RDS
    • CORS headers
    • Gmail smtp

     

    3) 협업 툴 🛠(클릭 시 사이트로 이동합니다 )

     

    4) 개발 방법론

    • Agile 방법론 ➿

     

     

    3. 사이트 주요 기능


    직접 구현한 기능은 ✅, 팀원이 구현한 기능은 ✔️로 표시했다.

     

    1) 회원가입, 로그인 페이지

    ✅로그인 기능 (id, pw 조건 구현) (Session Storage)

    ✔️회원가입 기능 (다중 조건 구현)

    ✔️회원가입 후 이메일 인증

     

    2) 메인페이지

    ✔️react-slick 이용한 광고 배너 슬라이드 구현

    ✅상단 메뉴 클릭 시 사이드바 드롭다운 구현

    ✅검색바 드롭다운 및 filter 함수 이용한 검색 기능 구현

    ✔️제품 태그가 담긴 인스타그램창 UI구현

    ✔️인스타그램 모달창 및 슬라이드 구현

    ✔️인스타그램 더보기 페이지네이션 구현

     

    3) 상품 리스트 페이지

    ✅사이드바 클릭 시 제목 별 필터 리스트 구현

    ✅검색 별 필터 리스트 구현

    ✅가격 별 제품 리스트 sort 구현

    ✅제품 색상별 이미지 변화

    ✅queryString 이용한 fetch 함수로 성별, 제품 타입, 사이즈, 컬러 별 다중 필터 리스트 기능 구현

    ✅scroll 위치에 따른 페이지네이션 구현 (로딩 페이지 포함)

     

    4) 상세 페이지

    ✔️다중 map함수를 활용한 신발 색상별 분류

    ✔️ 다른 색상 신발 클릭시 해당 색상 페이지 이동

    ✔️'더보기' 클릭시 해당 지점까지 scroll

    ✔️ 신발 사이즈 선택

    ✔️ 신발 사이즈 모달창

     

     

    5) 장바구니 페이지

    ✔️상품 페이지에서 담은 상품 장바구니와 연동시키기

    ✔️ 장바구니 품목 삭제

    ✔️ 백엔드 api와 연결하여 옵션 변경

     

     

     

    4. 기억하고 싶은 코드


    1) query String 이용한 다중 필터 [이후 추가]

     

    2) scroll 위치에 다른 페이지네이션 [이후 추가]

     

     

     

    5. 기록하고 싶은 에피소드


    1) 첫 경험한 Aglie 방식과 Trello 그리고 협업 🏃🏻‍♀️

    애자일 방법론의 필요성을 나타내주는 만화그림.

    애자일이 추구하는 가치는 “처음부터 완벽한 계획”이 아닌 “간소한 계획과 유연한 대처”이다.

    애자일 방법론을 사용하면 점진적으로 테스트 할 수 있어서 버그를 더 빠르게 발견 할 수 있고 수정과 변경에 유연하다는 장점이 있다.

     MVP (Minimum Viable Product) 최소실행 가능한 제품을 특징으로 하는 애자일 방법론은 지금 첫 협업 프로젝트를 하는 우리에게, 그리고 약 2주 정확하게는 12일간 프로젝트를 실행하는 우리에게, 얼만큼 구현 할 수 있는지 가늠할 수 없는 병아리 개발자에게 적절한 방법론이었다. 우리는 애자일의 방법론 중 하나인 스크럼 방식을 이용하였고 그 툴로 Trello를 활용했다. 

     

    스크럼 방식은 sprint라는 짧은 주기 목표와 daily standup미팅을 잘 활용해야한다. 

    짧게 짧게 지금 서로 하는 일과, 도움이 필요한 일, 완료한일 등을 체킹하는 것이다. 

    멘토님께서는 이 데일리미팅이 별것 아닌 것처럼 보이지만, 실제로 이 데일리미팅을 얼마나 잘하냐에 따라서 스크럼방식의 완성도가 다르다고 말씀하셨다. 미국 어떤 회사에서는 실제로 프랭크를 하면서 daily standup 미팅을 활용하는 곳도 있다고 한다. (짧은 daily형식을 지키기 위해!)

     

    이번 첫 프로젝트 때 우리는 점심먹기 전 12시를 우리의 데일리 미팅 시간으로 잡았고, 짧은 회의 후 함께 점심식사를 하며 서로 교제하는 시간도 가졌다. 이 것이 우리가 첫 planing meeting 때 계획했던 목표들 보다 더 많은 것을 완수하게 된 주된 원동력이 아니었을 까 생각된다.

    trello로 서로의 업무를 체크하면서 진행사항을 보았고 서로 겹치는 구현사항들을 체크하면서 도움을 줄 수 있었다.

    그리고 내가 맡은 업무가 끝났을 때 앞으로 진행해야할 2차 sprint 목표도 바로바로 진행 할 수 있었다.

     

    우리 팀이 사용한 Trello의 흔적

     

    다만 스크럼 방식의 조금 아쉬웠던 부분은 처음 우리가 목표로 두엇던 첫 목표들(기본적인 기능들)을 완료하고 추가적인 목표를 수행하려고 보니, 추가적인 기능을 구현하려면 이전에 완료했던 기능들을 수정해야하는 일이 발생해 두번 일을 해야했다.

     

    이것은 아마도 우리가 (실은 내가.. ) 스크럼 방식을 처음으로 사용하다보니 고려하지 못했던 부분인 것 같다.

     

    2차 때는 이 부분까지 고려해서 목표를 짜보는게 좋겠다는 생각이 들었다. :) 

     

    아직 병아리 개발자여서 그런지.. 나의 개발 능력과 속도가 잘 가늠이 되지 않는 나에게는 에자일 방식의 데일리 미팅으로 본인 뿐 아니라 팀원들의 업무파악도 쉽게 할 수 있었으며, 작은 목표를 이루는 것에 대한 성취감도 느낄 수 있었던 방법론 이었다. 

     

     

     

    2) 잘한 점 💁🏻‍♀️

    2-1. 리엑트JS와 친해지기 

    프로젝트 시작 전, 나는 멘토님과 동료들에게 여러번 말했었던 것 같다.

    "이걸.. 제가 2주 배운 리엑트로.. 할 수 있을 까요?"

     

    바닐라 자바스크립트로 만들었던 인스타그램 클론 코딩을 리엑트로 변경하면서 리엑트 구조를 이해하기 위해 꽤나 애를 먹었던 터라, 

    이번 프로젝트의 개인적인 목표는 리엑트로 웹사이트를 만드는 전체적인 구조와 흐름을 능숙하도록 이해하는 것이었다. 

     

    "아니, 어떻게 하나의 html에서 모든 페이지들을 렌더할 수 있다는 거지?"

     

    인스타그램 클론 코딩을 한 후에도 머리로는 이해가 되는 듯했지만... 가슴으로 와닿지가 않았다.

    팀원들과 함께 CRA 초기세팅을 하고, 페이지들을 맡아서 컴포넌트를 재사용하고, 

    각 페이지를 Route를 활용해 구현해 보면서 조금씩 이해가 되는 듯했다. 

     

    그러나 url parameter를 활용하는 순간 그 어설픈 이해가 와장창 깨지는 기분이었다. 🙇🏻‍♀️

    url parameter를 하면서 Link 를 사용하는 경우, Router를 사용하는 경우, withRouter를 사용해야하는 경우 총 정리하면서 

    헷갈렸던 url 개념, fetch 개념, 리엑트의 각 페이지 구조 등을 이해할 수 있었다. 

     

    2주간의 시간이었음에도 불구하고, 확실히 애매모호 했던 리엑트 구조 개념을 다잡고, 나아가서는 ComponentDidMount, ComponentDidUpdate, ComponentWillunmount등 생명주기도 활용해보며 리엑트와 좀 더 친해진 것 같다. :) 

     

     

     

    2-2. '비교'는 이전의 '나'와. 코딩은 동료와 함께 즐겁게.

    개발을 하다보면( '부트캠프'에서 개발을 배우다보면) 나의 실력을 '타인'의 것과 비교하기 마련이다. 

    그러다보니 내가 구현한 기능에 흡족하는 것도 잠시, 화려한 기능들을 구현한 옆 동료를 보면 움츠려들게 된다. 

     

    그럴때 스스로 되뇌었던 " '이전의 나'와 비교하자" 마법은 효과가 있었다. 

    더 많은 기능 구현에 욕심내기보다 현재 내 충실함과 성실함을 인정해주었다. 

    그러다보니 '스트레스'보다 "잘하고 있구나", "즐겁다"는 생각이 들었다. 

     

    그리고 그런 에너지는 동료팀원들과의 관계에도 영향을 끼치는 것 같았다. 

    내가 즐겁게 코딩하고 있어야 동료들과도 긍정적인 상호작용을 할 수 있었다. 

    그리고 실제로 즐거웠다.🙆🏻‍♀️

     

    이 부분은 사실 동시에 아쉬운 점이기도 한데, 

    개발기간 종료가 가까워지면서는 다른 팀의 완성도와 비교하면서 나도 목표한 것을 완성하기 위해 이미 구현한 것들에 대한 완성도와 리팩토링에 더 집중하지 못하기도 했다. 그리고 의도하진 않았지만 그런 조급함이 타 팀원들에게도 영향이 끼쳐지지 않았을 까 반성되는 부분이기도 하다. 

     

     

    3) 아쉬운 점 🤦🏻‍♀️

    3-1. 적절한 소통은 속도에 '날개'를 달아준다.

    12일 중 첫 주말을 맞이했던 때, 주말의 2틀을 고생했는데 그게 백엔드와의 소통으로 단 30분만에 해결되었던 일이 있었다.

    상품 리스트 페이지에서 제품의 컬러별 main-img와 sub-img를 보여주어야 하는 부분이었는데, 

    당시 백엔드 상황에서는 제품의 컬러별 main, sub이미지를 모두 각 제품 데이터 객체에 넣어주면 데이터 양이 기하급수적으로 늘어나게 되는 상황이라 내가 각 컬러와 제품 별 id 값을 찾아서 find 함수를 활용해 비교해보고 해당하는 id의 main, sub이미지를 가져와 렌더해주는 방식으로 하기로 결정하였다.

    컬러별 제품 사진 기능 구현

     

    그러나 각 제품 box컴포넌트를 map함수를 이용해 관리하고 있기 때문에 해당하는 컬러를 클릭하면 그 id 값의 이미지가 해당 box 컴포넌트 뿐 아니라 타 컴포넌트에도 이미지 변화를 일으키는 오류를 발견하게 되었다.

     

    이 오류를 해결하느냐고 장장 2틀을 고심했지만 결국 실패했다.

    그리고 월요일 오전, 더 많은 데이터 용량도 단시간에 커버할 수 있게 되었다는 백엔드 개발자의 말에 각각의 이미지를 받아와서 타 컴포넌트에 영향없이 렌더링을 할 수 있게 되었고 이 문제는 단 30분만에 해결되었다. 

     

    이 삽질(?) ⛏의 시간을 통해 오류 해결을 잡기 위한 다양한 시도 방법을 배우기도 했지만,

    무엇보다 내가 혼자서 끙끙 앓고 있었다면 더 많은 시간을 흘러보냈을 것이라는 생각이 들었다.

    백엔드와 프론트 개발자의 소통이 이렇게 정말 중요한 것이구나. 

    백과 프론트의 능숙한 협업은 프로젝트의 완성도를 달리하는 구나. 하는 깨달음을 얻었다.

     

    그리고 주말동안 혼자 고민하기 전에, 백엔드와 소통하는 방법을 택했다면 좀 더 빠르게 문제를 해결 할 수 있었겠다는 생각이 들었다.

     

    이전에 8기 선배님들 중에 한 분에 말씀하셨던 것이 생각난다.

    "넘치는 소통이 덜한 소통보다 낫다"

     

     

     

    3-2. 완성도 있는 기능구현을 향해

    2주라는 시간의 한계와 백엔드 프론트 개발자 비율, 병아리 개발자 실력의 한계로 필터의 필터구현(nesting filter), sold out, 할인률, 관심하트버튼 누르기 등 맡았던 제품 리스트 페이지를 좀 더 완성도 있게 기능구현을 하지 못했던 점이 아쉬웠다.

    검색바가 제품 리스트 페이지에서는 검색 후 엔터를 눌렀을 때 url로 인해 페이지 전환이 되지 않는 버그도 프로젝트 종료 당일날 발견하게 되었다. 

     

    오류를 발견 했을 때, 좀 더 세밀하게 오류를 잡아내지 못하고 다양한 기능구현을 향해 정신없이 달려갔던 건 아닌가 반성하게 되기도 했다. 다음 프로젝트 때는 버그가 없는지 다양하게 꼼꼼하게 살펴보고, 한 페이지 구현도 좀 더 완성도 있고 깔끔한 코드로 작성 할 수 있도록 노력해야겠다. 

    댓글

Designed by Tistory.