Machine_웅_Note

UI 계층 ( 프레젠테이션 계층 ) 1. MVx 의 대원칙 => Model : 단순하게 데이터 영역이 아니라. UI 로직 외에 도메인 계층에 가까운 비지니스 로직을 포함한다고 봐야 한다. => configuration change 에대해서 처리할 수 있는 체계도 필요하다 2.MVC => android robolectric unit test 어느정도 테스트를 할 수는 있지만 한계가 있다. 해결방법 1) 뷰의 분화 ( 복잡도를 낮출 수 있음 ) 2) 뷰 컨트롤러를 만든다 => 프로세스가 종료되는 것도 염두 해야한다. ( 전화가와서 백그라운드로 전환, 메모리부족, 타입아웃에러 등 ) - saveState 처리할 수 있는 로직을 만들어야 함. => 엑티비티는 컨트롤러로 아주 제한적인 일만 해야한다. ( 예를 들..

예시 => isVaild 를 테스트 하게되면 isVaild는 프라이빗이기 때문에,, public으로 바꾸지 않아야 한다. => isVaild 정책의 변경에 따라 저 코드는 문제가 될수 있다. => set , process , assert 하는 구조는 앞으로도 계속 되는 구조임으로 기억하자. => 트렌젝션을 직접 만들어서 처리를 해보는 것이 좋다. => 테스트를 통해서 나올 결과를 가지고 판단을 해야하지, 나온 결과를 또다른 조작을 통해서 판단 검증해서는 안된다. => 위에 예시에서는 createUser로 만든 계정을 아래서 db에 넣음으로써 검증을 하는 또다른 조작을 하고 있다. 완결성 : 테스트는 전부를 가지고 있어야한다, 완성되어있어야 한다. => 그 테스트케이스 안에는 테스트하고자 하는 것을 정확일..

1. 왜 테스트가 중요한가? 2. 안드로이드 테스트 종류 3. 무엇을 테스트 해야할까? ( baby step ) 4. 구글은 어떻게 테스트 하는가 ? 5. 좋은 테스트의 조건 6. 외부 의존성 처리의 원칙 7. 테스팅 안티패턴 1. 아키텍쳐 관점에서 테스트를 어떻게 구현 해야할지 2. 좋은 아키텍처를 구축하기 위해서는 전제조건으로 테스트를 어떻게 구현해야할지 알아본다 3. 테스트의 원칙 1. 왜 테스트가 중요한가? 1) 현실적인 필요성 : QA가 보다 생산적으로 일할 수 있다. 2) 좋은 설계를 촉진 : test case 를 통해서 api 를 변경시 사용성의 차이를 즉시 알 수 있다. => 개방폐쇄 원칙, 단일책임원칙 등 필요없는 의존성 문제를 해결 할 수있음. 3) 코딩 생산성 : 확신을 가지고 작업가..

3. 모바일 클린 아키텍쳐 * 왜 이렇게 하는 가에 대해서 집중해서 보도록 하자 가장 높은 수준의 계층 - 도메인 계층 (유스케이스) : 비지니스 요구를 충족하기 위한 부분 * 엔티티 - 업무 룰의 정의이다 ( 데이터 저장소가 아닌다 ) * 유스케이스 - 기술적인 부분이 아니라 비지니스 로직부분 이다. 도메인 관점의 비지니스로직 : 개발자가아니라, 기획자 등이 알아야 하는 비지니스 로직을 말한다.

1. 복잡성 제거 - 좋은 설계를 위한 첫 걸음 1) 복잡성을 조장하는 요인 세가지 - 의존성 ( 코드가 독립적으로 이해되고, 수정 될 수 없을때. -> 없앨수는 없으나 최소화해야함. ) - 불명확성 ( 중요한 정보가 불명확할 때 - 특정 메소드의 인풋 아웃풋이 불명확 , 과정이 불명확 ) - 전술적 프로그래밍 ( 전략적 프로그래밍 ) ( 빨리 완성하기 - 지금 있는 문제만 고려하고 수정하는 문제 ) 2) 복잡성을 낮추는 방법 추상화 - 정보에 대한 간단한 시나리오나, 시놉시스만 알면되는 것 깊은 모듈 - 모듈이 있다고 가정할 때에 사용자가 알아야 하는 것은 단순하게 사용할수 있는 메서드나 클래스여야 한다 - 하나의 기능을 사용하기 위해 계속해서 모듈의 메서들을 호출하는 것은 얕은 모듈이고 깊이가 얕고 ..

Monad (모나드) => flatMap의 파라미터 이름 형태 (값) ->박스 (값) => 값을 받아서 박스 값을 리턴한다. ( 값 ->박스 ) * flatMap 자체는 async 할 수도 sync 할 수도 있다. ( RxJava는.. 이상하다.) Functor 형태 (값) -> (값) => 값을 받아서 값을 리턴한다. ( 값 ->값 ) => 모나드와의 차이 일반적으로 우리가 사용하는 형태는 Functor 이다. * Functor자체는 async 할 수도 sync 할 수도 있다. (역시 RxJava는.. 이상하다.) CPS의 단점 - 끝없는 들여쓰기. - 이해하기 어려움 CPS의 장점 - 모든 제어 흐름을 만들 수 있다. * 코틀린 컴파일러가 컨티뉴에이션과, 상태머신을 만들어낸다.

https://dalinaum.github.io/coroutines-example/20 채널 버퍼링 채널 버퍼링 예제 91: 버퍼 이전에 만들었던 예제를 확장하여 버퍼를 지정해보자. Channel 생성자는 인자로 버퍼의 사이즈를 지정 받는다. 지정하지 않으면 버퍼를 생성하지 않는다. import kotlinx.coro dalinaum.github.io *버퍼링을 이용하면 - 자유롭게 보내고, 받으면서 중단되지 않으면서 채널을 사용할 수 있다. 버퍼 이전에 만들었던 예제를 확장하여 버퍼를 지정해보자. Channel 생성자는 인자로 버퍼의 사이즈를 지정 받는다. 지정하지 않으면 버퍼를 생성하지 않는다. import kotlinx.coroutines.* import kotlinx.coroutines.chann..

https://dalinaum.github.io/coroutines-example/19 팬 아웃, 팬 인 팬 아웃, 팬 인 예제 87: 팬 아웃 여러 코루틴이 동시에 채널을 구독할 수 있습니다. import kotlinx.coroutines.* import kotlinx.coroutines.channels.* fun CoroutineScope.produceNumbers() = produce { var x = 1 while (true) { sen dalinaum.github.io 팬 아웃 여러 코루틴이 동시에 채널을 구독할 수 있습니다. import kotlinx.coroutines.* import kotlinx.coroutines.channels.* fun CoroutineScope.produceNumb..

https://dalinaum.github.io/coroutines-example/18 채널 파이프라인 채널 파이프라인 예제 84: 파이프라인 파이프 라인은 일반적인 패턴입니다. 하나의 스트림을 프로듀서가 만들고, 다른 코루틴에서 그 스트림을 읽어 새로운 스트림을 만드는 패턴. import kotlinx.cor dalinaum.github.io 파이프라인 파이프 라인은 일반적인 패턴입니다. 하나의 스트림을 프로듀서가 만들고, 다른 코루틴에서 그 스트림을 읽어 새로운 스트림을 만드는 패턴. import kotlinx.coroutines.* import kotlinx.coroutines.channels.* // 리시브 채널 fun CoroutineScope.produceNumbers() = produce {..

https://dalinaum.github.io/coroutines-example/17 채널 기초 채널 기초 예제 80: 채널 채널은 일종의 파이프입니다. 송신측에서 채널에 send로 데이터를 전달하고 수신 측에서 채널을 통해 receive 받습니다. (trySend와 tryReceive도 있습니다. 과거에는 null을 반환 dalinaum.github.io 채널 채널은 일종의 파이프입니다. 송신측에서 채널에 send로 데이터를 전달하고 수신 측에서 채널을 통해 receive 받습니다. (trySend와 tryReceive도 있습니다. 과거에는 null을 반환하는 offer와 poll가 있었습니다.) import kotlinx.coroutines.* import kotlinx.coroutines.chan..