Naver Tech Concert 후기

1. Android Studio 설정 다시 한번 볼까요?

Android Studio 3.6 버전까지 오면서 놓치고 있던 Studio 설정들을 공유합니다. 라이브로 설정을 조작하면서 정보를 진행하는 시간을 가집니다.

 

단축키, quick lists, keymap, notification(gradle..), file color, file format,..

 

 

2. 예제에서는 알려주지 않는 Model 이야기

아키텍처, 패턴에서 모델은 빠지지 않고 등장합니다. 쉬워 보이지만 또 어렵기도 한 모델에 관하여 예제에는 잘 보이지 않는 내용들을 공유하려 합니다.

 

- model 역할 분리

model : 1. 데이터베이스, API를 통해 데이터를 불러오고 저장하는 역할.

           2. 서비스의 비즈니스 로직(도메인)을 담당.

 

- model의 역할(책임)에 따른 분리 과정

 

#1. Repository Pattern을 사용하라

 

Repo: https://github.com/omjoonkim/GitHubBrowserApp 

 

Review > 

Repository Pattern을 적용해보는 게 어때요?

 

Repository?

- 디자인 패턴 중의 하나

- 데이터 불러오는 로직을 분리시켜 관리하는 것이 목적

- 하나의 Repository는 하나의 Domain을 담당한다.

- 추상화를 통해 테스트에 용이해진다.

 

Source?

- 데이터를 불러올 수 있는 모든 외부

- Server(Http, socket), Local(db, cache)

- 현재 예제에서는 Http만 사용하기 때문에 나누지 않음.

 

#2. Business Logic을 분리하라

 

지금까지의 줄거리

model 사라지고 data와 source 대체!

 

기능 추가 = Business Logic 추가

= '유저의 행동에 따라 서비스에서 보여주고자 하는 결과를 나타내기 위해 데이터를 가공하는 로직'을 추가

 

Review >

Business Logic을 분리해보시겠어요?

 

Business Logic을 Presentation Logic에서 분리해야 하는 이유?

- 복잡한 화면일수록 Presentation의 코드가 커지게 된다.

- 그럴수록 복잡성이 증대. 유지보수성 저하됨.

- Presentation의 역할을 분리해줄 필요성이 생김.

- Presentation에서 Business Logic을 분리. Presentation에 집중하게 한다.

- 물론 작은 서비스, 화면, Platform에 따라 분리하지 않아도 괜찮긴 함.

 

how 분리?

Service?

Service Layer Pattern(n-tier, 3-layer에서 파생).

Busicess Logic의 집합소 개념. 재사용이 용이하다.

MSA, 작은 서비스에서 쓰일 때 유용함.

혹은 설계가 짜임새 있게 되어 있어야 한다.

완벽하게 Presentation에서 Logic을 분리하기 어렵기 때문.

또한 유지보수가 어려울 수 있기 때문.

Service - Repository

             Service

             Service   -  Repository

............ 유지보수 어려워. 서로 이중성을 갖고 있기 때문에.

서비스도 여러 개의 repository를 갖고 있기 때문에 단순히 데이터를 불러오는 것에서 끝나는 게 아니라..

장점도 있긴 함. 중복된 코드를 제거할 수 있음.

 

UseCase?

하나의 유저 행동에 대한 서비스(Application)의 Business Logic에 담겨있는 객체.

서로(UseCase)에게 독립적.

..

UseCase - 여러 개의 Repository

유지 보수하기 좀 더 저렴하다. 용이하다

 

UseCase를 잘못 사용하는 경우

- UseCase를 Repository처럼 사용하는 경우.

- UseCase를 Service처럼 사용하는 경우.

 

(강조) 보통의 경우에는 유저의 행동(Business Logic)과 1:1로 매칭 된다. (강조)

 

그래서 김신입은 유지보수 저렴+용이 -> UseCase 선택

 

Presentation에서 Business Logic을 분리.

시스템이 복잡해져도 유연하게 대처할 수 있게 되었다.

 

#3. Exception handling

 

지금까지 줄거리

View - Presenter

- Domain - Data - Source

Model을 Domain, Data, source로 나눔

 

Api call -> HttpNetworkException -> 403 Forbidden Rate Limit -> Toast

 

Review >

Business Logic이 분리되지 않았어요.

 

presenter의 Exception Handling이 Business Logic인 이유.

- HttpException, 403 code 체킹은 Presentation로직이 아니다.

- Presenter에선 Http, 403등에 대한 개념을 모르기 때문.

- 또한 유저의 행동에 따라 발생하는 예외 상황이기 때문에 Business Logic으로 볼 수 있다.

- 그러나 관점에 따라서는 다르게 처리하는 방법도 있을 수 있다.

 

Api call -> HttpNetworkException -> 403 Forbidden Rate Limit -> Toast

                           -> Convert to using in domain

 

Exception Handling도 Busines Logic으로 볼 수 있다.

 

처음엔 MVP.

그러나 Model은 세 가지로 나눌 수 있다.

Domain - Data - Source

 

Clean Architecture

 

 

3. 안드로이드 개발자 로드맵

네이버 안드로이드 개발자 3년 차가 되는 과정에서 졸업생은 무엇을 준비하고, 어떤 걸 공부해야 하는지 키워드와 노하우를 공유합니다.

 

 

 

4. 쪼개지고 나누어지는 안드로이드

다양성은 안드로이드 생태계의 핵심 가치입니다. 안드로이드 디바이스 종류는 정말 다양하며, 5G 등 새로운 모바일 기술은 오픈된 안드로이드 생태계를 기반으로 빠르게 발전할 수 있었습니다. 하지만, 안드로이드 다양성은 앱 개발자에게는 영원한 숙제로 남겨졌습니다. 구글은 안드로이드 생태계의 다양성을 유지하면서도 앱 개발자의 수고를 줄이고 사용자가 최적의 경험을 할 수 있도록 많은 노력을 기울이고 있습니다. 다양성과 호환성이라는 두 마리 토끼를 모두 잡기 위해 구글이 힘쓰고 있는 안드로이드 플랫폼 모듈화 및 앱 모듈화 프로젝트를 소개하고 앱 개발 시 염두에 둘 내용을 살펴봅니다.

 

 

 

 

잘 들었습니다.

탈주.