Skip to content

계획 소개

정동교 edited this page Jan 13, 2025 · 3 revisions

전체 계획

변하면 안되는 결과값:

  • 베팅 기능
  • 채팅 기능
  • 로그인/회원가입 기능
  • 마이페이지 오리 구매 기능

개선 및 리팩토링이 필요한 문제와 그렇지 않은 부분:

개선이 필요한 것 이유 기대 효과
테스트 자동화와 커버리지 개선 현재 테스트 코드가 하나도 작성되지 않아서 코드 수정시에 예상치 못한 오류가 발생할 수 있다. 코드 안정성을 높이고, 개발 효율성 향상
API 요청 최적화 현재 API 요청이 비효율적으로 많이 이루어지고 있는데, API 요청이 필요하지 않은 부분에서는 기존 데이터를 활용하고 캐싱을 활용해 동일 데이터를 여러 번 요청하지 않도록 개선, 현재 서버 비용도 투머치로 많이 나오는 중 네트워크 부하를 줄이고 UX 개선, 서버 비용 절감에 기여
상태 관리 개선 초기 상태 관리 방식이 간단한 애플리케이션에서는 문제없지만, 애플리케이션 규모가 커질수록 복잡해지기 때문에 개선이 필요하다. DX 개선 및 상태의 복잡성 개선
비동기 처리 최적화 비동기에 대해 딥다이브 코드 안정성과 응답 속도 개선
레디스 안정성 레디스 장애 시 복구하기 위한 방안이 존재하지 않아 서비스 전체 에러로 연결될 수 있음. 레디스 센티널 도입을 통해 레디스 장애 발생 시 자동 장애 조치
레디스를 이용한 큐 개선 기존에 구현한 레디스 큐는 메시지 순서 보장과 중복 메시지 소비를 방지하지 못함 메시지 큐 안정성 개선
  • 1주차: 테스트 자동화와 커버리지 개선(FE), 레디스 센티널(BE)
    • FE 성능 목표 : 핵심 비즈니스 로직에 집중하여 해당 부분의 커버리지를 80% 이상 달성
    • BE 성능 목표 : 레디스 장애 발생 시 자동 장애 조치
  • 2주차: API 요청 최적화(공통), 상태 관리 개선(FE), 메시지 큐 개선(BE)
    • FE 성능 목표 : React 개발자 도구를 이용하여 측정되는 상태 업데이트 후 목록 컴포넌트 렌더링 시간을 200ms에서 80ms로 60% 감소
    • FE 성능 목표 : 페이지의 CLS 점수를 0.1s 이하로 감소 시켜 데이터 응답으로 인한 레이아웃 변환을 감소 시켜 사용자 경험 증진
    • BE 성능 목표 : 기존 Redis 기반 메시지 큐에서 발생할 수 있는 문제를 Bullmq와 비교해 개선해보기
  • 3주차: 비동기 처리 최적화(FE) , 에러 핸들링 및 테스트 코드(BE)
    • FE 성능 목표 : 개발자 도구에서 Performance 성능 측정 시 측정되는 Aggregated time 중 Idle 시간을 30% 개선 시켜 성능 향상
    • BE 성능 목표 : 예외 계층 구조를 만들어 예외 핸들링 100% 커버
Clone this wiki locally