갓챠피디아 😇 👿

-고마웠어요 프엔젤, 백엔젤들 ❤

☑️ 첫 프로젝트

첫번째 프로젝트의 사이트는 왓챠피디아(https://pedia.watcha.com/ko-KR)이다.
왓챠피디아는 사용자가 자신이 본 영화에 대해 별점을 매기면, 취향을 분석해 좋아할만한 영화를 추천해주는 사이트이다.
그러다보니 사용자의 취향을 어떤식으로 결정하면 좋을지 <별점>이나 <검색>이나 <클릭> 같은 사용자의 기록들을 가지고 사용자의 취향을 어떻게 분석해야 할지에 대한 부분이 조금 어려웠다.
갓챠피디아팀의 모델링은 많은 기능을 구현하는게 목표가 아니라 필수 기능들을 더욱 확실히 익히자! 라고 의견을 모았다. 따라서 user와 movie 를 중심으로 가장 필요한 기능들을 중심으로 하고싶은 기능들을 점점 추가해나가는 방식으로 모델링 작업에 들어갔다.

☑️ Scrum 방식으로 진행

첫 프로젝트는 scrum 방식으로 진행해보기로 했다. 스크럼(Scrum)은 프로젝트 관리를 위한 상호, 점진적 개발방법론이며, 애자일 소프트웨어 개발 중의 하나이다.
애자일 방법론은 소프트웨어 개발 방법에 있어서 "아무런 계획"이 없는 개발 방법과 "계획이 지나치게 많은" 개발 방법들 사이에서 타협점을 찾고자 하는 방법론이다. 애자일 개발 프로세스란 어느 특정 개발 방법론을 가리키는 말은 아니고 "애자일(Agile=기민한, 좋은것을 빠르고 낭비없게 만드는 것) 개발을 가능하게 해 주는 다양한 방법론 전체를 일컫는 말이다. 그중에서 스크럼은 기존에 애자일을 접하지 않는 사람들도 쉽게 애자일을 실천할 수 있는 정형화된 프로세스를 제공해주고 있다.
스크럼 방식 출처: https://agileforall.com/resources/introduction-to-agile/

1. 첫번째 미팅

첫번째 미팅으로 팀원으로 선정된 우리들이 왓챠피디아 사이트 내에서 구현하고자 하는 기능들에 대해서 모두 합쳐서 의논해보는 시간을 가졌다. 이 과정에서 많은 의견이 나왔다. 사이트에 있는 거의 모든 기능들을 구현해보고 싶은 우리의 열정이 돋보이는 자리였다! 그래서 진행하고자 했지만 시간 관계상 하지 못한것들이 아직 남아있는데 이런것들은 추후에도 계속 수정할 수 있다고 생각하기로 했다. 그 중에서도 사이트를 우리가 보여주고 싶은 영화로 꾸미고 싶다는 의견이 가장 기억에 남는다.(프론트 팀원분중에 태현님은 본인의 인생 영화인 하는 바닐라스카이를 상세 페이지로 만드셨는데 너무 재미있을것 같아서 부러웠다!)

2. trello 작성

코딩 공장이라는 의미로 공사장 배경을 규석님이 설정하셨다 ㅋㅋ
이렇게 첫번째 미팅에서 나온 의견들을 토대로 멘토님들과 함께 의논하는 시간을 가졌고
최종으로 결정된 할 일들을 backlog로 작성하고 이번주의 할 일들을 This week, 지금 진행하고 있는 일과 끝난 일을 In Progress, Done 으로 옮겨가며 트레일로로 작성하였다.

3. Stand-up Meeting

우리팀은 매일 오전 11시, 스탠드업 미팅을 진행하기로 했다.
매일 새벽에 늦게까지 코딩하고도 늦지 않으려고 노력하는 모습이 보여서 멋있었다.
지금 진행 하고있는 일은 무엇이고 어디까지 진행중인지 오늘은 어떤 일을 할건지
그리고 오늘 논의해야할 사항이 있으면 따로 공유하기도 하면서 늘어지지 않기 위해 스탠드업으로 진행한다.
논의할 사항이 끝나면 매일매일 손을 모으고 갓차 갓차 화이팅!!! 을 외치면서 회의를 끝냈는데, 참 화이팅이 넘쳤던것 같다.
서로 프론트 엔젤 (프엔젤), 백엔드 엔젤 (백엔젤) 이라고 부르면서 힘든 상황속에서도 웃으려고 많이 노력했던것 같다!

☑️ 제일 중요했지만 간단했던

모델링을 팀원들 모두가 모여 협의하고 멘토님 앞에서 발표를 맡게 되었다.
14기 중에서 순서가 제일 첫번째여서 떨리는 마음이 꽤 컸다.
하지만 걱정했던것과는 다르게 수정할 사항은 많지 않았다.
원래는 고객의 취향에 맞게 분석하기 위한 user log라는 테이블이 있었는데 제외시키게 되었다.
아이큐 300이 모여서 협의한 보람이 있었다.(한 사람당 IQ 100씩)
모델링 작업은 협의하에 하루만에 끝났고 바로 장고 models.py에 작성하는 작업이 시작되었다.
모델링부터 models.py 작성은 셋이서 한데 모여서 다같이 진행되어 더욱 의미있는 시간이었다.
만약 다같이 하지 않았더라면 나중에 모델링을 수정 해야할때나 view를 작성할 때 어떻게 했었는지 몰라서 혼란이 일어났을 수도 있을것 같았다.
우리는 나중에 모델이 조금만 바뀌어도 서로 공유하고 알려주면서 혼란이 일어나지 않도록 노력했다.

many to many (다대다)

-movie,moviestaffpositions(중간 테이블), staff, positions
-movie, movie_genres(중간 테이블), genres
-comments, users, movies, comments(자기참조)
-stars, users, movies
-likes, users, commnets

one to many (일대다)

-movie, interst
-movie, picture

☑️ Communication의 중요성 😇

백엔드는 자신이 맡은 일 외에 겹치는 부분은 자주 협의해서 진행하였고 이해 안되는 부분은 바로 잡으면서 가서 순조롭게 소통이 진행되었던것 같아서 기분이 좋았다.
프론트 엔젤분들과 대화하면서 소통의 중요성을 많이 깨달았다.
서로의 업무 방식이 다르다보니 이해의 폭이 다를 수밖에 없었다.
그래서 첫째로, 나의 요청사항을 명확하고 올바르게 표현하는 법을 더욱 연습해야겠다는 생각이 들었다.
둘째로는 프론트엔드에서 어떤식으로 일을 하는지 알았으면 좋겠다는 생각이 들었다.
처음에는 푸터, 모달창, 레이아웃 등등 모르는 용어들이 생소했고 정확한 "개념"을 인지하고 있지는 않았었다.
이런것들은 다음 프로젝트를 진행 하면서도 점차 더 많이 알게될것이다.
자세히 알게 되면 나의 요청사항을 말할 때 더 정확히 표현할 수 있다는 장점을 얻을 수 있을것 같다.

☑️ User

models를 작성하고나서 앱 단위로 담당자를 배정했다. 나는 user에 관한 것을 맡기로 했고 규석님은 analysis, 수희님은 movie 앱을 맡기로 했다.
로그인, 회원가입, 유저 계정 생성, 프로필 이미지 변경, 계정 삭제 등 유저에 관련된 CRUD 를 맡았고 이것은 프로젝트 전에 연습했던 부분도 있어서 어려움 없이 끝낼 수 있었다.
생각보다 일찍 끝내서 나는 검색 기능이나 별점 카운트 기능을 추가로 맡을 수 있었다.

☑️ Git

프로젝트를 진행하면서 가장 어려웠던 점을 한가지 꼽자면 그것은.... 바로바로.. 깃!🌟
깃으로 고생을 좀 하다보니 구글링을 떠나서 따로 시간을 내서 공부하기까지 했었다.
우리 팀은 PR을 올릴 때마다 아래 사진처럼 쓰는 양식을 정했는데,
최종적으로 봤을 때 더욱 직관적이고 통일감도 있어서 좋았다. 이것도 규님의 아이디어ㅎ
공부 다 하고와서 이제 나는 깃 신이다! 외치고 다음날 문제 생겨서 이전 커밋으로 돌아가야 할 때 눈물을 머금었다는 후문이.... 하지만 시간이 지나면서 많이 익숙해졌다. 다음번에는 더 잘 할 수 있을것같다.

git commend 정리 /https://velog.io/@yj-leee/%EC%9D%B4%ED%95%B4%ED%95%98%EB%8A%94%EC%A4%91/

☑️ 협업의 경험 😈

개인적으로 나는 이번 팀원분들과의 케미가 정말 좋았다고 생각한다.
하나 물면 절대 안놓는 독종 3명이 모이는 바람에 우리는 자연스레 새벽반 멤버가 되었다.
그래서 워라밸 최악이라는 소문이 돌기도 했지만 하지만 다 우리가 원해서 하는거였고
각자의 욕심 때문에 남아 있었던거라서 서로 제발 먼저 조기퇴근하라고 애원하기도 했다.
초반에 열심히 한 덕분에 프로젝트 기간동안 좀 더 여유있게 보낼 수 있었다.

잘했던 점

왓챠피디아에서 가장 중요한 영화 데이터는 영화진흥원 오픈 API와 네이버 영화 검색 API를 혼용하여 사용했는데 규석님이 작성하신 자동화 스크립트 파일로 데이터를 빠르게 추가할 수 있었다. 덕분에 작업하는데 시간을 왕왕 줄일 수 있었다.
중간중간 모델링을 수정하면서 데이터를 다 다시 넣어야 하는 상황이 발생되는데 그때마다 아무 걱정 없이 처리할 수 있어서 참 다행이었다.
그리고 새로운 코드들을 배우고 알아가면서 기억에 남는 코드들이 많은데 그건 따로 정리 해볼 예정이다.
내가 맡은 user 와 검색기능, 별점 카운트 기능이 모두 끝나고 나서 중간에 시간이 비어서 할 일을 찾아서 해야하는 상황이었다.
병민님께서 movie앱 쪽 CRUD를 해보면 좋을것 같다고 추천 해주셔서 혼자서도 열심열심 해서 구현해보았고 수희님이 쓴 코드와 비교해보면서 궁금한점은 물어보기도 했다.
기억에 남는 점은 아래처럼 지훈 멘토님께서 칭찬을 해주셨는데 요렇게 단 한 줄로 우리들을 울고 웃게 만드셨다.

아쉬운 점

담당자 배정

검색 기능이 프론트엔드에서 담당자 배정이 누락되어 구현해보지 못했다.
병민님이 백엔드는 프론트랑 상관 없이 일단 기능을 만들어 놓으면 필요할 때 가져다 쓰는거라고 의미 있는 위로를 해주셨다.
포스트맨으로 테스트했을 때 결과가 잘 나왔다고 말씀드리니 영주님~! 잘하셨어요~~ 해주셔서 많은 위로가 되었다.
그리고 백엔드에서도 담당을 앱 단위로 나누기보다 기능별로 나누는 것이 겹치는 부분을 제외하고 더 많이 배우는 방법 이었을것 같다는 생각이 들었다. 그래서 이건 다음 프로젝트때 꼭 고려해 보아야할 사항이다.

☑️ 기억에 남는 코드

검색

• 중간테이블을 통해서 filter 적용하기

내가 처음 생각했던 방식은 staff에서 배우 하나의 객체를 가져온다음, 중간 테이블을 통해서 가져오는 방식이었다.
처음부터 중간 테이블에서 filter를 통해 가져오는 방법이 존재한다는걸 뒤늦게 알게되었다.
중간 테이블을 통해서는 왜 아이디만 가져올 수 있다고 생각했을까? 꼭 기억해두어야겠다.

별점

-하나의 뷰로 두개의 기능 처리하기
movie와 user에서 공통으로 사용되는 별점 카운팅 기능으로 하나의 뷰로 두개를 처리할 수 있다는 사실이 흥미로웠다.

역참조, 정참조 이해

승현 멘토님께 역참조, 정참조에 대한 설명을 듣고 더욱 정확한 이해를 할 수있었다.
many to many관계에서 중간테이블로 filter를 사용할 수 있다는 사실을 알게되고
그러면 혹시 one to many관계에서는 어떻게 하나요? 하고 여쭤보았더니 알려주셨다.
나는 무조건 prefetch를 써야하는 줄 알았는데 그게 아니라고 하셔서 신기했다.

이렇게 지훈 멘토님께 문의하고 답변을 받기도 했다.
select_related와 prefetch_related에 관한 많은 혼란이 있었다.
이게 뭔데? 왜 써야하지? 하는 생각이 많이 들었던것 같다.
900개 되는 쿼리수를 단 몇개로 줄였다는 다른 팀 동기의 말을 듣고 그래서 쓰는거구나 하고 이해하긴 했다.

잘 정리된 블로그 링크
<Django / select_related와 prefetch_related를 정복해보자>
https://bmh8993.github.io/Django/select_related%EC%99%80-prefetch_related%EB%A5%BC-%EC%A0%95%EB%B3%B5%ED%95%B4%EB%B3%B4%EC%9E%90/