DEVIEW 2017 [SESSION 4] 오픈소스를 쓰려는 자, 리베이스의 무게를 견뎌라

DAY 1 / 15:00~15:45 / TRACK 1

오픈소스를 쓰려는 자, 리베이스의 무게를 견뎌라

Whale

1. Chromium 을 선택

   WebKit 기반의 자체 엔진으로 브라우저 개발을 시작했으나 결국 Chromium 기반으로 구현하기로 결정

2. 어떻게 수정할 것인가

   Chrome layer 를 직접 사용하여 개발

   Chromium 은 Browser(Chrome layer), WebView(Contents layer) 로 구성됨

3. 베타 출시

4. 빠르게 발전하는 크로미움

   • 베타 출시 때부터 최신 크롬과 버전차 발생. 크로미움 버전업 요구

5. 리베이스 필요

   • Chromium 52 > 58

6. 많은 Conflicts

7. 모든 개발자가 담당영역 리베이스 동시에 시작

   • 커밋 리플레이(커밋을 일일히 옮김)

   • 52 와 58 의 차이적용

8. 코드 리팩토링

   • Conflict 해결을 좀 더 쉽게 하기 위해 가드 사용하여 구분(#ifdef WHALE_DEV)

   • Conflict 를 줄이기 위해 섞여있는 코드를 구분하고 파일을 분리

     • 상속이 가능할 경우 별도의 파일로 구현

     • in-class initialization, 파일/함수의 중간에 추가코드 삽입, Alias 사용

9. 일정

   • 리베이스에 2개월 시간 소요, 리그레이션 처리에 4주 소요

회고

1. 발견하지 못한 여러 실수들

2. 신규 개발 일정 딜레이

3. 비효율적인 작업

   • 모듈들이 서로 의존적이여서 다른 작업자들의 일정에 영향을 받음

느낀점

리베이스 후 어려운 이슈(OOM, Crash) 들이 크롬 개발자들로 인해 해결

가성비가 뛰어난 작업, 코드 리팩토링&클린업의 기회

새로운 리베이스 방식 시도

개발자 한명이 리베이스를 시도

• 기계적인 리베이스

• 간단한 Conflict 는 직접 해결

• 구현자의 도움이 필요한 부분은 남겨둠

가능성을 봄

리소스 처리

과거: chromium 리소스를 직접 대치해서 Conflict 발생

리소스를 건드리지 않고 웨일의 리소스를 적용할 수 없을까?

현재: 빌드 시점에 웨일 리소스를 Chromium 리소스에 오버라이딩 하여 적용

리베이스 메인테이너 지정, 다른 개발자들은 각자의 영역에서 서포팅

전보다 빠른 처리 가능했음.

두번째 회고

컴파일 타임 리베이스

• 초기 코드 리베이스

• 담당 개발자가 Conflict 처리

런타임 리베이스

• 리베이스된 코드를 실행하여 잘 동작하는지 확인

컴파일 타임 리베이스 시간이 줄어듬.

검증 방법의 개선

• Unittest, Trybot 도입 필요