Release 1.1.0 (January 17, 2025) · boostcampwm-2024/refactor-web11-road_to_friendly

1️⃣ FE 설계 구조 문제점 분석 및 개선 작업 PR #1

서비스의 Phase 전개에 따른 UI 전환이 소켓 메시지 url에 따른 Room 컴포넌트 내부 상태 플래그들의 변화에 의존하고 있음
- 방 입장(Phase 1) → 대기 화면 출력(isIntroViewActive: true) → 방장의 시작 대기 → 방장이 시작 → 소켓서버로부터 질문 목록 수신 → isIntroViewActive: false → 질문에 대한 응답 입력 및 표시(Phase 2) → 마지막 질문이 끝나면 isResultView: true → 소켓서버로부터 관심사 분석결과 수신 → isContentShareVisible: true → 통계 및 컨텐츠 공유 화면 표시(Phase 3)
- Room 컴포넌트에서 관리하고 있는 페이지 전환 관련 플래그가 너무 많아서 책임이 커 보임
- 페이지 분리가 직관적이지 않고 새로운 기능(Phase 단위) 추가에 대한 확장성이 떨어짐
  - 지금 구조에서 새 기능을 추가하려면 또다른 플래그를 추가해야 함
결합도가 높은 컴포넌트들이 존재함
- RoomIntroView가 호스트, 참여자별 대기 페이지(Phase 1)와 QnA 페이지(Phase 2) 모두에 대한 렌더링 책임을 지고 있음

Phase 전환을 트리거하는 소켓 메시지를 수신할 때 Room 플래그를 변경시켜 UI를 변화시키는 대신, 일치하는 Phase에 해당하는 URL로 내비게이션하도록 Routing 설정하여 확장성 개선
- 전체 Phase에 공통으로 존재하는 Header, ParticipantContainer를 React Router의 children, <Outlet> 으로 공통 레이아웃 처리
- Room 컴포넌트에서 UI 전환을 위해 관리하던 많은 플래그 상태들을 제거

기존에는 /rooms/roomId URL 페이지 하나에서 모든 페이즈가 단방향으로 진행되었으나, 이번 리팩토링으로 페이즈별 URL과 일치하는 UI를 표시하게 되어 추후 페이즈 추가, 페이즈 간 이동, 재연결 등을 구현함에 있어 용이함
여러 컴포넌트들이 수많은 상태 플래그에 의존하며 서로 결합되어 있던 로직을 분리하여 코드 가독성과 확장성, 유지보수성을 높임

서비스의 특이성: 첫 렌더링 시 서버로부터 많은 정보를 받아오는 일반적인 서비스와는 다르게, 다중 사용자와 실시간으로 소통하며 정보가 쌓이며 단계적으로 렌더링하는 서비스.
성능 측정을 위해선 방 생성 ⇒ 다중 사용자 참여 ⇒ 게임 시작 ⇒ 각 사용자들의 입력이라는 일련의 프로세스가 필요. 또한 이 과정에서의 렌더링 성능을 지표로 판단하기 위해서 Performance 탭의 녹화를 이용할 필요성
이런 과정을 매 측정 시마다 직접 하는 건 불편할 뿐만 아니라, 측정 결과값에 사용자의 입력이 들어간다는 점에서 부정확하다는 단점이 존재
또한 성능 문제가 생길 정도로 많은 사용자 입력은 혼자서 시뮬레이션 하기엔 현실적으로 어려움. 여러 상황, 여러 변수값들을 조정하며 측정하기 위해선 자동화가 필요

Puppeteer 를 이용해 브라우저를 열고, 탭을 여러 개 연뒤 방 생성, 각 탭마다 방에 참여, 다 모일 시 게임 시작, 각 탭에서 정해진 속도로 입력 후 전송하는 일련의 과정을 자동화
해당 과정을 자동으로 녹화해 크롬 DevTools에서 열 수 있는 trace file 을 생성
RECORD_DURATION , INPUT_DELAY , MAX_KEYWORDS_NUM , KEYWORDS_PROCESS_INTERVAL 등 성능과 측정에 영향을 미치는 값들을 상수화하고, 매번 다르게 해 측정할 때 구분할 수 있도록 파일명에 추가

사용자 인터렉션과 서비스 흐름을 자동화함으로써 성능 측정이 간편해짐
성능 측정에 유의미한 값들을 조정하며 여러 케이스를 가정하는 세부적인 측정과 각 케이스 간 비교가 가능해짐
현재 보고서 파일을 통계 처리 하는 로직은 존재하지 않음, 그러나 개선 전후의 차이를 정량적으로 나타내기 위해서 필요성을 느껴 추후 추가 예정.