카카오 T 택시 기사용 앱 Kotlin 적용기

6주에 걸쳐 카카오 T 택시 기사용 안드로이드 앱을 개편한 경험 공유
* 언어 변경: Java → Kotlin
* 라이브러리 변경
- AUIL → Glide
- Volley → Retrofit
- GCM → FCM

Transcript

1. 카카오 T 택시 기사용 앱 Kotlin 적용기 안세원 (kingori쩜gmail쩜com) 카카오모빌리티
2. 다룰 얘기 6주에 걸쳐 카카오 T 택시 기사용 앱을 개편한 경험 공유 • 언어 변경: Java → Kotlin • 라이브러리 변경 ◦ AUIL → Glide ◦ Volley → Retrofit ◦ GCM → FCM #2
3. 카카오 T 택시 기사용 앱 • 카카오 T 택시 서비스의 공급자(택시 기사)용 앱 • 2015년 출시됨 • 써보고싶다면 택시기사가 되시오! #3
4. 카카오 T 택시 기사용 앱 50대 이상 한국인의 힛트 앱?!? • 출근할 때 켜서 퇴근할 때 끔
 → 무시무시한 사용시간 • 하루의 수입에 직접적인 영향을 줌 
 → 안정성이 매우 X 10 중요! https://www.wiseapp.co.kr/ #4
5. 기존 기술기반 2015년 출시 후 큰 개편 없이 꾸준한 기능 추가 • Java • AUIL • Volley • GCM • ButterKnife • Otto → 바꿀 때는 되었지만 시간도 없고, 사람도 없고... #5
6. 때 마침 찾아온 여유?! • 연말은 카카오 T 서비스에 매우 중요한 시기 ◦ 업데이트는 사전에 마치고 연말엔 문제가 없는 이상 출시를 하지 않음 • 회사는 사람을 놀게 두지 않음
 → 놀면 뭐하니. 이 참에 카카오 T 택시 기사용 앱을 업데이트 하자! #6
7. 수행 기간 & 인원 • 수행 기간: 2017.12.6 ~ 2018.1.16 ◦ 크리스마스, 회사 송년회, 연말 휴가 등등 빠진 날 많음... • 투입 인원 : 대략 6MM ◦ ~2018.1.5 : 4명 ◦ ~2018.1.16 : 2.5명 ◦ 참여자 모두 Kakao T 앱을 개발해서 Dagger, Kotlin, Retrofit, RxJava 경험 있음 #7
8. 뭘, 어디까지 할 것인가? • Java → Kotlin • AUIL → Glide • Volley → Retrofit + RxJava2 • GCM → FCM • Stetho 도입 • MVP / MVVM / … • Dagger • Unit Test #8
9. 뭘, 어디까지 할 것인가? → 보수적으로! • Java → Kotlin • AUIL → Glide • Volley → Retrofit + RxJava2 • GCM → FCM • Stetho 도입 • MVP / MVVM / … • Dagger • Unit Test #9
10. 이 작업이 의미가 있는 건가요? • 기왕 하는 거, MVP / MVVM 정도는 적용해야 하는거 아닌가요? • 님, Dagger는 왜 빼나요? • 이 정도 바꿀거면 이 작업을 뭐하러 하나요? #10
11. 그래도 의미는 있지 않을까요? • Kotlin 자체가 주는 효용 ◦ 깔끔한 코드 / 짧은 코드 / Null 안정성 ◦ 기능 추가 / 개선 작업을 위한 효율적인 토대 마련 • 관리 기술 셋을 축소하여 팀의 기술 부채 감소 ◦ 구닥다리 기술 퇴출 : Volley, AUIL, Otto, ButterKnife #11
12. 작업 순서 • 주 단위로 목표 설정 ◦ 1주차 ( ~12/12) : Kotlin 변환 ◦ 2주차 ( ~12/19) : 라이브러리 적용 #1 : 일부에 시범적용 ◦ 3 ~ 5주차 ( ~1/9) : 라이브러리 적용 #2 : 전면 적용 ◦ 6주차 ( ~ 1/ 16) : 매뉴얼 테스트 • Jira로 작업 관리 ◦ 주 단위 작업을 Task로 만들고, 각 담당자 별 SubTask생성 #12
13. 1주차 : Kotlin 변환 • 1주차 ( ~12/12) : Kotlin 변환 • 2주차 ( ~12/19) : 라이브러리 적용 #1 : 일부에 시범적용 • 3 ~ 5주차 ( ~1/9) : 라이브러리 적용 #2 : 전면 적용 • 6주차 ( ~ 1/ 16) : 매뉴얼 테스트 #13
14. 1주차 : Kotlin 변환 • 이쁘지 않아도 좋으니 빠르게 전체 코드를 java -> kotlin 으로 변환 ◦ Android Studio 의 자동 변환 기능 적극 활용 • 긴가민가한 부분은 길게 고민하지 말고 //fixme 주석 달아놓기 • 4명이 각기 영역을 나눠 기계적으로 변환 ◦ Activity & Fragment ◦ 온갖 Manager / DB / PUSH ◦ API / Model ◦ 기타 : Application , Constant, Preferences, Utils → 12/13일 기준, 250개의 java 파일 ⇒ 231 개의 kt 파일 + 1개의 java 파일
 (누구니, 하나 빼먹은 사람?) #14
15. 기계적 변경도 쉽지만은 않더라 • Nullability에 대한 고민 : 일단은 ? 와 !! 남발하자 • 동시에 모든 파일을 변환한게 아니니 java <-> kotlin 상호 존재하는 과도기 존재 
 : 일단은 @JvmStatic , @JvmOverloads 남발하자 • 도구가 너무 욕심을 부려 오히려 알아보기 힘든 코드 생성
 : java 코드와 상호 대조하여 쉽게 풀어쓰자
 → 기존 프로젝트를 한 벌 clone해 둔 다음, 원래 java 파일을 옆에 띄워두고 작업 #15
16. 2~5주차 : 라이브러리 적용 & 정리 • 1주차 ( ~12/12) : Kotlin 변환 • 2주차 ( ~12/19) : 라이브러리 적용 #1 : 일부 부분에 시범적용 • 3 ~ 5주차 ( ~1/9) : 라이브러리 적용 #2 : 전면 적용 • 6주차 ( ~ 1/ 16) : 매뉴얼 테스트 #16
17. AUIL → Glide • 기술적인 고민보단 하땀 한땀 API 변경해 줘야 하는 작업이 많음 ◦ 이미지 표시 옵션 ◦ 성공/ 실패 콜백 • 기존 disk cache 이미지 마이그레이션? ◦ 기사용 앱에는 기사님 프로필 사진 정도의 캐시 이미지만 의미가 있음
 → 기존 디스크 캐시 이미지는 과감히 삭제 • 2઱ରী ੸ਊ ৮ܐ #17
18. ButterKnife → Kotlin Extension • Kotlin Android Extension을 사용하면 ButterKnife를 사용할 이유가 없음 • ButterKnife로 선언한 뷰 필드 제거 후, 뷰 필드를 직접 접근하도록 변경 • OnClick 등의 애노테이션은 그냥 한땀 한땀 변환 • kotlin extension 사용 시 주의! ◦ RecyclerView의 ViewHolder 등의 클래스에선 뷰 caching 안됨 ◦ Fragment 의 view destroy 이후 최초 필드 접근 시 NPE 발생 ▪ onDestroyView() 호출 시 flag 설정하여 fragment view 갱신 시 확인코드 추가 • 2઱ରী ੸ਊ ৮ܐ #18
19. Otto → RxBus • Otto 이벤트 버스를 RxBus 로 대체 • 가급적 적게 쓰는 게 좋겠지만, 일단 대체하고 나서 생각하자. • Event Type 은 그대로 유지, @Subscribe 메서드를 RxBus.listen() 으로 교체 • 2઱ରী ੸ਊ ৮ܐ #19
20. Volley → Retrofit + Gson + RxJava API 하나 하나 마다 꽤 많은 손이 가는, 가장 큰 작업
 → 한명이 기본 구조를 만들어 전파, 4명 모두 영역을 나눠 변환 작업 수행 • JsonObject 기반의 모델을 Gson 으로 변경 • Kotlin data class로 모델 클래스 개편 ◦ Nullable / Non-null 여부를 서버쪽과 협의하여 API 재검수 • Retrofit으로 API 한땀 한땀 변경 • 응답을 Volley의 callback 객체에서 RxJava single 구조로 변경 • 2주차에 샘플 개발, 3,4주차에 전면적용 #20
21. 기타 도구 적용 • Stetho : 구동중인 앱의 상태 조작 (dumpapp plugin 활용) ◦ http://facebook.github.io/stetho/ • Chuck : http / socket 통신 모니터링 ◦ https://github.com/jgilfelt/chuck • Timber : logcat logging ◦ https://github.com/JakeWharton/timber #21
22. 6주차 : 매뉴얼 테스트 • 1주차 ( ~12/12) : Kotlin 변환 • 2주차 ( ~12/19) : 라이브러리 적용 #1 : 일부에 시범적용 • 3 ~ 5주차 ( ~1/9) : 라이브러리 적용 #2 : 전면 적용 • 6주차 ( ~ 1/ 16) : 매뉴얼 테스트 #22
23. 매뉴얼 테스트 아쉽게도 자동화 테스트는 아직… 열심히 손으로 테스트하자 • QA팀에게 전체 Test Case 전달받음 • 수행 인원 3명 : 전체 기능을 3개 범위로 나눈 후, 서로 다른 영역을 2번 테스트 • 1차 수행 후 발견된 에러 수정하여 2차 수행 시 정상 동작 재확인 → 큰 문제는 발견되지 않았음 #23
24. 다 했으니 릴리즈…? 리펙터링된 브랜치에 스마트호출 기능 개발하여 출시
 → 앱 출시는 3월 중순 • 스마트 호출 기능 개발 • 그 사이에 개발된 java 기반 커밋들은 
 kotlin 으로 변환하면서 한땀 한땀 머지 • 스마트 호출 포함, 전체 QA 수행 #24 https://news.v.daum.net/v/201804100942333
25. 릴리즈 결과 • Fragment 의 onDestroyView 이후 kotlin extension의 view 접근 시 NPE 발생 ◦ 건수가 많지 않아 향후 패치로 수정 • 그 외의 NPE는 거의 없었음 • 성공적! #25
26. 회고 : 프로젝트 • 범위를 보수적으로 잡기 잘 했음 ◦ 기간, 인원 모두 처음보다 줄어들었음: 급한 일이... ◦ 전면 개편을 할 땐 아는 기술 위주로 후딱 후딱 작업하자 ◦ MVP 적용 등 구조까지 고쳤다면 훨씬 힘들었을 것 같음 • 1주 단위 관리도 좋았음 ◦ 작업 가시성 확보 ◦ 1주 이상 걸릴 작업도 별로 없었음 • 구조 개선이 없어도 Kotlin 전환은 의미 있는 작업 ◦ 줄어든 NPE, 간결화된 코드 ◦ 명확한 Nullability #26
27. 회고 : 기술 • Retrofit + RxJava 전환이 가장 공수가 많이 들었음 ◦ Model, Service, RxJava subscribe 구조 변환 ◦ 한명이 우선 샘플을 만든 후, 다 같이 나눠 작업해야 함 • Kotlin 변환은 쉽지만은 않음 ◦ companion object ◦ 난무하는 !! ◦ 쓸데 없이 최적화시킨 비교구문
 → 무조건 단기간에 전체 변환을 목표로! : Java-Kotlin inter-operation 최소화 ▪ 팀 내 규칙을 정해 todo , fixme 주석을 적극 활용 #27
28. #28 끝