RxSwift를 포함하고 있는 ReactiveX 기술은 스트림 옵저빙을 사용한 비동기 프로그래밍을 위한 API이다.
쓰레드 스케줄링과 옵저버 패턴이라는 매우 근본적인 컴퓨터공학 기술을 기반으로 하기 때문에 다양한 언어나 환경에 포팅됐다.
더욱이 연산자를 공유하기 때문에, 언어나 플랫폼을 넘아들며 다양한 환경에서 쓸 수 있다.
마치 최신 개발언어들이 차용하는 고차 함수(Higher-Order Function)처럼, 로직을 흐름(stream)이라는 프로그래밍 패턴의 형태로 풀어낼 수 있기 때문에, 인간의 선형적인 고찰을 담아내기 좋다.
큰 단점 중 하나는 디버깅이다.
전통적인 프로그래밍은 하나의 라인안에서 함수의 반환값을 할당하고 다음 로직 라인이전에 로그를 찍거나 break point를 걸 수 있었고, 로직의 흐름이 순차적이었기 때문에 디버깅이 비교적 쉬웠다.
반면 메서드 체이닝을 통해 로직을 구성하는 ReactiveX는 디버깅에 숙력도를 요한다.
개발이 편한만큼 디버깅에 불편한 부분인 tradeoff 처럼 만들어진 건 어쩌면 수순일것이다.
양날의 검처럼 느껴지는 부분은 매우 많은 연산자(Operators)들의 특성을 숙지해야 한다는 것이다.
프로그래밍을 작곡에 비유해보자.
기존의 방식은 클래식을 만드는 과정이었다면 ReactiveX이 제시하는 방식은 샘플링을 통한 유행가를 만드는 느낌이든다.
샘플링 할 원곡은 많을 수록 좋다는 것.
그리고 각자의 재능에 따라 원곡수가 적더라도 좋은 노래를 뽑아내는 사람이 있다는 것이 비슷하달까?
역사적으로 선형적인 프로그래밍 방식 또한 패턴화를 통해 템플릿화를 시도한 흔적이 보인다는 건 재밋는 점이다.
실무팁
UIView와 bind와 하는 값이라면 Driver<T>를 사용하는 것이 좋다.
항상 main thead에서 실행되어야 하기 때문이다.
observeOn 혹은 asDriver로 스케줄러를 바꿔줄 수 있지만, stream을 생성하는 쪽에서 스케줄러를 제한두는 것이 문제를 만들지 않고 동시에 코드 간결성도 높다.
다만 Driver<T>는 Behavior 종류가 아니기 때문에 기본값을 가지지 않는다.
이 때문에 UIView의 초기화에 신경을 써야한다.
참조
