1차 프로젝트 - 4. 총정리

코지클래식·2021년 10월 18일
WeCode
1

Mecook

목록 보기
4/4

1. 프로젝트 소개

개요

  • 작업 기간 : 2주 (10/5~10/15)
  • 작업 인원 : 프론트4 + 백엔드2
  • 프로젝트 내용 : E Commerce 사이트 클론코딩 (외부연동 제외)

링크

작업 내용

  1. 메인 : 우선순위를 기준으로 정렬하여 N개의 베스트 메뉴 노출
  2. 회원가입/로그인 : bcrypt로 비밀번호 암호화, JWT로 사용자 브라우저 localStorage에 토큰 저장하여 특정 요청 시 유효성 검사
  3. 상품리스트 : 카테고리 순, 혹은 우선순위 높은 순으로 정렬하여 상품 노출.
    -> 테이블 : 상품, 카테고리(정참조), 좋아요(1 to N)
  4. 상품상세 : 상품의 세부내역
    -> 테이블 : 상품, 카테고리, 좋아요, 상세이미지/텍스트(1 to N), 해시태그(N to N)
  5. 상품검색 : 상품을 키워드(단어)별로 검색
    -> 이름 또는 해시태그를 기준으로 검색
  6. 좋아요 : 상품 정보에 상품 별 좋아요 숫자 노출. 로그인 시 좋아요 선택/취소 및 사용자가 좋아요를 누른 상품 표시.
  7. 장바구니 : 상품정보에 양을 추가해서 별도 저장. 로그인 시 가능
  8. 주문(포인트 차감식) : 회원정보에 저장된 포인트를 차감해서 주문

역할

  • 전체 ERD 작성 및 모델링 개요 작성
  • 상품 모델링, 상품 리스트/상세조회 및 검색기능 작성

2. 사용 기술

  • 백엔드
    Python(언어), Django(서버), MYSQL(DB), Git/GitHub(버전관리), bcrypt/JWT(암호화), AWS EC2/RDS/S3(클라우드 컴퓨팅)
  • 프론트엔드
    JSX, React(CRA), Sass(React-outer-DOM)

공유하고 싶은 코드

하나의 데이터를 생각하면 테이블간의 관계가 1:N 이지만,
여러 상품을 기준으로 테이블에서 여러 정보를 뽑아야 하는 상황에서
DB와의 접속을 줄이려고, 다음과 같은 코드를 작성했다.

product_queryset= Products.objects.select_related('category').values(*[keyword_dicts[key] for key in keyword_dicts])
product_id_list = [product["id"] for product in product_queryset]
likes           = Like.objects.filter(product_id__in=product_id_list)
likes_list      = Counter([like.product_id for like in likes])



for product in product_queryset[:20] :
    curr = {}

    for keys in keyword_dicts :
        curr[keys]   = product[keyword_dicts[keys]]
        curr["like"] = likes_list[product["id"]]

3. 협업의 경험

착각

프로젝트가 끝나기 전에는, 나는 의사소통을 잘하고 있다고 착각했다. 서로에게 필요한 점들에 대해 내가 먼저 공유하고 이야기를 나눴다고 생각했는데 아니었다.

  • 나는 하루만에 모델링을 끝내고, 팀원들과 데이터 모델을 공유했다.
  • 이틀째에 프론트엔드에게 페이지별로 필요한 데이터를 달라고 요청했고, 이후 프론트에서 요청한대로 한시간만에 API를 만들어 놓고 기초적인 가짜 데이터를 집어넣었다. 이후에는 프론트에서 필요 사항이 있으면 나는 요청대로 바꾸기만 해주면 되고, 내가 해야하는 건 리팩토링 뿐이라고 생각했다.

그러나 현실은 내가 생각했던 것과는 달랐다. 양쪽 모두 협업이 처음이었기 때문에 발생한 일이다.

문제점

이번에 발견한 의사소통의 문제점은..

  1. 내가 공유했다고 생각한 ERD, 모델링은 팀원이 사이트를 제대로 살펴보기도 전에 내가 설명도 없이 '던져버린' 정보가 되었다. 나는 이를 통해 페이지별로 필요한 데이터리스트를 돌려받기를 원했지만, 결국 청자의 입장을 고려하지 않은 정보의 입력은 시간낭비가 되었을 뿐이었다. 이는 백엔드나 프론트나 마찬가지다.

  2. API에 문제가 발생하면, 프론트에선 누구의 문제인지 몰라 백엔드와 교차검증해야하는 타이밍이 있었다. HTTPIE로 확인하면 데이터가 정상적으로 오가는 것처럼 보였다. 하지만 BODY가 빈상태로 되어있으면 에러가 발생하는걸 몰라서 시간낭비가 발생했다. 빠른 해결을 위해서는, 내가 먼저 다가가서 계속 물어봤어야 했다.

  3. 프론트 입장에서는, 백엔드에서 제공해준 API를 시간이 걸리더라도 스스로 가공할 능력이 있었다. 내가 먼저 말을 걸기 쉽지 않은 사람이기도 했다(맨날 헤드셋 쓰고 있었음). 때문에 백엔드에서 변경하면 더 빠르게 적용할 수 있는 내용들을 직접 처리하는데에 시간이 더 걸렸다.

개발 외적인 아쉬운 부분

  1. 가짜 데이터(mock데이터)라도 좀 더 성의있게 넣었으면 어땠을까 하는 아쉬움이 남는다. 현업에 가서는 페이지 관리자들이 올릴 데이터라고 생각하고 "내가 할일이다" 라는 생각을 안했다. 그러나 그냥 시간 남는 사람이 했으면 되는 작업이었다. 백엔드는 비교적 시간이 있었다.

  2. 개개인의 작업물에 대해 A가 완성되어야 B가 가능하다는 것을 알고 있음에도 불구하고, 작업 순서를 그렇게 두지 못했다. 이래서 소위 말하는 PM, 프로젝트매니저가 필요하구나 하는 것을 느꼈다. 다음에는 아무도 안하면 나라도 해야겠다.

느낀점

의사소통을 하는 시간이 꽤 길었다. "이것도 몰라?" 하는 부분도, 내가 말하지 않으면 남들은 절대 알 수 없었다. 의사소통을 잘하는 것이 정말 중요하다는 것을 느꼈다.
하루에 대화를 2~3시간씩은 했던 것 같다. 그런데 놀라운 점은 우리가 하는 작업이 클론코딩이라 기획이 정해져 있다는 것이다. 기획이 명확하지 않거나, 기획이 있더라도 눈으로 보고 확인할 사이트가 없었다면 커뮤니케이션에 시간이 엄청나게 더 들었을 것이라는 생각이 든다.

4. Good/Bad

잘한 점

  1. DB접속을 최소화 하는 코드를 만들었다.

  2. 코드 짜는 시간이 길지 않았다. 적어도 내 스케쥴 때문에 다른 작업이 밀리는 일은 없었다.

  3. 안좋은 코드를 억지로 살리려고 하기 보다는, 처음부터 짜는게 훨씬 낫다는걸 깨달았다. 맨 처음에 빠르게 API를 제공하려고 만든 코드를, 살리면서 리팩토링 하면서 시간낭비가 발생했는데, 다음부턴 이렇게 하면 안된다는 것을 배웠다.

  4. 백엔드는 API등을 만들 때, 페이지기준이 아닌 데이터의 흐름을 기준으로 만들어야 한다는 것을 배웠다.

  5. 객체지향이 뭔지 이제 겨우 생각해볼 만큼의, 절차지향적이라고 할 수 있는 코드를 작성할 수 있었다. 다음에는 객체지향을 노려보겠다.

아쉬운 점 - 개인

  1. 초반에 AWS에 서버를 올릴 수 있는 시간과 기회가 있었는데, 가상환경 버전을 다루기가 어렵다는 이유로 뒤로 미뤄버렸다. 결국 나중에 프론트엔드에서 주소를 계속 바꾸게하는 시간낭비를 발생시켰다.

  2. API 명세서를 가독성 있게 제공하지 못했다. 나는 GET 요청만 있기 때문에 API를 따로 안만들어도 된다고 생각했는데, 잘못된 생각이었다. 나는 JSON Viewer를 사용해서, 크롬에서 쉽게 보는법을 전파해줬다고 생각했지만 그래도 따로 줬어야했다. 또, POST 요청은 내가 작업하지 않더라도 API 명세서를 미리 보여줬어야 했는데 남의 코드라고 신경쓰지 않아 시간의 낭비가 있었다.

  3. 협업이고, 작업해야 하는 분량이 정해져 있다 보니 내 몫을 끝내고 뭘해야 할지 알수가 없었다. 다른 백엔드 팀원의 분량에 욕심이 나서 계속 진행상황 물어보고 본인이 할건지 물어봤는데, 그냥 마감시간을 정해주고 기다렸어야 했다. 괜히 나 자신의 불안함과 초조함을 남에게 전달했던 것 같다. 팀원을 믿어야 하고, 팀원이 도와달라는 말을 먼저 하기 전에 뭔가 시도하는 것은 감정만 상하는 행동이었다.

  4. 더 할 수 있는 부분들 (주문, 배송, 결제.... etc)에 대해 협업이라는 다른 백엔드 팀원의 작업을 기다린다는 핑계로 미뤄두고 안했다. 솔직히 할려면 할 수 있었는데도. 그렇다고 시간을 의미있게 쓴 것도 아니었다. 내가 뭘 해야할지를 몰라 붕 뜬 시간이 있었던 것 같다.

  5. 모델에서는 공통적인 부분을 줄일 생각을 못했다. (createdat, updatedat)

후기

먼저 짧은 시간동안 많은 양의 작업을 해주신 프론트 분들에게 매우 감사하다. 소위 말하는 레이아웃을 만들어 내는 작업이 미적감각이 모자란 나로써는 너무나도 힘든 일이고, 프론트엔드의 엄청나게 많은(백엔드에 비해서) 파일/폴더와 프로그램을 보고 있으면 상대적으로 코드가 적은 내가 미안한 감정이 들 정도였다.
그리고 가장 어린나이에 팀장이 되어 계속 진행상황을 확인하고 회의록을 작성해준 팀장님께 감사드린다.
뭔가 잘했다는 생각보다는 더 잘할 수 있었는데.. 하는 아쉬움만 남는다.

profile
코지클래식
코지베어
이전 포스트

1차 프로젝트 3. 갈아 엎기

0개의 댓글