3주차 팀프로젝트 중간점검

내가 일주일 동안 맡았던 업무는

• 프로젝트 소개 작성
• 카드 불러오기 중복 오류 해결
• 영화 검색 기능 고도화
• 로컬스토리지 사용하여 영화 검색 시 영화제목 및 작성시간 저장 기능 구현
• 최고평점 API 불러와서 카드 붙이기
• 최고평점, 너이영추천 카드 캐러셀로 만들어서 메인화면에 나타내기
• 네비게이션바 클릭시 캐러셀은 숨기고 해당 카드만 보여주기
• 16:9 반응형 CSS

 

이렇게 총 8가지 정도 작업을 했다. 팀프로젝트를 하면서 어떤 어려움이나 오류가 있었고 그에 대한 해결방법을 블로그에 정리해보려고 한다.

 

 

 

★ api로 카드를 불러올때 카드가 무한으로 화면에 출력되는 문제점 : 중첩된 반복문으로 인한 오류

1. 중첩된 forEach문을 먼저 제거했다. 이전 코드에서 movies.forEach 안에 또 다른 movies.forEach가 있어서 각 영화마다 모든 카드를 생성하는 문제가 있었다.
2. 영화목록 데이터를 가져오는 작업과 그 데이터를 화면에 출력하는 작업이 하나의 함수에 포함되어 있었기 때문에 두 로직을 분리했다.
3. getMovies 함수와 displayMovies 함수로 분리했다. (효과적인 네이밍)
4. getMovies 함수에서 영화 데이터를 가져온 후 별도의 displayMovies 함수를 호출하도록 설정했다.
5. displayMovies 함수에 movies_container.innerHTML = ' '; 를 추가하여 새로운 영화 카드를 추가하기 전에 기존 내용을 지우도록 했다.
6. 더 이상 사용하지 않는 temp_html 변수를 제거했다.

이렇게 수정된 코드는 각 영화에 대하여 한 번씩만 카드를 생성하고 화면에 출력한다. 따라서 영화 카드가 중복해서 나타나는 문제를 해결할 수 있었다. 

 

 

 

★ 네비게이션바 클릭시 캐러셀이 사라지지 않는 문제점

: 페이지 전환 시 요소들의 표시/숨김 처리가 제대로 이루어지지 않은 오류

 

1. togglePageElement 함수 개선

• 이 함수를 새로 구현하여 페이지 전환 시 모든 관련 요소들을 명시적으로 숨기고, 필요한 요소만 표시하도록 했다.
• 캐러셀, 컨테이너, 영화목록 컨테이너 등 모든 주요 요소들을 처리하도록 했다.

 

2. 페이지별 동작 구분

• switch문을 사용하여 각 페이지('main', 'view', 'hot', 'choice')에 따라 다른 동작을 수행하도록 했다.
• 메인 페이지의 경우 모든 캐러셀을 표시하고, 다른페이지들의 경우 네비게이션 컨테이너를 표시한다.

 

3. 초기화 로직 추가

• 함수 시작 부분에서 모든 요소를 먼저 숨기고 시작한다. 이렇게 하면 이전 상태에 관계없이 항상 원하는 요소만 표시할 수 있다.

 

4. 요소 선택자 개선

• querySelectorAll을 사용하여 여러 캐러셀 요소를 한번에 선택하고 처리할 수 있도록 했다.

 

5. 페이지 전환 로직 통합

• 모든 네비게이션 링크 클릭시 이벤트에서 togglePageElements 함수를 호출하여 일관된 페이지 전환 처리를 보장했다.

 

 

 

 

★ 반응형 css 작업중 창크기를 줄이면 만든 작업물이 깨지는 문제점 : 최소너비를 설정하지 않아 발생한 오류

1. 창크기를 엄청 줄였을 때, 검색창이나 검색 버튼이 깨지는 문제점 발견했다.
2. CSS 미디어 쿼리 검색창 부분에 최소 너비(min-width)를 설정해주니 창크기를 엄청 작게 줄여도 검색창의 최소한의 너비는 보장되었다.

최소너비(min-width) 설정하는 주요 이유

• 사용성 보장: 검색창이 너무 작아지면 사용하기 불편할 수 있다. 따라서 최소 너비를 설정함으로써 사용자가 편하게 검색어를 입력할 수 있는 최소한의 공간이 확보된다.
• 디자인 인관성: 매우 큰 화면에서 %만 사용하면 검색창이 지나치게 넓어질 수도 있다. 최소 너비를 통해 검색창의 최대 크기를 제한하여 디자인의 일관성을 유지할 수 있다.
• 레이아웃 안정성: 컨텐츠의 최소 크기를 보장함으로써 예상치 못한 레이아웃 깨짐을 방지할 수 있다.
• 반응형과 적응형의 균형: 순수한 반응형(%만 사용)과 적응형(고정 크기 사용) 디자인의 장점을 결합할 수 있다.

 

메인페이지에 최고의 평점, 너이영 추천 카드의 캐러셀을 출력했지만 네비게이션바 클릭시 캐러셀이 사라지지 않는 문제점 : 

 

 

 

 

Q. 반응형 CSS 작업할때, 언제 width를 써줘야 되고, 언제 max-width 써야돼? 라는 의문점이 생겼다.

검색해서 찾아본 결과를 정리해보겠다. 이 두 속성의 차이점과 각각 언제 사용해야 하는지 알아보겠다.

 

 

1. width의 사용

• 고정된 너비가 필요할 때 사용한다.
• 요소의 너비를 정확하게 지정하고 싶을 때 사용한다.
• 화면 크기와 상관없이 항상 같은 너비를 유지해야할 때 사용한다.

@media screen and (max-width: 1920px) {
  .container {
    width: 960px;
  }
}

이 경우, 화면 너비가 1920px 이하일 때, .container의 너비는 항상 960px이다.

 

 

2. max-width의 사용

• 요소의 최대 너비를 제한하고 싶을 때 사용한다.
• 반응형 디자인에서 더 유연한 레이아웃을 만들 때 사용한다.
• 화면 크기가 작아질 때 그 요소가 그에 맞춰 줄어들게 하고 싶을 때 사용한다.

@media screen and (max-width: 1920px) {
  .container {
    max-width: 90%;
  }
}

 이 경우, 화면 너비가 1920px 이하일 때, .container의 너비는 화면의 90%를 넘지 않지만, 화면이 작아지면 그에 따라 줄어든다.

 

 

사용 가이드라인:

1. 반응형 디자인을 만들 때는 주로 max-width를 사용한다
   • 이는 더 유연한 레이아웃을 만들어 다양한 화면 크기에 대응할 수 있게 해준다.
   • 예: max-width: 1200px; 또는 max-width: 90%;
2. 특정 요소의 크기를 정확히 제어해야 할 때는 width를 사용한다
   • 버튼, 아이콘, 또는 정확한 크기가 필요한 UI 요소에 적합하다.
   • 예: width: 200px; 또는 width: 50%;
3. 종종 두 속성을 함께 사용하기도 한다:

 

 

 

 

 

.

.

.

 

 

 

# 팀프로젝트를 하면서 느낀점

 

1주차보다 3주차 팀프로젝트가 확실히 어려웠다. 조금 더 어려운 기능구현을 시도해야 했고, 각자 코드 스타일이 조금씩 달라서 헷갈렸다. 물론 코드 컨벤션을 정했었지만 아직 변수에 효과적인 네이밍을 붙이는 것이 어려워 완벽하게 통일된 스타일을 유지하기는 힘들었다.

특히 API 연동과 비동기 처리 부분에서 많은 어려움을 겪었다. 데이터를 가져오고 처리하는 과정에서 예상치 못한 버그들이 발생했고, 이를 해결하는 데 많은 시간이 소요되었다. 하지만 이 과정을 통해 JavaScript의 비동기 처리에 대해 조금은 이해할 수 있었다.

또한, 깃허브를 통한 협업 과정에서도 여러 challenges를 마주했다. 브랜치 관리와 merge 과정에서 충돌이 발생했을 때, 이를 해결하는 방법을 배우는 데 시간이 걸렸지만, 결과적으로 버전 관리의 중요성을 깨달을 수 있었다.

팀원들과의 의사소통도 중요한 과제였다. 각자 맡은 부분을 개발하면서 서로의 진행 상황을 공유하고, 문제가 생겼을 때 함께 해결책을 찾아나가는 과정이 필요했다. 이 과정에서 명확한 커뮤니케이션의 중요성을 체감했고, 개발자로서의 협업 능력도 향상될 수 있었다.

프로젝트를 진행하면서 시간 관리의 중요성도 크게 느꼈다. 초기에 설정한 목표를 모두 달성하기 위해 노력했지만, 예상보다 많은 시간이 소요되는 작업들이 있었다. 이로 인해 우선순위를 조정하고 일부 기능을 간소화해야 하는 상황도 있었다.

결과적으로, 이번 프로젝트를 통해 기술적인 역량뿐만 아니라 협업 능력, 문제 해결 능력, 시간 관리 능력 등 다양한 측면에서 성장할 수 있었다. 앞으로의 프로젝트에서는 이번 경험을 토대로 더 효율적인 개발 프로세스를 만들어 갈 수 있을 것 같다. 특히 코드 리뷰를 더 자주 하고, 팀 내 지식 공유 세션을 갖는 등 협업의 질을 높이는 방안을 고민해 볼 필요가 있다고 생각한다.