함수형 프로그래밍에 대하여(feat. Swift)

현재 프로젝트서 The Composable Architecture를 사용하고 있습니다

라이브러리를 만든 개발자는 함수형 프로그래밍을 고려하며 만들었다고 해서, 함수형 프로그래밍에 대해서 알아보려합니다

 

워낙에 생소한 개념이다 보니까, 엄청나게 자세한 설명과 예제보다는

함수형 프로그래밍 (Functional Programming)을 이해하는데 필요한 기본 용어와 개념을 중심적으로 정리해봤습니다.

 

사이드 이펙트(Side Effect)란?

어떤 함수를 호출했을 때, 그 함수의 반환값 이외에 호출된 함수 밖에서 프로그램의 상태변화가 발생하면

이를 Side Effect라합니다.

 

저렇게 쓰니까 전혀 와닿지 않네요 

 

"내가 어떻게 컨트롤 할 수 없는 외부의 세계에 접근한다"라는 생각이 들면

Side Effect라고 봐도 될 것 같아요.

 

가장 대표적으로는 File I/O, 네트워킹, 콘솔 로깅, 

 

순수 함수(Pure Function)란?

• 특정 input에 대해서 항상 동일한 output을 반환하는 함수
• 그리고 함수 외부의 값을 사용하지 않아 사이드 이펙트가 없습니다.

이러한 순수 함수가 가지는 장점이 뭘까요?

 

테스팅하기 좋습니다!

output(결과)가 오직 input에만 의존적이기 때문에 테스트 코드를 짜는 게 쉽습니다.

 

공통적으로 접근해야 하는 상태가 없기 때문에 parallel하게 프로그램을 실행할 수 있습니다.

 

...그런데?

우리가 만들고 싶은 앱이 이러한 SideEffect가 없으면 과연 얼마나 의미가 있을까요?

그래서 네트워킹, IO와 같은 것을 어떻게 다루는지가 중요합니다.

 

함수형 프로그래밍(Functional Programming)은 side effect를 하지 말자! 가 아닙니다.

side effect를 어떻게 잘 관리해서 우리의 코드를 테스트하기 좋은 구조로, compose 하기 좋은 구조로 짤 수 있을까?

고민해야 합니다.

 

그래서, "나는 이러한 input이 있고, 이러한 output을 원한다"를 생각하고,

코드를 작은 함수로 쪼갠다음에, 필요한 함수들을 연결하는 것이 목표가 됩니다.

 

 

다시 The Composable Architecture로 돌아오면...

먼저 Github에서 Composable Architecture에 대한 설명을 보면...

Composition
How to break down large features into smaller components that can be extracted to their own, isolated modules and be easily glued back together to form the feature.
Side effects
How to let certain parts of the application talk to the outside world in the most testable and understandable way possible.
Testing
How to not only test a feature built in the architecture, but also write integration tests for features that have been composed of many parts, and write end-to-end tests to understand how side effects influence your application. 

 

확실히 Fucntional Programming에서 추구하는 방향과 겹치네요