첫 프로젝트 회고(feat. WatchaPedia)

박민하·2022년 7월 3일
회고록
0

회고록

목록 보기
1/2

🚀 프로젝트 소개

  • 왓챠피디아 클론 코딩
  • 클래식 영화 소개 사이트
  • 메인페이지, 영화 상세페이지, 프로필 페이지로 구성
  • 로그인을 하면 개인 프로필 페이지 생성
    • '보고싶어요' 기능으로 좋아하는 영화를 찜해놓고 프로필 페이지에서 확인 가능.
    • 영화별 별점 지정 가능.

✔ 개발 기간

2022-06-20 ~ 2022-07-01 (12일)

✔ 팀 구성

  • Backend : 이태권(PM), 박민하
  • Frontend: 김민석, 김은경, 이현범

✔ 협업 툴

SlackNotionTrello

✔ 역할

  • DBdiagram을 이용한 데이터 모델링 (보조)
  • csv file to MySQL (중심)
  • 회원가입(SignupView) API 구현(POST)
  • 로그인(SigninView) API 구현(POST)
  • 로그인/회원가입 유효성 검사
  • 상세 페이지(FilmDetailView) API 구현(GET)

✔ Backend 기술 스택

LanguageFramworkDatabaseEnvironmentHTTP

🚀 프로젝트 구조

✔ 모델링

✔ API

👏 후기 👏

  첫 프로젝트가 끝났다. 이제 첫 회고를 작성하려고 하는데, 이걸 어떻게 풀어야 재밌게 핵심적인 내용만 소개 할 수 있을지가 고민이다. 우선 간단하게 프로젝트 과정에서 작성한 코드를 바탕으로 있었던 일을 느낀 점과 함께 정리해 보고자 한다.

✍️ 기억에 남는 코드 및 협업 과정

1. 모델링

  • db 모델링은 애초부터 잘 해둬야 한다는 점은 프로젝트 시작부터 귀에 딱지가 앉도록 들었다.
  • 하지만 아무리 주의한다고 해도 계획은 완벽하게 굴러가지 않는 법.
  • 사실 모델링 초기에는 배우의 배역과 역할 테이블이 없었다(!!!!!!).

    🤷‍♂️"백엔드님들~ 상세페이지에 배우 배역과 역할 데이터를 넣어야하는데 모델링에는 그 부분이 없어서요. 확인 부탁드립니다!"
    🤦‍♀️🤦"...!"

  • 아주 감사하게도 프론트쪽에서 프로젝트 초기에 발견해주셔서 데이터 수정 작업에 들어갔다.
    • 이 데이터를 어떻게 추가해야 빨리 db를 설계하고 다시 작업에 착수 할 수 있을까 고민했다.
    • 이 과정에서 백엔드 개발자 둘이서 소통을 많이 했고, 서로의 의견을 존중하면서 데이터 수정을 마쳤다.
    • 이 과정은 같은 백앤드끼리의 첫 충돌이었고, 예민해져있는 두 개발자가 서로 양보해가면서 협의(논리로 설득)하는 첫 과정이어서 기억에 남았던 best1로 뽑을 수 있다.

2. 로그인/회원가입 유효성 검사

  • 이 유효성검사 코드가 프론트와의 첫 협업이다.
  • 먼저 프론트 쪽에서 접선(?)을 시도해왔다.

    💁‍♂️"이제 로그인/회원가입 모달 창을 만드려고 하는데, 회원가입 조건을 달아주는 유효성 검사가 필요합니다."
    🙆‍♀️"넵. 혹시 원하시는 조건이 따로 있을까요?"
    🤷‍♂️"일단 비밀번호는 영어,숫자,특수기호 중 2개 이상 포함 했으면 좋겠고요, 닉네임의 경우는..."
    🤦‍♀️"...!"

  • 이전에 써봤던 정규식이 아니라서 구글링을 통해 여러번의 디버깅을 거쳐서 구현한 코드다.
  • 딱히 특이할 게 없는 regex지만, 프론트 측의 요구에 맞춰서 코드를 작성한게 처음이라서 인상깊었던 코드다.

3. 상세 페이지(FilmDetailView) API

  • Django ORM은 항상 어려웠고, 지금도 어렵지만 프로젝트 기간 동안 수없이 리펙토링을 하면서 가장 많이 발전한 부분으로 꼽고 싶다.
    • 위 코드는 film class 하나만 import 해서 작성했다.
    • 그 전까지는 모든 class를 import해서 다소 난잡하게 메서드를 사용했었다.
    • QuerySet method에 대해서 더 공부할 수 있는 좋은 기회였다.
  • 변수 이름이 프론트 측과 동일해야 통신이 가능하다고 해서 가장 자주 프론트와 소통했던 부분이다.
  • 처음에는 배우 이름 따로, 배우 이미지 따로 불러올줄만 알아서 난항을 겪었다.

    🙋‍♀️"영화 상세페이지 데이터를 불러오려고 하는데, 이런 구성이면 될까요?"
    🤷"네, 하지만 배우는 한 리스트 안에 따로 불러와줬으면 합니다."

  • 백엔드 입장에서는 상관 없지만, 프론트 입장에서는 데이터를 받아올 수 없는 구조가 있다는 점을 알게됐다.

    🙆‍♀️"드디어 배우별로 나열했어요~ 이러면 문제 없을까요??"
    🤷"아, 혹시 감독에도 '역할'부분을 추가할 수 있을까요? 상세페이지를 다시 보니 그 정보가 필요하네요..."
    🤦‍♀️"...!"

  • 위의 대화에는 복합적인 문제점이 있다...
    • 감독 테이블의 역할 컬럼을 추가하기 위해서는 model 수정하고, db 테이블도 수정하고, migrate도 다시하고, 데이터도 새로 넣어야한다.
    • 앞서 언급했다시피... 모델링이 잘못되어 갈아엎은 적이 이미 있다...
    • 어려운 일은 아니지만, 그 때 당시 중요한건 이 데이터가 아니었다(24시간이 모자라).
    • 결국 하드코딩으로 'role' : '감독' 데이터를 넣은 수치스러운 경험이지만, 애초부터 모델링을 잘하자라는 교훈을 얻게 됐다.

🌟 프로젝트 기간 중 얻은 것들

✔새롭게 배운 내용

  • Django
    • class 상속
    • decorator
    • django ORM(aggregate, annotate, Q객체, order_by, get_or_created)
  • 협업 툴(trello, postman)

✔느낀 점

  • 백엔드는 페이지를 벗어나서 코드를 작성해야 한다.
    • 코드는 한 번 작성 해두면 이 페이지, 저 페이지에서 활용 할 수 있다.
  • 협업 툴은 잘 활용하지 않으면 빚좋은 개살구다.
    • 백/프론트에서 "오늘 이 부분을 구현할거다"고 한다면 그 때 그 때 대화를 충분히 해야지 나중에 뒷북치지 않는다(모델링... 데이터 통신 미루다가 늦게 알아차린 빈 구멍....).
    • 프론트의 작업 방식을 최소한이라도 알고 있어야 나중에 고생 안한다(데이터 수정의 늪).
  • 혼자 하는 프로젝트와 팀 프로젝트는 아주아주 다르다.
    • 나만 잘한다고, 내가 못한다고 프로젝트가 잘 되고 못 되는게 아니다.
    • 의견 전달을 어떻게 해야할지, 언제 해야할지, 꼭 해야하는 작업인지 등 신경 쓸 게 많다.

🍻 프로젝트를 마치고

  프로젝트 마지막 날, 팀원들과 2주간의 회고를 하면서 생각는게 다 비슷하구나 싶었다. 다들 많이 아쉬웠고, 많이 고생했고, 많이 재밌었다고 했다. 공감하는 부분이지만 사실 나는 아쉬운 부분이 크다.

  나와 같이 작업한 백앤드 개발자에게는 시간 내에 프로젝트를 끝내게 해줘서 감사한 마음도 있지만 내 부족함을 일깨워 준 사람이기도 했다. 회고록을 쓰기 전에는 이런 나를 깎아내릴 수 있는 표현은 굳지 서술하지 않으려고 했지만... 좋았던 점은 위에서 다 쓰기도 했고, 아무래도 회고는 다음에 또 다시 같은 실수를 반복하지 않기 위해 쓰는거니까 넣기로 했다.

  제한된 시간과 부족한 지식은 다른 팀원에게 부담을 줬다는 생각이 들었고, 실제로 내가 구현한 부분은 이 프로젝트의 극히 일부분일 뿐이다. 맡은 바는 최선을 다하고 마무리 지었지만 Q객체로 메인페이지에서 영화 정보를 가져거나, 보고싶어요 기능을 구현하는 거나, 대부분의 핵심 기능들은 손도 못대보고 끝났다. 이걸 직접 고민해보고 구현해 본 동료 개발자는 많은 것을 얻었을 것이다. 프로젝트에 대한 이해도가 높아질 수 밖에 없어 프론트와의 소통은 대부분 동료 백앤드 개발자와 이루어졌다. 가장 큰 아쉬움이다.

  내 부족한 점만 들춘 것 같아서 부끄럽다~~ 다음에는 이런 아쉬움을 느끼지 않도록 주의하겠다고 다짐하며! 이 회고록을 마친다.

profile
박민하
backend developer 🐌
다음 포스트

두 번째 프로젝트 회고(feat. MyRealTrip)

0개의 댓글