RxJs 퀵스타트 서론
책을 쓰면서 RxJS는 왜 만들어졌고, 또 어떤 철학 배경으로 RxJS가 탄생했는지를 찾아가다 보니 결국 RxJS를 어떻게 써야 하는 지 자세히 알게 되었다. 또한 RxJS를 왜 써야 하는 지도 더욱 분명해졌다.
개발을 처음 시작할 때는 요구사항을 어떻게 구현할지 구현 자체에만 초점을 맞추게 된다. 하지만 경험이 쌓이기 시작하면 구현보다는 얼마나 효과적으로 유지보수할 수 있을 지 또는 얼마나 많은 문제점을 설계나 테스트 코드를 통해 사전에 해결할 수 있을 지 고민하게 된다. 그래서 우리는 자연스레 기존 문제들을 해결하기 위해 고심했던 라이브러리, 디자인 패턴들을 하나둘씩 적용하게 되고, 결국에는 이런 고민들이 녹아들어 간 프레임워크에 관심을 갖게 된다.
프레임워크를 잘 사용하는 것도 중요하지만 그 기술의 결과물이 어떤 고민의 산물인지 아는 것이 더 중요하다. 고민의 원인을 알게 되면 그 기술을 보다 깊게 이해할 수 있고 폭넓게 활용할 수 있다.
상태 머신이란 주어진 시간의 상태가 존재하고, 어떤 한 사건에 의해 다른 상태로 변할 수 있는 수학적 모델을 의미한다.
사용자의 입력에 따라 프로그램이 예상하는 결과를 얻지 못하는 것을 우리는 프로그램 오류라고 이야기한다. 웹 애플리케이션을 하나의 상태 머신으로 본다면 정확한 입력과 로직으로 상태를 관리하는 방법이 중요하다.
각 구성요소에게 정확한 입력값을 전달하는 문제는 단순히 값을 전달하는 것이기 때문에 쉽게 생각할 수 있지만 쉬운 문제만은 아니다. 서버에서 전달받은 응답 결과값이 정상적으로 왔을 경우에만 입력값을 전달해야 한다. 비정상적인 응답 데이터를 입력값으로 전달하면 오류가 발생할 수 있다.
상태 오류가 발생하는 이유는 상태 변화를 정확하게 전달하지 못하는 경우이다. 구성요소 간 의존도가 있는 경우, 구성요소 간 호출 순서에 의존도가 있는 경우 프로그램은 오류에 직면할 수 있다.
가장 간단하면서도 빈번하게 발생하는 오류는 분기문, 변수에 따른 오류이다.
분기문이 많으면 많을수록 프로그램 흐름이 복잡해진다. 더군다나 중첩 분기문이 오류에 직면할 확률을 높인다.
또한 변수를 많이 사용하면 할수록 로직 오류는 빈번히 발생할 수 있다. 변수는 우리가 의도치 않게 변경할 수 있으며 또한 누군가에 의해 변경될 수 있기 때문에 많은 변수의 사용은 프로그램의 복잡도와 오류 발생률을 높인다.