Android Kotlin을 통한 개발 전략 신동길 NAVER / 네이버앱개발

2. 네이버 앱개발 l 신동길

3. 제목: Android Kotlin을 통한 개발 전략
1. 기존 코드 어떻게 전환하고 확장할 것인가?
2. 넌 어느 별에서 왔니?(코틀린 주요기술의 근원)
- 람다와 함수형
- 프로퍼티와 함수
- 연산자 재정의
- Method Extension
- Pipe Filter Model
3. 자바에서 코틀린으로 변환과정
- 멤버 변수의 초기화
- @Nullable 처리
- 중첩 클래스 쪼개기
- Optional(?.) 최적화
4. 코드 효율화를 위한 툴킷 정의와 활용
- 전역변수와 프로퍼티
- 연산자 재정의
- 고차함수 활용
5. 거버넌스의 필요성
6. 맺음말 : 어떤 프로그램이 될 것인가?

4. 1. Kotlin 어떻게 전환할 것인가?(1/3)
기존 코드를 어떻게 전환할 것인가?
 바뀌는 부분만이라도 변환해 가자?
 새로 짜는 부분만?
BUT
헤어날 수 없는 자바
 자바 스타일의 코틀린 코드
 기존 자바 코드에서 호출이나 참조가 쉽지 많은 않다
언어는 습관이다.
컴퓨터 언어도 습관이다.
=> 잘 안 바뀐다

5. 1. Kotlin 어떻게 전환할 것인가?(2/3)

6. 1. Kotlin 어떻게 전환할 것인가?(3/3)

7. 2. 코틀린 넌 어느 별에서 왔니?

8. 2.1 코틀린의 유용한 기술들?
오퍼레이터
오버로딩(C++)
람다 (Java 8, Javascript)
Property (Object Pascal)
Method Extension(C#)
DataStream Model
(Direct X, java8)
다른 언어의 DNA를
가지고 진화!

9. 2.2 함수형과 람다(1/2)
함수형
 함수의 파라메터와 리턴형으로 함수를 표현한 자료형
 모든 함수는 함수형으로 형으로 표현 가능하다
 함수, 람다, 익명함수, 함수 참조 등을 변수로 선언 & 전달할 때 사용

10. 2.2함수형과 람다식(2/2)
람다 식(Lamda Expression)
 함수를 불필요한 부분 생략하고 기호화하여 간결한 한 것
 Expression이므로 함수와 달리 코드 중간에서 값을 리턴하지는 못함

11. 2.3 연산자 재정의
필요성
 연산자가 함수보다 간결하여 쉽게 인식 됨
 함수의 호출보다 쉬운 코딩
 반복적인 코딩에 대한 효율성
 이미 존재하는 객체에 추가 정의 가능(*)

12. 2.4 프로퍼티
프로퍼티란?
 변수에 대한 처리와 변수 값을 묶어 놓은 것
 단일 파라메터/리턴에 대한 처리를 간결화여 함수를 대치하는 목적
 프로퍼티는 철저하게 컴포넌트(객체)의 사용자를 위한 개념

13. 3. 자바에서 코틀린으로 변환

14. 3.0 자바코드의 변환 예제
DessertCellView

15. 3.1 멤버 변수의 초기화 방법(1)
init{}
 초기값을 지정하지 않고, 이 함수에서 지정 가능
 객체의 초기화 시에 값을 지정할 수 있음
lateinit
 초기 값을 지정하지 않고 생략 후 나중에 대입
 변수 접근시 초기화 여부를 확인하지 않음
by lazy (delegator)
 사용 시점 초기화 됨
 코드 블록으로 초기화 하므로 다른 처리 가능
Optional(?)
 Null로 초기화 하고 나중에 값을 지정

16. 3.1 멤버 변수의 초기화(1/5)

17. 3.1 멤버 변수의 초기화(5/2) – Optional(?)

18. 3.1멤버 변수의 초기화(3/5) – lateinit var

19. 3.1 멤버 변수의 초기화(4/5) – by lazy

20. 3.1 멤버 변수의 초기화(5/5) - init

21. 3.2@Nullable 처리(1/2)

22. 3.2@Nullable 처리(2/2)
convertView:View?
as DessertCellView?

23. 3.3 클래스의 중첩 최적화
Inner(nested) class 최소화
 한 파일에 여래 개의 객체 선언 가능
 중첩된 클래스는 복잡해 보임
 객체 내에 또 객체를 선언하는 중첩을 사용할 이유가 없음
 해당 파일에서만 사용하는 객체 앞에 private 으로 선언하여 사용 가능

24. 3.4 Optional(?.) 최적화
? 선언
 꼭 필요한지 고려 해야 하라
 init, late init, lazy 로 피할 수 있으면 피해라
 !!는 확실히 검증된 경우만 사용하라
let, apply외 표준확장 함수
- 동일 변수에 2개 이상의 ?. 을 사용할 때
- 과용하면 오히려 코드 읽기가 어려워짐
Elvis(?:)
조건문 내에 쓰는 거? 좀 생각해 보자

25. 4. 코드 효율화를 위한 툴킷 정의와 활용

26. 4.1 간결하게 하기 위한 요소들
패키지 레벨 전역 변수 함수
클래스와 관계 없이 변수나 상수를 정의할 수 있다.
서비스 코드 레벨에서 공유 되는 변수는 전역으로 사용해도 좋다
고차함수 정의(DSL스타일)
함수의 파라메터로 람다를 사용하는 고차함수 람다 식을 함수 호출 다음에 정의
함수의 조건 만족하면 코드블럭을 수행하는 방식
연산자
연산자를 통해 함수 호출 코드를 간결화 할 수 있다.
기존의 객체에 연산자를 추가 정의할 수 있다.

27. 4.2 패키지 Levels 선언 – Beyond Class Scope
Global Context
Application Context, Handler, ThreadPool, Resource etc
System Util Functions
Screen info, dp2px
isNetworkStatus, Package Info
Systems Managers
ConnectionManager, ActivityManager, WinowManager
WifiManager, etc

28. 4.2 패키지 Levels 선언 – 전역 변수(프로퍼티)
3가지 초기화(선언) 방식
- 단순변수
- 지연 초기화 된 변수
- Property

29. 4.3 연산자 정의 - StringBuilder (plusAssign )

30. 4.3 연산자 정의 – View(plusAssign )

31. 4.3 연산자 - Intent(get/set )

32. 4.3 연산자 정의 – Uri(get )

33. 4.4 Global 함수의 정의와 고차 함수
고차 함수(DSL 스타일)
- 함수의 람다 파라메터는 함수 다음에 코드 블록으로 정의할 수 있는 속성을
이용하게 특정한 조건을 만족하는 코드 블록을 정의할 수 있게 한다.
- DSL 함수와 동일한 이름의 프로퍼티나 함수 정의
Global 함수의 정의
- 안드로이드에서 제공하는 기능 중 반복적으로 사용되는 함수를 정의
- 서비스 코드 내에서 빈번하게 사용하는 코드의 정의
- 이 함수의 정의 목적은 짧은 코드임

34. 4.4 DSL 함수 PRACTICE - Orientation

35. 4.4 DSL 함수 PRACTICE – Api Levels

36. 4.4 DSL 함수 PRACTICE –Catch all Exceptions

37. 5. 팀 개발 공동 개발을 위한 거버넌스
필요성
- 너무 다양한 스타일이 존재한다.
- 개발자의 언어 이해 능력이 차이가 나므로 스타일을 어느 정도 정할 필요가 있다.
- “어떤 스타일은 사용하지 말라”의 가이드가 아니라 어떤 패턴의 코드에는 “어떤
스타일을 우선하여 사용하라”고 정의
- 시스템 클래스에 대한 함수확장이나 전역 변수의 대한 가이드 라인도 어느
정도는 필요