프로젝트가 끝났다. 준비 단계에서 계획한대로 잘 되었는지 후기 겸 회고록을 작성해보려고 한다.
👉 준비 단계 보러가기

프로젝트 소개

• 자세한 기능 소개는 깃허브 README.md를 참고하기!
  👉 https://github.com/ohy9205/movie/tree/dev

• 배포 사이트는 여기!
  👉 https://ohy9205.github.io/movie/sign_in

후기

일정

계획했던 일정은 2023/1/2 ~ 2023/1/8
실제 걸린 일정은 2023/1/2 ~ 2023/1/10
약 이틀정도 더 지체되었다.

왜 일정을 지키지 못했니

시간이 지체된 원인을 생각해 보았고 몇가지 이유를 꼽을 수 있었다.

자료조사를 대충한 죄

프로젝트를 계획할 때 막연하게 '당연히 API는 있겠지~' 하고 생각했는데 그게 완전히 불찰이었다.

계획 하기에 앞서 자료 조사부터 끝냈어야 했는데 안일하게 생각하고 아묻따 계획하고 시작해버려 마땅한 API를 찾는데만 반나절~하루 정도를 꼬박 쓰게되어 결론적으로 하루를 날리게 되었다ㅠ

디자인은 간단하게라도 잡아두자

이번엔 레이아웃 정도만 생각하고 디자인은 전혀 계획하지 않고 프로젝트를 시작했다.

그런데 막상 구현하니 생각보다 레이아웃이 이상하기도 하고 디자인을 어떻게 해야될지 갈피를 잡지 못해 이런저런 디자인을 시도해보는 것에도 시간을 너무 많이 잡아먹었다.

기능

계획한 필수 기능은 모둗 구현했지만 개선해야 할 부분이 있다.

개선사항은 각각의 게시글에 적어두었지만 그 중 우선적으로 처리할 것들을 몇가지 추려보자면

로그인 성공 시 / 경로로 이동되지 않는 문제

로그인에 성공하면 / 페이지로 이동되도록 구현했는데 특정 상황에선 이동이 안되고 로그인 페이지가 새로고침 되는것으로 보인다.

아직 문제가 발생하는 상황을 정확히 파악하진 못했지만 로그인 페이지는 사용자가 처음 접근하게 될 페이지인 만큼 가장 최우선적으로 해결할 상황이다.

박스오피스 조회가 오래걸림

지금은 api를 통해 박스오피스 데이터를 받아오고, 해당하는 데이터를 데이터베이스에서 검색해서 가져오고 있다.

그런데 이렇게 하니 데이터베이스에 영화 정보가 늘어날때마다 박스오피스를 검색하는데 시간이 오래걸린다는 문제가 발생했다.

이 문제는 데이터베이스에 박스오피스 영화를 따로 저장하는 방법이나 캐싱을 이용하는 방법으로 개선할 수 있을 것 같다.

메인 페이지에서 캐러셀 크기로 인해 UI가 뒤틀리는 현상

웹 페이지를 반응형으로 만들었더니 메인 페이지에서 캐러셀 너비로 인해 UI가 뒤틀리는 현상이 발생했다.

캐러셀에 고정 너비를 지정했기 때문에 발생하는 문제로 보인다.

지금은 영화 포스터 이미지 너비를 180px로 고정했기 때문에 캐러셀까지 고정 너비로 지정했는데 이미지와 캐러셀 너비를 모두 퍼센트로 변경하다면 해결할 수 있을 것 같다.

아쉬운 점

프로젝트 구조가 이게 맞나

계획단계에서 구상한 프로젝트 구조는 이랬다.

📦src
 ┣ 📂api // API 관련
 ┣ 📂components	// 컴포넌트
 ┃ ┣ 📂ui // 공통style을 위한 box컴포넌트나 html요소 컴포넌트 
 ┣ 📂pages // 라우팅 처리되는 페이지 컴포넌트
 ┣ 📂store // context, redux 등 state관리
 ┣ 📂util // 데이터 포맷 등 부가적인 기능을 수행하는 메소드

구상 시에는 의도한대로 정리가 잘될것 같았지만 막상 진행하다보니 별도의 파일로 분리하는게 맞는것인지 애매모호한 기능들이나 컴포넌트들이 생겼다.

되도록이면 파일을 분리하는 방향으로 만들었는데 파일이 많아지니 너무 너저분하게 보여 생각보다 불필요한 파일들이 많아진게 아닐까 싶은 생각이 든다.

하지만 이건 프로젝트를 많이 경험하고 감을 쌓으면 추후에 충분히 개선할 수 있는 부분이라고 생각한다.

중복된 API코드

지금은 firebase의 database realtime API와 storage API를 각각의 파일로 구분해 두었는데 firebase 설정 부분이 중복되는 문제가 있다.

막연하게 생각하면 class나 extends 등을 이용해서 개선할 수 있을 것 같은데 아직은 적당한 해결방법을 찾지 못했다. 추후에 프로젝트를 리팩토링하면서 계속 고민할 생각이다.

commit의 '비'습관화

애초 계획은 작업별로 commit을 하자는 것이었는데 잘 지켜지지 않았다.

어떤 기능을 구현하면서 이전의 작업을 수정하는 등의 일이 생기다 보니 커밋을 하는 시점이 모호해지고 무엇보다 commit을 하는걸 자꾸 까먹는게 제일 문제였다. commit하는걸 까먹은 경우엔 뒤늦게라도 되도록 작업별로 커밋하기위해 노력했지만 간혹 하나의 파일에 여러 작업이 포함되버린 경우에는 어쩔 수 없이 하나의 커밋에 여러 작업 내용이 업데이트되는 일이 생겼다.

아직까진 나에겐 커밋이 숙제처럼 느껴지는 것 같다😥

커밋 메시지 포맷을 통일하지 못한것도 아쉬운 점이다. 다음부터는 계획단계에서 커밋을 어떻게 작성할 것인지도 잡고 들어갈 생각이다.

하지만 이번에 깃을 활용한 부분도 있다!
위에서도 말했듯이 생각보다 UI 디자인에 시간을 많이 잡아먹었는데, 이 때 레이아웃까지 이리저리 변경하는 작업을 branch별로 나누어서 했다. 각각의 브랜치에 각각의 레이아웃과 스타일을 적용시키면서 진행했는데 깃이 없었다면 어느천년에 하나하나 다 수정하고 있었을지 상상도 안된다...

추후 계획

1. 추가 기능 개발
   추가로 댓글 기능과 리뷰 기능을 구현하려고 한다. 리뷰엔 별점도 남길 수 있으면 좋을 것 같다
2. 타입 스크립트로 변환
   타입스크립트 학습이 끝나면 프로젝트를 타입스크립트로 변환시킬 예정이다. 프로젝트를 업그레이드 시키면서 타입스크립트도 실습해볼 수 있는 기회가 될거같다.