[번역] DroidKaigi 2016 ~ Cookpad에 있어서 Android 엔지니어의 역할과 그 변화 May 20, 2016. | By:
pluulove
본 포스팅은 クックパッドにおけるAndroidエンジニアの役割とその変遷
을 기본으로 번역하여 작성했습니다
제 일본어 실력으로 인하여 오역이나 오타가 발생할 수 있습니다.
실제 슬라이드의 일본어 부분을 번역했다는 점 양해바랍니다.
1p
대상자
모바일 개발팀을 이끄는 사람
참가하고 있는 사람
지금부터 만들려고 생각하고 있는 사람
2p
이야기할 내용
적은 인원으로 1팀 체제시대에서 다양한 사업부 많은 인원 체제시대까지 Android 엔지니어의 역할이 바뀌는 중, 팀이 직면한 과제와 그것을 해결하기 위해 구축해온 개발 프로세스나 습관, 구조
바로 도입할 수 있을법한 것을 중심으로 소개
※코드는 나오지 않습니다.
3p
Cookpad에 있어서 Android 엔지니어의 역할과 그 변화
를 지탱한 개발 프로세스
4p
자기소개
Toshihiro Yagi (@sys1yagi)
Android Engineer
Cookpad 주식회사 매물정보사업부 소속
2013년 입사
최근 취미 : Github에 Daily Commit
6p
국내 「Cookpad」 이용현황
7p ~ 8p
Cookpad Android
mobile app 전체의 월간 이용자 수 (MAU) 927만
→ 의 40% 정도가 Android
※2015년 12월 시점
9p
적은 인원 체재 시대
2013년 10월~
하이브리드 어플 -> native 어플 전환
totally from scratch
Android 엔지니어 3인
10p
적은 인원 체재 시대
11p
해본 것
Web에서 제공하고 있는 기능을 native에 이식하기
필요한 API를 추려내고, 사양작성, 조사
Android 특유의 디자인과 경험을 만든다
다량의 issue를 오로지 소화
12p
3명의 개발스타일
Github Enterprise로 issue 관리
Pull Request & Review
CI(Jenkis)로 master branch 빌드
Deploygate에 debug 버전을 배포
13p
Android 엔지니어의 역할
14p
2014년 3월 배포
2014년 3월 25일 화요일
2014년 3월 25일 화요일
평균 세션 시간: 00:02:26
평균 세션 시간: 00:02:58
Android: 00:02:26
Android: 00:02:58
15p
2014년 3월 Mobile First실 설립
16p
많은 부서 체재 시대
17p
당시 내 생각
아마도 움직일 테니깐 배포하자
18p
아마도 움직일 테니깐 배포하자
척척 기능을 개발
bug가 발견되면 마구 수정
스피드있는 배포하기
그것이 가치를 제공하는 것으로 연결된다
19p ~ 20p
하지만 매번 업데이트하면…
Crashlytics
가벼운 버그라도 실패로…
14000 crash / day
12000 UU에 영향
20p
무엇을 언제 변경했었지?
21p
언제 끝나?
○○기능을 넣고 싶은데 예정을 잡고 싶은데 다음 버전은 언제 됩니까?
모릅니다
22p
과제
업데이트하면 곧바로 십수만 명이 이용하기 시작한다, 경기한 버그가 큰 영향을 주게 된다
mobile app은 Web 서비스와는 달라 1번 배포하면 되돌릴 수 없다. 품질보다 엄격하지 않으면 안 된다.
품질 up을 위해 작업에 몰두하기 쉬워져 버전 간의 차이에 대해서 의식이 미치지 못하고, 고지나 문서 등의 커뮤니케이션을 할 여유가 없다
배포 사이클이 명확하지 않아 각 부서에서 예정을 세울 수 없다
넘치는 issue
23p
아마도 움직일 테니깐 배포하자
24p
Android 엔지니어의 역할 +
안정적인 배포를 하는 어플리케이션 개발 프로세스를 구축, 많은 인원으로의 개발을 지탱한다
품질향상의 구조를 만들고, 지식 축적을 한다
그래도 스피드는 떨어트릴 수는 없다
25p
How?
26p ~ 27p
배포마다 KPT로 회고를 개시
http://techlife.cookpad.com/entry/2014/10/31/093305
Keep:
Problem:
Try:
Problem을 해결하는 구체적인 행동을 정의한다
계속적인 개선
28p
무법지대였던 개발 프로세스를 컨트롤 가능한 규정을 만든다
29p
나아가는 방향성
30p
배포 일정 정의
개발 기간 : 10 영업일
테스트 : 3 영업일
10% 배포 3 영업일
20% 배포 2 영업일
50% 배포 1 영업일
100% 배포 1 영업일
31p
배포 일정 정의
1 배포 20 영업일
10% 배포에서 다음 개발 기간이 시작된다. 배포와 배포 간격은 2주간
빈도가 높지도 낮지도 않은 밸런스
일정에 따라 변경을 생각
32p ~ 34p
개발종료일 문제
개발 기간 10 영업일
Code Freeze(CF)는?
35p
PR 기한 도입
리뷰 기간, 수정을 고려해서 PR 기한일을 개발 종료 3 영업일 전으로 둔다
36p
배포 달력 작성과 공유
37p ~ 38p
git branch 방침을 정의
-> 차이가 있다면 그때마다 merge
기본적으로 항상 master를 바라보고 개발하면 된다
39p
변경의 전체를 issues화 한다
github에 버전마다 마일스톤 작성
부서 Label을 작성
각 버전에 넣고 싶은 변경을 전부 issue화 한다
PR 기한 전 등에 진척을 확인
마일스톤에 넣은 issue에 관한 변경을 전부 테스트
40p
컨트롤 가능한 배포
부서 간에 일정 조정이 기본적으로 불필요하게 된다
직전의 갑자기 들어온 PR 등의 방지, 치안유지
변경 차이는 마일스톤을 보면 안다
안정된 개발이 가능하게 되었다
41p
품질을 올리고, 운용 비용을 내린다
42p
배포 전
배포 후
배포 일정에 따른 차이가 들어가는 타이밍 통제
?
리뷰로 검출
?
마일스톰에 의한 전체 차이의 가시화
?
마일스톤 차이를 중심으로 망라적인 테스트
?
43p
배포 후에 가능한 한 빠르게 찾을 것
특정 케이스에서만 재현되는 Crash
API의 예기치 못한 에러
데이터 미스로 404
이상한 토큰으로 Request하고 401 (Logout)
배포한 기능이나 사라진 기능에 대한 이야기
44p
배포후 감시로 종합적으로 한다
배포한 3시간 후, 아침, 해질녘을 3일간, 각종 체크 결과를 기록한다
45p ~ 46p
예기치 못한 Crash를 빠르게 검출
Google Analytics의 리얼타임 Summary와 Crashlytics의 상황을 본다
새로운 버전의 비율에 대해서 Crash 수가 많지 않은가?
47p
예기치 못한 Crash를 빠르게 검출
API 에러 로그를 Kibana4에 보내 Graph화, 전 버전과 비교해서 에러가 나오지 않는가를 감시한다
https://www.elastic.co/downloads/kibana
48p
유저의 목소리를 듣는다
의견 서식에 보낸 특정 버전의 목소리를 체크
배포 전
배포 후
배포 일정에 따른 차이가 들어가는 타이밍 통제
Crashlytics 체크
리뷰로 검출
Kibana4로 API 에러 체크
마일스톰에 의한 전체 차이의 가시화
의견 체크
마일스톤 차이를 중심으로 망라적인 테스트
49p
배포 전후에 할 것은 많이 있다는 문제
마일스톤에 넣은 issue의 준비
버전 코드의 갱신
issue 진척 확인
Code Freeze와 RC-branch 작성
Diff 리스트업과 테스트
라이센스 체크
갱신 문서
배포 후 감시
KPT 일정 확보
etc…
50p
배포 전후에 할 체크 리스트를 issue화 한다
51p
배포 전후에 할 걸 언제 누가 할 것인가의 문제
아, 누군가 하고 있을 거라고 생각했다
52p
배포 매니저
필요한 항목을 체크리스트 항목화하고 1 배포의 사이에 그것을 전부 담당하는 역할을 만들고, 분배한다.
http://techlife.cookpad.com/entry/2015/02/25/093000
53p
품질을 올리는 구조, 운용 비용을 내리는 구조
배포 전후에 에러 검출을 빠르게 할 수 있게 되었다
배포 전후에 해야 하는 일을 체크리스트 항목화하고 빠트리는 일이 없어졌다
그것들을 배포 매니저가 담당함으로 개발자는 개발에 집중할 수 있게 되었다
54p
2014년 말
배포 사이클의 안정 (13회 배포)
3500 crash / day (75% 감소)
55p
2015년 1월 모바일 First실 해산, 모바일 기반팀 설립
56p
Android 엔지니어의 역할++
사업부 내의 서비스 성장에 책임을 짐 (주로 Android 부분)
사업을 가속하는 개발기반을 강화해간다
57p
많은 부서 체재 시대
58p
많은 사업부, 다수 인원 체재 시대
59p ~ 60p
검색결과 화면
회원 사업부
매물정보 사업부
검색 편성부
투고 추진부
광고 사업부
61p
꽤 크다
Code : 170,000 라인 정도
Class 수 : 1085 정도
Method 수 : 93,000 정도
화면 수 : 70 정도
Code 변경자 : 1 배포에 7-8명
62p
Android 엔지니어의 역할++
사업부 내의 서비스 성장에 책임을 짐 (주로 Android 부분)
사업을 가속하는 개발기반을 강화해간다
많은 사업, 다수 인원이라도 스피드, 품질을 떨어트리지 않는 체재를 만든다
63p
How?
64p
KPT, KPT, KPT
http://techlife.cookpad.com/entry/2014/10/31/093305
65p
가시화와 커뮤니케이션
66p
Android 아침 회의
그 버전에 관한 개발자가 모바일 기반을 중심으로 부서 횡단적으로 모여 이야기한다. 10분 정도.
일정, 상담, 정보 공유 등등
67p
채팅으로 통지를 강화
Github에서의 코멘트, PR, merge 등의 이벤트 통지
개발 일정을 매일 통지
CI Status를 통지
68p
Pull Request 효율화
69p
zatsy Repository
모바일 개발 전반적인 과제나 욕망, 하고 싶은 것, 꿈 등을 마음대로 적는 전용 Repository
모바일 기반팀이 맡는 경우도 있지만, issue를 적은 사람이 하는 경우도 있다
사내 스터디 검토 issue나 회식 예정을 정하는 issue 등도 만들 수 있다.
어수선한 발상을 발휘하는 팀 만들기 : (http://techlife.cookpad.com/entry/2015/03/25/202709)[http://techlife.cookpad.com/entry/2015/03/25/202709])
70p
아침 Lint에 따른 변경으로 허들이 낮아짐
typo이나 함수 구조 개선이나 컴파일러가 내뱉는 경고 수정 등 우선도가 낮은 것이라도 계속해서 수정하는 관습
작은 것을 해결하는 도중 큰 장애물에 닥친 경우는 issue화
부서와 관계없이 활동
지금에 이르러서는 아침 Lint와 이름 지정하지 않아도 하게 되었다
아침 Lint 활동으로 작은 기술적 부채를 해결한다 : http://techlife.cookpad.com/entry/2015/09/15/190000
71p
라이브러리 도입에 의한 효율화, 아키택처 개선
Retrolambda, RxJava, RxT4A, DataBinding Library, Easy Parcelable, kvs-schema, fragment-creator, Android Orma, Permissions Dispatcher, Robolectric
도입 시에는 pros/cons를 논의하고 issue를 세워 스터디를 열거나 한다
근육, QA 단계에 철저히 테스트한다
Android 개발에 RxJava를 팀에 도입한 이야기 : http://techlife.cookpad.com/entry/2015/04/17/100000
72p
같은 배에 타다
관계자끼리 매일 계속적인 대화로 의식이 어긋나지 않는다
채팅에서의 이벤트 가시화로 논의의 활성화
하고 싶은 것과 욕망을 이야기할 수 있는 분위기
정말로 해야 하는 것인가를 진지하게 논의할 수 있는 분위기
부서와 관계없이 개선을 이어나가는 분위기
73p
2015년 말
배포 사이클 유지 (17회 배포)
스피드 유지 (bug fix, 설계개선, 신기능 etc…)
1800 crash / day (더욱 품질 향상)
74p
2015년 Best 어플
75p
Top Developer
76p
2016~
77p
아직 할 것이 많다
78p
User First, 모든 것은 사용자를 위해서
79p
매일 요리를 즐기는 것으로 마음에서 우러나오는 웃음을 늘린다
80p
We’re hiring. Let’s enjoy Android together.
Please enable JavaScript to view the comments powered by Disqus.