[6팀 전이진] Chapter 4-2. 코드 관점의 성능 최적화

[im-binary]

과제 체크포인트

과제 요구사항

• 배포 후 url 제출
  • https://im-binary.github.io/front_7th_chapter4-2/
• API 호출 최적화(Promise.all 이해)
• SearchDialog 불필요한 연산 최적화
• SearchDialog 불필요한 리렌더링 최적화
• 시간표 블록 드래그시 렌더링 최적화
• 시간표 블록 드롭시 렌더링 최적화

과제 셀프회고

기술적 성장

기존 fetchAllLectures 함수에서 Promise.all 내부의 await 키워드로 인해 직렬 처리되던 것을 수정하여 API 호출이 병렬로 실행되도록 개선했습니다.

requestWithCache 유틸을 구현하여 동일한 URL에 대한 중복으로 요청을 보내지 않도록 했습니다 .

기존에는 컴포넌트 내에서 매번 수행되던 필터링 로직을 useLectures 커스텀 훅으로 분리하고, useMemo를 적용하여 최적화했습니다. 검색 옵션(searchOptions)이나 강의 목록(lectures)이 변경될 때만 필터링 연산이 되도록 했습니다.

DnD 시 전체 테이블이 리렌더링되는 문제를 해결하기 위해 ScheduleTable 컴포넌트를 ScheduleGrid, DraggableSchedule 등으로 쪼개고 memo를 적용했습니다. DraggableSchedule.tsx에서는 드래그 중인 아이템의 상태 변화가 다른 아이템의 렌더링에 영향을 주지 않도록 했습니다.

코드 품질

src/ScheduleContext.tsx에서 schedulesMap 전체를 하나의 상태로 관리하다 보니, 단일 스케줄 변경에도 구독하는 모든 컴포넌트가 영향을 받는 구조가 되었습니다. 이 문제를 해결하려고 컴포넌트 분리를 많이 했지만, 상태 구조 개선이 더 필요할 것 같기도..? 합니다.

학습 효과 분석

과제 피드백

리뷰 받고 싶은 내용

성능 최적화를 위해 ScheduleTable을 ScheduleGrid, ScheduleItem 등으로 쪼개고 각각 메모이제이션을 적용했습니다.(src/components/ScheduleTables)
성능상으로는 이점이 있지만 파일 개수가 늘어나고 코드가 파편화되는 느낌을 받았습니다. 코치님은 유지보수성과 성능 사이에서 어떤 기준으로 분리 단위를 결정하시는지 궁금합니다.