[책 정리] 6장. 함수형 프로그래밍 - Clean Architecture

정수를 제곱하기

 

-

함수형 언어에서 변수는 변경되지 않는다.

 

 

 

불변성과 아키텍처

 

-

경합 조건(race condition), 교착 상태(dealock) 조건, 동시 업데이트(concurrent update) 문제가 모두 가변 변수로 인해 발생한다.

우리가 동시성 앱에서 마주치는 모든 문제, 즉 다수의 스레드와 프로세스를 사용하는 앱에서 마주치는 모든 문제는 가변 변수가 없다면 절대로 생기지 않는다.

 

 

-

아키텍트라면 동시성(concurrency)문제에 지대한 관심을 가져야만 한다.

우리는 스레드와 프로세스가 여러 개인 상황에서도 설계한 시스템이 여전히 강건하기를 바란다.

 

 

 

가변성의 분리

 

-

불변성과 관련하여 가장 주요한 타협 중 하나는 앱 또는 앱 내부의 서비스를 가변 컴포넌트와 불변 컴포넌트로 분리하는 일이다.

상태 변경은 컴포넌트를 갖가지 동시성 문제에 노출하는 꼴이므로 흔히 트랜잭션 메모리(transactional memory)와 같은 실천법을 사용하여 동시 업데이트와 경합 조건 문제로부터 가변 변수를 보호한다.

트랜잭션 메모리는 db 가 디스크 레코드를 다루는 방식과 동일한 방식으로 메모리 변수를 처리한다.

즉, 트랜잭션을 사용하거나 또는 재시도 기법을 통해 이들 변수를 보호한다.

 

 

-

앱을 제대로 구조화하려면 변수를 변경하는 컴포넌트와 변경하지 않는 컴포넌트를 분리해야 한다는 것이다.

그리고 이렇게 분리하려면 가변 변수들을 보호하는 적절한 수단을 동원해 뒷받침해야 한다.

현명한 아키텍트라면 가능한 한 많은 처리를 불변 컴포넌트로 옮겨야 하고, 가변 컴포넌트에서는 가능한 한 많은 코드를 빼내야 한다.

 

 

 

이벤트 소싱

 

-

더 많은 메모리를 확보할수록, 기계가 더 빨라질수록, 필요한 가변 상태는 더 적어진다.

이벤트 소싱(event sourcing)에 깔려 있는 기본 발상은, 상태가 아닌 트랜잭션을 저장하자는 전략이다.

상태가 필요해지면 단순히 상태의 시작점부터 모든 트랜잭션을 처리한다.

물론 지름길을 택할 수도 있다. 예를 들어 매일 자정에 상태를 계산한 후 저장한다. 그 후 상태 정보가 필요해지면 자정 이후의 트랜잭션만을 처리하면 된다.

 

저장 공간과 처리 능력이 충분하면 앱이 완전한 불변성을 갖도록 만들 수 있고, 따라서 완전한 함수형으로 만들 수 있다.

소스 코드 버전 관리 시스템이 정확히 이 방식으로 동작한다.

 

 

 

결론

 

-

구조적 프로그래밍은 제어흐름의 직접적인 전환에 부과되는 규율이다.

객체 지향 프로그래밍은 제어흐름의 간접적인 전환에 부과되는 규율이다.

함수형 프로그래밍은 변수 할당에 부과되는 규율이다.

 

 

-

소프트웨어, 즉 컴퓨터 프로그램은 순차(sequence), 분기(selection), 반복(iteration), 참조(indirection)로 구성된다.

그 이상도 그 이하도 아니다.