[회고록] 프로젝트 후기

2주의 pre-course, 2주의 foundation 과정을 거쳐 드디어 1차 프로젝트를 시작하게됐다. 총 서로다른 7개의 커머스 웹페이지를 7개의 팀이 클론 프로젝트를 진행하게됐다. 클론 프로젝트를 진행함은 기획과 디자인에 소모하는 시간과 노력을 줄이고 개발에 집중하기 위함이다. 한팀을 제외하고는 프론트엔드 3명 / 백엔드 3명으로 구성되어 프로젝트를 진행하게되었다.

Trello 작성하기

프로젝트는 scrum 방식으로 진행하기러 하였고, 제일 먼저 진행한 사항은 해당 웹페이지를 분석하고 Trello에 task별로 나누어 업무분장을 하고 계획을 짜는 일이었다. 사실 나는 MBTI 끝자리가 P이기에(?) 계획을 세우는게 익숙지 않고 불편한 일이지만, 업무의 양이 방대하고 정해진 시간내에 완성해야하기 때문에 계획을 짜는게 훨씬 효율적이라고 생각이 들었다.

task들을 기능별로 구분해서 보드를 관리해야되기 때문에 처음부터 큰 그림을 다 그리고 시작해야했다. 기능별로 큰 덩이로 나누고 각각의 덩어리들을 단위 기능으로 나누었다. 하지만 각각의 기능들에 대해 구체적으로 어떠한 작업들을 해야하는지 머리에 잘 들어오지 않아 일단은 rough하게 잡아놓고 시작했다. 어차피 trello 는 진행중에도 계속 수정될 수 있고, 계획이 바뀔수도 있기 때문이다.

업무는 일반적인 커머스 서비스가 가지고 있는 3가지 기능인 제품(products)/장바구니,주문(order)/사용자,리뷰(user) 기능으로 나뉘었고, 나는 제품 관련 기능들을 구현하도록 배정되었다.

데이터 모델링

프론트엔드 개발에서 밑바탕 그림을 그리는 것으로 '레이아웃'을 잡는 과정이 백엔드 개발에는 데이터 모델링이 있다. 데이터 모델링은 백엔드 개발담당 3명이 모여서 Aquery tool을 이용하여 진행하였다. 1차적으로 웹페이지에서 확인할수 있는 최대한 많은 기능들을 모두 모델 안에 넣고, 데이터간의 관계를 정의하였다.
우리는 의류 항목중 '신발' 품목만 구현하기로 하였는데, 모델링중 개념적으로 어려웠던 부분이 두가지가 있었다.

1) 신발 <-> 사이즈, 신발 <-> 색깔 간의 관계는 둘다 Many To Many 관계이고, 신발/사이즈/색깔을 모두 연결하려면 중간 테이블 + 중간 테이블이 형성되어 조금 복잡해진다.
👉 이름이 같고 색깔이 다른 신발은 서로 다른 제품으로 구분하여 색깔 <-> 신발 은 one to many 관계, 신발 <-> 사이즈는 many to many로 관계를 정의하여 하나의 중간 테이블만 만들어 복잡함을 조금 덜게끔(?) 했다.
2) 처음에는 cart 안에 user 테이블의 Foreign-key를 넣어 카트에 user로 구분하려했으나, 이렇게 되면 매번 쇼핑할때마다 cart를 관리할수 없었다.
👉 제품 <-> 주문(order) Many To Many 관계의 중간 테이블로 carts를 만들어 카트에 주문번호가 들어갈수 있게끔 하고, 주문에 user id를 연결시켰다.

VIEW 짜기(API 만들기)

데이터 모델링 작업이 끝나고 API 만드는 단계가 왔다. 처음에 나는 제품에 대한 API를 크게 메인 페이지 / 제품 리스트 페이지 / 제품 상세페이지로 나누었다. 이게 이번 1차 프로젝트를 통틀어 가장 큰 삽질(?)이자 실수이지 않았나싶다... 근데 이렇게 생각한 생각의 뿌리에는 한가지 잘못된 생각이 하나 있었다. django에서 url 설정을 view당 1개를 설정하게되는데, 여기서 설정하는 url이 곧 우리가 보게되는 웹페이지의 url이라고 생각했다. 왜그랬을까...😂🙄

알고보니 프론트에서는 한 페이지안에서도 여러 url을 fetch하여 데이터를 부분부분 받을수 있었다.❗️ URL은 단지 데이터를 받아오는 주소일 뿐...

그러다보니, 나는 한개의 페이지 안에있는 여러가지 기능들을 하나의 view에서 처리하고자 하였고, 머리가 매우 복잡해졌지만 주말에 머리를 싸메고 코드를 작성한 결과 하나의 view에서 처리하도록 만들어냈다. 이와중에 pagantion을 검색을 하지 않고 내손으로 짜냈는데 지금봐도 잘짠거 같다 ㅋㅋㅋㅋ(덕분에 프론트가 좀 고생했지만🤣)

하지만, 월요일에 github에 첫 푸쉬를 하고 코드 리뷰를 받은 결과...
하나부터 열까지 다 뜯어고쳐야 하는 상황이 발생하였다. API를 기능별로 분리하여 다시 만들어야했고, 그동안 프론트와 상의한 내용도 엎어야했기 때문에 같이 작업하는 프론트도 코드를 많이 고쳐야하는 상황이 발생했다.

코드를 리팩토링하고, 세부 구현(제품 구분 + 정렬 + 상세 필터+상세정보+제품 포스팅)까지 마무리했을때 최종 발표 이틀전이 되었고, 이때 사실 마음을 놓고 프론트를 기다리는 상황이었는데 추가구현을 더 해볼껄 그랬다.

<배포>

발표 전날 AWS에 관한 세션을 듣고 직접 클라우드 서버/데이터베이스를 배포하는 작업을 진행했는데, 배포작업은 메뉴얼대로 하면 되는 부분이라 어렵지 않았지만 생각보다 많은 시간을 잡아먹고 프론트에서 동적 routing 작업이 생각보다 지연되어 같이 맞춰볼 여유가 많이 없었다. 그리고 마지막에 맞춰보면서 많이 느꼈는데, 내가 코드를 작성하면서 혼자만 생각하고 프론트에 말하지 않았던 부분들이 많이 드러났고, 기능구현이 안된 부분도 있었다.

<아쉬운 점(고쳐야할 점+배운점)>

• 모델링 작업에 시간 투자
• 페이지단위로 코드작성(X) -> 기능 단위로 코드 작성(O)
• 코드를 혼자만 생각해서 짜면 안됨 + 구현 기능이 있으면 항상 프론트에 정보 공유
• 바빠서 Trello 관리를 못함
• 시간 남으면 추가 구현
• 그날그날 있었던 이슈사항 문서화하기

기억하고싶은 코드

• pagenation : https://velog.io/@adsf25/Pagenation내방식
• filtering : https://velog.io/@adsf25/Django-다중-필터-적용