-
Notifications
You must be signed in to change notification settings - Fork 2
1주차 진행 계획
fru1tworld edited this page Jan 10, 2025
·
2 revisions
전체 계획에 대한 내용은 우리의 리팩토링 목표 페이지를 참고해 주세요!
스케일업은 힘들 것 같다는 생각이 들었습니다. 따라서 확장 가증한 코드로 변경하고 싶다는 생각이 들었는데요.
서버 아키텍처는 이렇게 그려져있지만 실제로는
다음과 같이 되어있습니다. 즉 NestJS에서 WebSocket 서버와 API 서버가 같이 실행되고 있습니다.
그러나 트래픽이 몰린다는 확장하기 어렵다는 특성이 있어서 확장 가능하게 구현하고자 합니다.
첫 주 계획은 다음과 같습니다.
API 서버와 WebSocket 서버를 분리합니다.
API 부분은 Note와 Space에 대해서 MVC 패턴이 적용되어
[Note | Space]Controller -> [Note | Space] Service -> DB 와 같은 형식으로 되어있고
WebSocket 부분은
GateWay -> Collaborative Service -> [Note | Space] Service -> DB 와 같이 [Note | Space] Service에 강하게 결합되어있습니다.
따라서 첫 주차에는 API 서버와 WebSocket을 분리하고자 합니다.
CRDT 반영 테스트하는 부분은 희진님과 함께 분배해서 진행 예정
목표: 유지보수 용이성을 향상시킨다.
- 웹 소켓 서버 통신 테스트: 웹소켓 연결 상태, CRDT 동기화 테스트
- CRDT 반영 테스트: 공유 데이터에 따라서 그래프 뷰, 에디터 화면을 올바르게 표시하는지 테스트
목표 1: 그래프 뷰 화면에서 20명이 동시에 노드를 생성하는 상황에서 4G 환경에서 평균 네트워크 지연 시간이 100ms를 초과하지 않는다. (사용자의 노드 생성 주기는 2s로 가정한다.)
목표 2: 에디터 화면에서 20명이 동시에 텍스트를 입력하는 상황에서 4G 환경에서 평균 네트워크 지연 시간이 100ms를 초과하지 않는다. (사용자의 타자 속도는 331 TPM로 가정한다.)
목표 3: 그래프 뷰 화면에서 10,000개의 Node와 9,999개의 Edge가 존재하는 경우 프레임 렌더링 시간이 16ms를 초과하지 않고, 단일 프레임의 Draw 호출 수가 1,000개를 초과하지 않는다.
목표: 스페이스 화면에서의 렌더링 시간을 10% 이상 단축시킨다.
- 메모이제이션, 코드 스플리팅 등 활용
- React DevTool을 활용해 렌더링 시간 측정
이벤트 핸들러 관련된 로직은 옵저버 패턴 활용하여 병주님과 같이 개선 작업 진행 예정
목표 1: 평균 Cyclomatic Complexity를 10 이하로 낮춘다.
목표 2: 코드 중복도를 20% 이상 낮춘다.
목표 3: 한 파일 당 평균 150줄 이하를 유지한다.
- 상태 관리 및 비즈니스 로직 분리, 컴포넌트 업데이트 방식을 디자인 패턴을 활용해 리팩토링
- ESLint, SonarQube 등을 활용해 코드 복잡도와 중복도 측정
- 고려 중인 패턴: 디렉토리 구조 아키텍처, 옵저버 패턴, 팩토리 패턴 등