팀네이버 컨퍼런스 DAN 24, 20년된 Naver Cafe 서비스가 모듈화로 진화 하기 그후 1년

Computer Science

팀네이버 컨퍼런스 DAN 24, 20년된 Naver Cafe 서비스가 모듈화로 진화 하기 그후 1년

songmoro 2025. 2. 1. 15:13

728x90

원문(안드로이드): https://tv.naver.com/v/67446433

네이버 카페 아키텍처
- 사용했던 것: mvp
- 현재: mvvm + clean architecture

모듈
- app
- shared
  - repository, domain, util
- model
  - ntt, api
java
- 어노테이션 프로세스 2개

UI 접근 방식
- 데이터 바인딩, 버터나이프

아키텍처 목표
- 오래된 기술 스택 버리기
  - 유지보수 어려움
- 뷰 모델
  - 기능이 많아서 데이터 흐름 파악 어려움
- 모범 사례
  - 일관된 설계로 코드 해석 쉽게

구글이 말하는 모듈화
- 장점
  - 코드의 재사용성 증가
  - 기능별 코드 분리로 관리 용이성 향상
  - 독립적인 테스트 환경 제공
- 전략
  - UI, 도메인, 데이터 레이어
제일 강조하고 싶은 거
- 빌드 시간
  - 모듈화로 각각의 모듈 개별 빌드를 통해 빠른 결과

빌드를 언제 하나
- 배포
- TDD
- 개발
  - 빌드 시간을 줄이면 생산성 향상
앱 모듈 구조

모듈화 목적
- 유지 가능한 작은 코드 만들기
  - 각 레이어 간 분리로 간섭 방지
    - 독립적인 코드, 작은 코드
  - 규격화하기
  - bus factor 높이기

레거시 전환
- 문서화
  - 준비
- 어려운 코드 쉽게 바꾸기 혹은 지우기
  - 무엇을 바꿀지
- 리팩토링과 과제 분리
  - 어떻게 바꿀지
- 대규모 변화 vs 점진적 변화
  - 장단점

문서 내용
- 기능
  - 화면의 기능에 대한 정의
  - 예외 사항
- 링크
  - 기획, 디자인, 서버
- 플로우 차트 혹은 시퀀스 다이어그램

어려운 코드 쉽게 바꾸기 혹은 지우기
- 예전에 없었거나 몰랐던 기술로 인해 어렵게 쓰인 코드
  - 비동기 처리, ...
- 자바 -> 코틀린 변환으로 없어질 코드
  - for + if -> map, filter
- 새로운 기술 도입
  - 코루틴, 컴포즈

리팩토링과 과제 분리해서 배포
- PR이 복잡해지니 리팩토링, 과제를 분리
- 리팩토링 후 과제 추천

점진적 vs 대규모
- 대규모 변화 해야 할 때
  - 조금만 고쳐도 오류 발생
  - 배포 후 잦은 핫픽스
  - 레거시를 바꾸는 게 의문일 때
    - xml -> compose
  - 고려사항
    - 롤백 염두
    - 최소한의 코드로 새로운 버전과 기존 버전 오갈 수 있도록 작업

모듈 나누는 기준
- base
  - common
  - network
  - 인증
- data, domain
- feature

노하우
- 자동화된 리팩토링 리뷰
  - code move
  - unused code remove
  - optimize imports
  - auto formatting
  - kotlin convert
- stacked pr
  - 리뷰 순서
    - develop <- feature/A
    - feature/A <- feature/B
    - feature/B <- feature/C
  - 머지 순서
    - develop <- feature/A
    - develop <- feature/B
    - develop <- feature/C

노하우 2
- 파일 이동
  - 처음 이동은 다른 모듈에 동일 패키지로

당부
- 리팩토링을 위한 리팩토링
  - 새로운 기술 적용은 과제로
- 고립 전략
  - 지우지 못할 경우 고립시키는 것도 하나의 방법
  - 필요한 경우에만 제한적으로 접근

728x90