Two Circle 쇼핑몰 프로젝트 회고

Two Circle 프로젝트

라운즈

라운즈(ROUNZ) - 세상에 없던 안경쇼핑

국내 안경 쇼핑몰 판매 사이트 라운즈를 모티브

프로젝트 선정이유

• 깔끔하고 심플한 사이트 UI
• 프론트엔드 공부를 위한 필수적인 기능들이 있고 구현하기에 크게 어렵지 않음
• 시간이 많이 들어갈만한 디자인이 많지 않아 기능구현에 집중 가능

프로젝트

GitHub - hyeon17/TwoCircle

---

KPT

Keep

• 매일 30분, 트러블 슈팅에 대해 의견을 교환하고 수정사항을 피드백하였고 서로 존중하면서 자유롭게 의견을 어필하는 문화가 좋았다.
• 바닐라 자바스크립트로 SPA를 구현하면서 Navigo 라우터 기술을 적용하였다. 이를 통하여 SPA에서 라우터를 구현할 수 있음에 따라 화면에 필요한 부분의 데이터만 받아서 렌더링 하므로 처리 과정이 효율적이며 속도가 빨라졌다.
• 자주 사용하는 기능 중 하나인 페이지네이션 코드를 모듈화 하여 중복 코드를 방지함에 따라 코드의 재사용성이 좋아졌다. 이 코드를 통해 페이지네이션이 필요한 페이지가 있으면 매개변수로 데이터를 받아 바로 적용시키므로 빠르게 적용 가능하고 유지보수 또한 간결해졌다.
• figma에서 미리 디자인 틀을 잡고 페이지 다이어그램을 작성하여 추후에 SPA를 구현할 때 헤매는 일이 없이 빠르게 구현하여 효율적으로 작업을 할 수 있었다.

Problem

• 세세한 사항을 생각하지 않고 기능 구현에만 몰두하여 코드의 수정이 빈번해졌다. 한 예시로 쇼핑몰에 대해 제대로 파악하지 않고 초기에 구현에만 집중하다 보니 사용자가 상품을 장바구니에 담을 때 알림을 띄워줘야 하는데 처음에는 띄워주지 않아 사용에 혼란을 주는 상황이 생겼다.
• scss파일을 style.scss파일에 넣고 모두 관리하다 보니 class name이 중복되면 스타일 오염이 발생했다.
• 협업을 진행하면서 소통의 오류가 발생했다. 수정사항에 대한 피드백을 구두로 전달받으면서 나와 팀원의 이해한 방식이 달라 수정사항을 다시 수정한 상황이 생겼다.
• github에서 pr을 날릴 때 브랜치에서 수정된 코드를 업데이트받지 않고 pr을 날려 conflict가 생겼다.
• 각자 어떤 작업을 진행하고 있는지 몰라 중복된 기능을 구현한 일이 발생하였다.
• 웹 번들러 중 하나인 parcel을 사용하면서 image폴더에 있는 이미지들이 번들링 후 적용이 되지 않았다.
• 주어진 api에서는 상품을 2개 이상 구매할 때 개수에 대한 값을 받는 곳이 없어 api요청을 보낼 때 한 번에 2개 이상에 대한 구매요청을 보낼 수 없었다.

 

Try

• 쇼핑몰의 기능에 대해 파악하기 위해 여러 쇼핑몰 사이트에서 직접 기능을 체험해 보면서 사용자 편의성을 위한 세세한 사항을 메모 후 추후 기능에 반영하였다. 한 예시로 결제 시 계좌를 선택하지 않으면 계좌를 선택 후 결제를 하도록 알림을 띄우는 코드를 반영하였다.
• 스타일 오염 방지를 위해 각 페이지 시작 class name을 페이지 이름으로 설정하여 하위 항목에서 class name이 중복되어도 스타일이 오염되지 않게 하였다.
• 소통의 오류의 원인이 구두로 전달되어 각자 이해한 방식이 다른 것을 파악한 후 수정사항에 대한 피드백은 slack채널을 통해 메시지로 전달받아 소통에 오해가 없게 하였다.
• conflict를 방지하기 위해 미리 local에서 git fetch/merge를 수행한 후 pull request를 진행하였고 매일 밤 12시에 팀장이 pr에 대한 코드들을 모두 merge 하여 다음날 작업 시업데이트를 받는 식으로 방향성을 정해 해결하였다.
• 팀원들의 진행사항을 빠르게 파악하기 위해 github Issues탭에 자신이 진행하고 있는 작업에 대해 작성하여 해결하였다.
• parcel-plugin-static-files-copy 를 통해 정적 파일을 연결하여 해결하였다
• 2개 이상 구매한 상품에 대해 구매요청을 보낼 때 한 번에 보내는 것이 아닌 구매한 개수만큼 요청을 보내어 여러 개를 구매한 것처럼 보이게 하여 해결하였다.

---

 

 

느낀 점 및 마무리

첫 웹사이트 팀 프로젝트를 하면서 많은 일이 있었다. 초기에 다들 프로젝트 진행을 어떻게 해야 하는지 몰라 거의 주먹 구구식으로 진행하였다. 하지만 점점 비효율적인 작업방식으로 인해 팀원들이 다들 지쳐갔고 체계가 잡혀 있지 않아 다들 많이 고생하였다. 나중에는 체계를 잡고 각자 작업방식에 대해 효율적으로 진행하였지만 처음부터 체계를 확실히 잡고 진행하지 못한 것에 대해 많이 아쉬웠다. 

프로젝트가 끝난 후 멘토님께 피드백을 받았는데 기능구현에만 급급하다고 말씀하셨다. 이 점은 개발 시 인지하고 있었지만 제한된 시간 안에 필요한 기능을 일단 넣고 나중에 상세한 기능은 다시 봐야겠다고 생각했다. 하지만 점점 기능이 많아질수록 모듈화가 어려워지고 필요한 상세기능이 어떤 것이었는지 헷갈려 다시 바로 잡는데 시간을 많이 쏟은 것이 아쉬웠다.

프로젝트에 관해 멘토님께서 관리자 페이지와 서비스 페이지를 분리시키는 것이 좋다고 하셨다. 사용자 입장에서는 관리자 페이지를 볼 필요가 없는데 서버에서는 관리자 페이지까지 보내므로 서버에서 불필요한 작업이 실행된다. 또한 추가로 알아본 바로는 보안에 취약할 수 있는 점도 있기 때문에 별도의 포트를 생성하여 사용하는 것이 안전하다. [참고 기사]

이번 프로젝트를 하면서 정말 많은 인사이트와 경험을 얻었고 이를 바탕으로 추후 프로젝트 진행 시 더 효율적인 방식을 통해 사용자 측면에서 생각해보는 개발을 해야겠다고 다짐했다.