일시 : 2019.08.04(일) 13:00~19:00

참여자 : 백진호

세미나 정보 : https://event-us.kr/ted/event/8421

빠른 안드로이드 개발에 대한 프로세스 알아보기

---

강남언니 어떤 방식으로 협업 하는가?

• 전직원 슬랙사용(비개발직군 슬랙 활용가이드 제공)
• 기본적으로 모든 채널은 공개채널
• 업무요청등은 DM을 지양
• 업무 외 시간 슬랙하는 것에 대한 제한없음(멘션포함), 생각을 전달하는것을 미룸으로써 오는 손실 방지..
• 과거 트렐로 사용 (문서내용 많아 지면 관리 어려움) 그 후 confluence 사용
• 노션사용
• 스쿼드별 자리배치(PO, iOS, Android, 디자이너 등)
• 데일리 미팅 (스크럼)
• 스프린트 1주 → 2주변경
• KPT를 통한 회고 (Keep, Problem, Try)

기획부터 릴리즈까지 진행방법

• 6개월 스냅샷 (기획→디자인1차→개발→디자인최종→개발완료 및 QA→릴리즈)
• 기획 - 회의시간(타임타이머 사용, 효율적인 회의를 위해)
• 개발 - 프리핸드 공유(슬랙) → 개발팀 스레드로 대화
• QA - 노션QA 시트 사용
• 점진배포 5% → 10% → 20% → 50% → 100%
• 6주스프린트 이후 rehab 기술블로그를 통하여 발표

다양한 요구사항에 빠르게 대응하는 방법

• MVP 아키텍쳐 사용중 프레젠트 선개발
• 로직이 변하지 않을 것 같은 부분은 선개발
• 전역변수 사용 지양
• 함수형프로그래밍 사용중(RxJava)

느낀점

• 개발자 채용에 대한 회고가 필요할듯 개선방안논의
• rehab을 통해 스프린트를 돌아보고 개선하는 시간이 필요함(단순 팀 회고가 아닌 개발팀내 개발부채 해결 위해노력)

카카오페이 안드로이드 개발자로 일하기

---

• 23명의 클라이언트 개발자, 12개의 파트, 2개의 앱을 서비스중
• 국내최대의 페이시장장악, J커브 그리는중

2개앱 운영

• Java/kotlin의 공존
• legacy code
• 페이앱 개발
• 우리만의 모듈 필요

카카오페이

• Kotlin, mvvm, Clean Architecture, module

사용하는 주요 기술

• Retrofit, Koin, Coroutines, Epoxy(데이터바인딩)

모듈을 이용

• 공통 모듈을 위한 메인 → 모듈1, 모듈2 → 내부 모듈 배포 → Talk pay, Pay app (계속적으로 검토, 개선방안 찾는중)
• 공통의 Prefix를 따름
• 각각앱에서 가지는 디펜던시는 적용하지 않음
• Clean Architecture 기반의 적용
• 내부서버에서 동작확인

일하는 방법

• 기획회의, 개발팀 배정, 개발팀내에서 구조 작업 이야기, 개발진행
• 톡, 페이 각각 나눠서진행(안드로이드), 톡 페이 같이 진행 (iOS)

시간과 장소에 구애받지 않고, 언제나 이야기한다

• 논의가 필요하면 언제나 이야기할 준비가 되어있다
• 실험적인 기술은 언제나 도전한다.
• 안정화되었다고 생각하면 공유한다
• 새로운 도전은 언제나 환영 팀과 공유하고 진행해 본다

페이앱은 어떻게 만들어졌나

• 디자인 팀과 수많은 협업
• 기존 레거시 코드의 재작성
• 협의한 MVVM Architecture 사용

인턴 교육 과정

• 작업을 위한 언어를 익하고, 매주 리뷰 진행
• 아키텍쳐를 익힐 수 있도록 과제 진행
• 현업과 페어 프로그래밍 등을 통해 학습력 증대 / 실무에 적용
• 리뷰를 진행

아지트로 크루들과 연결

• 아지트를 통해 자료 공유
• 간단한 공유문서
• 카카오 내부의 다른 개발자들과 소통
• 내용의 방대함

GitHub

• 코드 관리
• 이슈를 통해 작업 관리
• PR을 통한 코드리뷰 진행(1명이상 코드리뷰해야함)
• 작업상 필요한 내용은 GitHub README 작성

연결을 위한 다양한 공간

• Confluence wiki, Jira, Zepline, Keynote

성장

• 회사의 성장, 개인의 성장, 우리팀의 성장, 더많은 논의

코드작성 문화

• 일부 하긴 하지만 전체적인 코드 리뷰 문화가 필요하다
• 코드리펙토링
• 아키텍쳐적용
• 아름다운 코루틴 사용

내부 문화 몇가지

• 완전한 수평 조직
• 비 정기적인 강의(재테크, 문화 등)/회식(회식비 제한없음)/플레이샵/워크샵
• 매달 진행하는 타운홀
• 이번달은 특별히 Kotlin in action 저자 분의 직강 예정

느낀점

• 회식비 제한없음 부럽다..
• 교육과정이 잘되어 있어 보임
• 자기 스스로 개발에 흥미가 있고 새로운것을 얘기하고 논의하는데 재미있어함

VCNC는 어떻게 타다를 만드는가

---

라이프사이클 기능(모든 맴버의 참여를 유도함)

• 아이디어→문서작성→Committe평가(모든팀의 각대표 서버,운영 사업개발, PM, 디자인 등)→백로그→시간협의→개발

아이디어 단계

• 더나은 아이디어를 생각 아이디어 제한서를 작성
• 어떤 문제점을 해결하기 위한 아이디어인가
• 실제 적용 되었을때 예상되는 효과
• 1명이상의 스폰서(Committe 참석자)
• 거절 되었다면 제안자가 스폰서에서 결과에 대한 피드백 공유

Cell은 가상조직

• 아이디어를 릴리즈하기위한 팀

릴리즈 후

• 성공 여부의 지표를 체크함
• 성공, 실패 상관없이 회고회의 진행

아이디어 피쳐의 관리

• Kanban 사용
• 매일오전 데일리 칸반 스탠드업 미팅
• 현재 진행 과정의 공유

개발팀이 일하는 방식

• 모든 클라이언트 개발자는 iOS, Android 같이 개발(가능한 빨리 오픈해야 하는 첫 사업 모델때문에 : VCNC의 첫 오프라인 사업)
• VIPER, Reflex, MVP with Rx
• iOS, Android가 각각 아키텍쳐부터 모든 고민이 2배로 들어가서 공통 적인 부분은 묶는다
• Daily scrum 각 Cell에서 내용 공유 및 진행사항 공유, 어려움을 겪고 있거나 도움을 줄 수 있는 경우
• 계속적인 리뷰 및 리펙터 : 언제나 이이제기 하며 해결하기 위한 방안 제시포함

문서화

• 노션사용

PR

• Build, Test, Lint, Change-log
• 자동으로 1명이 선택되서 그사람이 반드시 리뷰를 해야 함(Auto-assign App)
• Pull Panda: Pull Reminder
• Diff Monster 작업변경 확인
• Git flow 사용
• Squash 머지 사용 (이쁘게 정리하기 위함)

CI/CD

• 젠킨스에서 변경 Teamcity (Zeplin에서 만든것)
• Project hierarchy
• Build queue
• Configuration as code
• fabric 베타

타다클라이언트 개발스택

• 모두 Kotlin으로 작성되어 있음
• 최대한 최신 버전의 코틀린을 사용 하려고함

RIBs 아키텍쳐 패턴사용(Cross Flatform, Uber RiBs)

• No MVC, no MVVM, no MVP
• Single Activity Application(Map-based application)
• Router, Interactor, Builder로 구성

ReactiveX

• 모든 것을 비동기적으로 생각하고 대응한다
• 비트윈떄무터 RX를 사용하여 거부감은 없었음

Protocol Buffers

• 서버와의 효율적 커뮤니케이션을 위해 사용
• API 문서작성 X
• .proto → moshi JSON class
• gRPC

느낀점

• 할일이 정해져서 내려옴 서비스를 위한 아이디어 회의 필요
• 커밋 정리 잘하자.. ㅠㅠ rebase 사용…!
• Protocol Buffer 효율적인듯

서로를 성장시키는 질문

---

비개발자에게 이해 할 수 있게 설명해 보자

• 왜 MVP, MVVM을 하고있나? (아키텍쳐)
• 왜 64 비트 작업을 해야하나? (64비트)
• 이렇게 작업하는거 불편하지 않나요? (작업방식)
• 이게 왜 필요하다고 느끼세요? (필요성)

Architecture

• 이유 유연한 개발
• 특정 패턴 형태의 작업을위해서

64비트

• 필수 불가결 작업
• 또 다른 해결 방안을 모색 (App Bundle, APK Split)

작업방식

• 작업방식은 2가지로 극명하게 나뉨
• 누군가는 결정해야함 (왜 필요한지, 설명하고, 누군가는 납득하고 많은 커뮤니케이션 소모)
• 사람/업무가 바뀌면 다양하게 바뀜
• 복수 인원이 원활하게 진행하기 위한 프로세스
• 명확한 답은 없음
• 다양한 의견을 나열하고 선택 뿐

필요성

• 각자가 필요하다고 느끼는 크기는 다름
• 실제 필요한지? 그냥 하고 싶은지? 설명이 부족하지 않은지?

업무 프로세스

• 플랜→이슈→개발→리뷰→리펙토링
  • 플랜 : 이번 버전/분기에 해야할 업무들 확정
    • 질문
      • 왜 이업무를 하는가
      • 이다음 플랜은 어떻게 보고 있나
      • 납득시켜주세요
  • 이슈 : 스프린트에 맞는 이슈, 우리가 하고싶은 이슈
    • 질문
      • 우선순위 설정, 이슈의 상세한 스펙?
      • 지금해야할 백로그 이슈?
      • 더 이상 미룰 수 없는 빚더미 이슈?
  • 개발 : 필요에 따라 개발에 대한 토의
    • 질문
      • 고민되는것 없나요?
      • 진척은 괜찮나요?
      • 같이 코드 볼까요?
      • 커피 마실래요?
  • 리뷰 : 각 이슈 의미에 맞게 개발 상태 체크, 문제점 처리가능한 데드라인 단계
    • 질문
      • 이정도 과하게 작업되어야 하는가요?
      • 우리가 편하려고 이렇게 하는건 아닌것 같다
      • 왜 여기에 많은 동작이 하는지?, 궁금증 100배

이사람이 질문을 해올때

• 본질을 묻는가?
• 단순한 취향인가?
• 의도가 무엇인가?
• 순수한 궁금증인가?

질문을 한다는 것?

• 선택과 집중
• 안전성 확보
• 스피드
• 타인의 이해
• 자신감
• 왠지 모를 만족감

질문을 받는것 대답을 하는것 틀리는건 괜찮음

• 대답을 하지않아 암묵적 동의는 좋지 않음

질문이란

• 질문은 새로운 시작 과정이다
• 질문은 새로운 정리 과정이다
• 질문은 새로운 이해 과정이다
• 질문은 새로운 본일 과정이다

헤이딜러에서는어떻게 일하나요?222

---

• 기획 후 슬랙채널을 생성하여 커뮤니티함
• jira와 연동
• 칸반형식으로 관리
• Sketch - Zeplin 활용한 UI관리
• Snippets - daily, weekly 운영 채널( 개발팀, OS별 팀 )
• Truck count.. zzzzz
• metting : snippet에 기반한 daily, weekly 미팅
• style guide 관리

Git

• Gif Flow 사용
• Git branch/commit 은 항상 jira 이슈번호로 시작(해당 코드의 변경 이유나 히스토리 트래킹에 유용)

PR

• PR : github template 활용하여 기본 작성 템플릿에 기초하여 작성
• PR 상태에 맞는 Label을 추가하여 관리
• 1명이상 리뷰, SonarQube 리뷰

CI/CD

• 젠킨스 사용중, 슬랙연동
• SonarQube가 해당 PR내용을 리뷰하여 각 코드에 commit 및 리뷰 결과 리포트

QA

• Google SpreadSheet 사용

A/B 테스트

• 1사람의 의견으로 결과물이 나오게하지 않기위해

Submodule

• Git의 서브모듈을 이용하여 공통관리

아름답게 앱 오류 처리하기

• messager has stopped 팝업 → 새로고침할 수 있는 화면(운영, 개발에서 분리해서 화면에 로그 찍히게 구현)

느낀점

• PR : github template 활용 해보자
• SonarQube 써보자
• A/B 테스트의 필요성(기본적인 목적 + 능동적으로 일하기 위해)
• 오류가 났을때 디버깅이 아닌 화면에서 볼수 있도록(개발버전에서만)
• pull panda(pull reminder) 사용해보기 PR에 대한 analytics 정보 제공

단단한 글로벌 안드로이드 서비스 만들기

---

• Confluence(Knowledge Base)
• Jira(task)
• Slack(Communication)
• Sketch, Zeplin(디자인)
• Abstract, GitHub(형상관리)
• CI(젠킨스)

GitHubLabel

• 많은 PR이 생긴다면 Label을 구성해 놓는게 효율적

Glober

• 앱이름
  • 포르투칼에서는 azar가 불행하다라는 뜻이라 azzar로 배포함
• NumberFormat
  • 가격 numberFormat이 국가마다 다름 (1,200, 1.200, 1 200)

점진적배포

• 5%→100%

Todo

• 디자인시스템 적용
• 다크모드 적용
• R8 마이그레이션
• 안드로이드 Q 대응
• RTL 대응
• 크로스플랫폼 모듈
• 더 빠른 릴리즈 사이클

1등 돈관리 앱은 어떻게 만드나요?

---

조직

• 기능조직(안드로이드팀)
• 목적조직(가계부팀) : 메인
• 안드로이드팀 (월: 계획회의, 화수목: 스탠드업 미팅, 금: 회고미팅)
  • 트라이브 이슈
  • 기술의견
  • 배포
  • 코드리뷰(PR)의 부탁
  • 기술이슈 - 설계 / CI

배포

• 1주일 단위 배포
• 타임라인
  • 기획(JIRA, confluence)
  • 디자인(zeplin)
  • 피쳐개발
  • 코드리뷰
  • 피쳐QA(Fabric Beta)
  • 배포범위 확정
  • 배포피쳐 머지
  • 배포범위 QA (빌드테스트) 일반적인 Git Flow
  • 베타배포(지정테스터들이 알바배포된 버전확인 1주일 안정성확보)
  • 점진적배포(30%→60%→100%)
  • 슬랙 공유
• 코드리뷰
  • 버그
  • 리펙토링
    • 가독성
    • 컨벤션(indentation, method name)
  • 설계
  • 질문
• 2명이상 Approve 해야 머지/배포 가능

기술이슈

• MVVM + Clean Archutecture
• 테스트(KOIN)
• 미래멀티모듈
• MVP (Passive View)
• MVVM 1개 피쳐에 실험적으로 도입 (타 팀원 가독성 문제) 보류
• 테스트 커버리지
  • Codecov Report(PR을 올렸을떄 코드커버리지나옴)
• 보안 하위메뉴 적용중
  • 난독화 ( 빌드 매우느림, SDK 낮은 기기 대응 힘듬(MIN SDK 23 롤리팝 미지원))
  • 무결성
  • 앱 잠금
  • 보안키보드
  • 암호화

실무

• Kotiln, MVP, RX
• 배울 수 있다(핀테크 도메인 지식)
  • 금융사 연동
  • 결제
  • 보안
  • 전자금융업 법규

인재상

• 스스로 문제를 찾는 사람
• 피드백이 활발한 사람

정리

• 정리해서 공유할 내용은 많은데.. 콘샐러드 참여바람