일단 먼저 내놓는 미니프로젝트 후기 [ 11/1 - 11/5 ]

개발기간 : 11/1(월) - 11/5(금)

개발인원 : 탁예준, 김용빈, 백정수

프로젝트명: Youtube random playlist

github : MiniProject_v1: Youtube random playlist (github.com)

 

<Youtube Data API>

1. API 정보 제공이 너무 불친절했다.

- API 문서에 part는 뭐고 id는 뭔지, item에는 뭐가 들어있고 snippet은 뭔지 제대로 명시해준것이 하나도 없었다. 결국 직접 쿼리를 보내보면서 인자들이 무슨 역할을 하는지 알아냈어야 했는데, 이 과정이 너무 비효율적이었고 많은 시간을 소요하게 만드는 원인이 되었다.

함수 호출에서도 이에 따른 문제가 발생했는데, 어떤 파라미터를 어떻게 넣어야하는지 상세하게 파악이 되지 않아 쿼리 조건을 구성하는데 어려움이 많았다. 개발 막바지에 들어서는 문서의 문구들을 이해할 수 있었지만, 처음 보기에 직관적이지 않았던 점이 큰 장벽으로 다가왔다. 배우는 입장에서는 API 문서를 보는 법을 배운 것 같아 큰 도움이 되긴 했다. 그래도 조금만 더 친절했더라면.. 좋았을텐데...

 

2. 단일 영상의 재생과 재생목록의 재생을 혼용할 수 있는 플레이어의 개발이 불가능했다.

- 개발하면서 깨달았던 점인데, 유튜브 영상에는 단일영상의 재생과 재생목록의 재생을 위한 플레이어가 별도로 존재한다.

그리고 Youtube Data API는 단일 영상 재생과 플레이리스트 재생을 혼용할 수 있도록 하는 기능을 지원하지 않는다.

두 개의 모드를 혼용하는 일이 거의 없기 때문이었을 것으로 보였지만, 우리의 프로젝트의 핵심 기능이 이 부분이었기 때문에 기술적인 한계를 극복하고 구현해낼 방법이 필요했다.

이에 대한 해결방법을 찾던 중, 결국 둘 중 API 핸들링 중요도가 낮은 것을 iframe 태그로 불러오는 방법을 채택하기로 했다.

이번 프로젝트에서는 단일영상에 대한 상세정보들을 얻어오는것이 중요했으므로 재생목록을 iframe으로 불러오기로 결정했다.

 

3. 그럼에도 해냈다

- 기술적인 한계를 극복하는것은 즐거운 경험이다. 공식적인 방법은 아니지만 결국 두 개의 플레이어를 사용자의 경험상으로는 하나처럼 느껴지도록 만들어냈고, 이 부분은 매우 성공적이었다.

 

 

<MongoDB>

1. RDBMS처럼 구성해버렸다.

- 컬렉션을 정의하는 과정에서 습관처럼 Join으로 프로그램을 풀어나갈 생각으로 RDBMS처럼 관계를 정의하여 DB를 구성했다. 나중에서야 깨달았다. 나는 MongoDB에서 Join하는 방법을 모른다는 점을.

- 이후 비효율적이게도 관계를 크게 신경쓰지 않아도 되도록 컬렉션을 다시 정의해서 현재 당면한 위기는 벗어났지만, MongoDB의 문법을 익히는 것도 미래의 숙제가 될 것 같다.

 

 

<html/css>

1. 디자인 요구사항에 맞출 수 있는 역량이 부족했다.

- display에 대한 이해도가 부족했다. block과 inline에 대한 이해는 있었지만, flex, grid에 대해서는 하나도 알지 못 했다. 이것은 화면 구성을 어렵게 하는 결과를 낳았다. 결국 디자인 수요를 완전히 만족시킬 수 없는 산출물이 탄생했다. 프로젝트 인원에 프론트엔드를 알고 있었던 사람이 있었더라면 어려움이 없었을 것 같다.

 

2. 단일페이지가 여러 기능을 하도록 만드는 것은 아주 어렵다는 것을 깨달았다.

- randomplaylist 페이지는 사용자가 보기엔 마치 한 가지 기능만을 하는 페이지로 보이지만, 기능적으로 본다면 두 가지 기능을 한다. Youtube Data API 내용과 이어지는 부분인데, 재생하고자 하는 영상이 단일 영상일때와 재생목록일때의 플레이어 사양이 다르다보니 한 페이지에 두 개의 플레이어를 불러온 채로 교차로 hide, show 하며 표시해줘야했다. 그러면서 페이지의 기능또한 전환되어야 했다.

 재생목록에서는 좋아요 버튼, 좋아요 목록, 댓글을 표시해야 했고, 설명 블럭이 재생목록의 작성자와 명명한 플레이리스트 제목으로 나타냈어야 한다면,

 단일 영상에서는 좋아요 목록과 댓글을 보이지 않게 하고 좋아요 버튼 대신 다음 영상으로 가는 버튼과 설명 블럭이 영상의 실제 게시자명과 영상의 제목으로 나타났어야 했다.

 이 기능들은 전체적으로 매우 성공적으로 구현됐기 때문에 만족도가 높았다.

 

 

<javascript/python>

1. 일관적이지 않은 언어 사용이 있었다.

- 미리 사전에 정의를 해놓지 않아서 기억에 의존한 규칙을 설정하다보니 변수 및 함수의 이름의 규칙성을 무시하는 코드들이 많았다. 언제는 tag_insert로 했다가 언제는 addtag로 했다가... 네임스페이스들에 대한 정의는 사전에 해두는것이 중요하다는 것을 깨달았다. 미래에 자신의 코드를 보고 쉽게 기억해낼 수 있도록 나만의 정의 방식을 정립해야할 필요성을 느꼈다.

 

 

<코드상에서 만족했던 부분들>

 1) user token 받아오기 기능 구현

   - jwt 방식을 사용하면서 사용자의 정보가 쿠키 내의 토큰에 보관되도록 되어서, 이것의 유효성만 검증할 수 있는 기능이 있다면 어떤 기능에서든 부담없이 호출해서 사용자의 정보가 유효한지 확인할 수 있게 되었다. 이 부분을 하나하나 구현한 것이 아닌 하나의 함수로 만들어 유지보수성을 높이고 재사용을 용이하게 만들었던 점이 매우 만족스러웠다.

 

 2) 좋아요 목록을 n개는 표시하고, 나머지는 +n과 같은 숫자로 표시하기

   - 구현하고보니 전체 내용을 받아온 뒤 일부분만 출력하고 나머지는 개수로 치환시켜버리면 되는 간단한 기능이었지만, 만들 때까지의 고민이 약간 있었다. 소소한 기능이었지만, 개발을 하는데 고민이 들어가는 것은 꽤 즐거운 일이기 때문에 재미있게 만들었다.

 

 3) DB에서 집단함수를 적용하는데 성공했다.

   - 기능을 만들고보니 페이지에 실제로 적용된 기능은 아니었지만, 그룹핑을 한 뒤 count를 출력할 수 있었다. 처음 써봤고 잘 됐기 때문에 만족했다.

 

 4) **fwarg 형식을 이용한 user token 파라미터 전달의 간편화

   - user token 변수를 list 형식으로 구성하여 파라미터 전달을 유동적으로 해서 사용자의 유효성 검사를 원한다면 javascript 단에서도 할 수 있도록 만들고자 했는데, 의도대로 잘 되었다.