쏙쏙 들어오는 함수형 코딩 (6 ~ 10일차)

6일차

<액션은 다양한 형태로 나타납니다.> 전염되는 액션코드

이전 파트에서 데이터, 계산이 나와서 이번에 액션에 대한 이야기가 나올것이라 예상했었다. 

액션에 대해 어렴풋이 느끼고 있었는데, 자바스크립트 코드를 보여주니 무심코 사용했던 코드들이 액션이었다는 걸 깨닳을 수 있었다. 

 

저자는 액션이 결코 나쁜것은 아니라 강조하는데, 나 같은 경우에도 '뭐가 어떻게 나쁘다던데' 라고 어디서 들으면 이유는 잘 생각하지 않고 무의식적으로 해당 행동을  피하는 습관이 있다.

 

이 책을 읽으면서 무심코 액션은 나쁘다는 선입견을 가지고 있었는데, 생각을 바꾸는 계기가 되지 않았나 싶다. '차악'이 아니라 '또 다른 방법' 이라고 말이다.

 

여튼 저자는 액션 없이 코드를 작성할 수 없다고 이야기 하는데, 계산이 가질 수 있는 장점들을 말하며 액션을 분리해 계산으로 나누는 방법에 대해서 강조하고 있다. 계산은 테스트를 하기 쉽게한다. 또 재사용하기 쉽다는 것이다. 호출 시점에 의존하는 액션은 특성상 동일한 입력이 있을 때 동일한 출력을 보장해야하는 테스트나 재사용성에 나쁘다.

이후 암묵적인 입력과 출력에 대해서 말하는데, 오늘 해당 된 파트에선 자세히 설명하진 않는다.

 

예시로 DOM을 업데이트 하는 일은 암묵적인 출력이라한다. DOM을 업데이트 하는것은 실제로 반환값이 있는것은 아니지만 어떤 정보가 나오는 것이기에 출력이라 볼 수 있지만, 실제 반환값이 없기에 암묵적인 출력이라는 것이다. 이런 암묵적인 입력과 출력이 있다면 해당 코드는 액션이 된다고 설명한다.

 

이를 명시적으로 바꿔준다면 테스트와 재사용성에 좋다는 뉘앙스를 오늘 파트에서 느낄 수 있었는데, 어서 내일 파트를 읽어보고 싶다.

---

7일차

<액션에서 또 다른 계산 빼내기>

액션에서 계산을 빼내는 방법은 다음과 같은 단계로 이루어진다.

1. 계산 코드를 찾아서 빼낸다.
2. 새 함수에 암묵적 입력과 출력을 찾는다.
3. 암묵적 입력은 인자로, 암묵적 출력은 리턴값으로 바꾼다.

여기서 암묵적 입력과 출력은 전역변수를 읽었을 때(암묵적 입력), 전역변수를 바꿨을 때(암묵적 출력) 를 의미한다. 위 과정을 기억하면 액션에서 계산을 추출하는데 많은 도움이 된다.

액션이 왜 테스트에 어려울까 다시 한번 생각하게 됐는데, 이러한 암묵적 입출력을 테스트에 설정하려면 셋업이 엄청 어려워 질 것이라 생각이 든다.

 

전역적으로 참조되는 변수들은 인테그레이션 테스트에서 동일한 결과를 얻어 내기가 힘들 것이다. 특히 비동기적으로 동작하는 로직을 테스트 할 때, 전역 변수에 어떤 로직이 먼저 실행 되느냐에 따라서 결과 값이 달라 질 것이다. 그리고 이런 비동기 동작들은 순서를 보장할 수 도 없는 노릇이다.

함수형 프로그래밍이 주는 장점이 재사용성을 높혀 줄 뿐만 아니라 테스트하기 쉬운 코드를 만들어 주는데서 그치지 않는다고 저자는 말한다. 이것만으로도 함수형 프로그래밍이 좋은것을 느낄 수 있었는데, 동시성 설계, 데이터 모델링까지 좋은 점들을 설명한다니 어서 빨리 뒷부분까지 읽어보고 싶다.

---

8일차

<암묵적 입력과 출력 줄이기.> 느슨한 연결

지난번 파트에서 '액션에서 계산 빼내기' 단계를 설명하면서, 마지막 단계로 있던 '암묵적 입력은 인자로, 암묵적 출력은 리턴값으로 바꾼다.' 이 부분을 자세히 설명한다. 짧게 요약하자면 암묵적 입출력을 명시적으로 바꿔서 모듈화 시키자는 것이다. 이렇게 느슨하게 연결된 모듈들은 재사용하기도, 테스트 하기도 편하다.

이 파트를 보기 전부터 느꼈지만, 내 프로젝트의 코드에서 냄새가 느껴지기 시작했다...

 

대부분의 컴포넌트들이 특정 라이브러리나 데이터에 강하게 연결되어 있어서, 재사용성이 매우 떨어졌다. 이는 코드를 작성하면서도 느끼고 있었다. 다만, 코드에 잠식되서 '지금 코드를 짜고 나중에 리펙토링을 하자..' 하면서 코드들이 서로 강하게 연결되면서 '지금 하면 할게 너무 많은데.. 나중에 할까..?'이 순환이 계속해서 이어져 끊을 수 없는 고리가 만들어졌다.

 

코드에 냄새가 났을 때 맡을 수 있었지만, 확장성에 유의하며 코드를 짜기가 귀찮은 면도 있었고 큰 이유로 '방법'을 잘 몰랐다. 때문에 디자인 패턴 공부 필요성을 느껴, 책을보며 공부하면서도 '음 그렇네...' 하고 머리로만 이해하고 실제로 써보지 않은것이 화근이긴 했다. 때문에 이번 독서를 계기로 실전에 적용해보면서 리팩토링을 실천해보고 싶다.!!

---

9일차

<계산 분류하기>

지금까지 꽤 많은 분리를 해왔다고 생각했지만 저자는 '더' 분리한다... 이러다가 원자 단위까지 분리하는게 아닌가 싶다... 근데 '원자까지 분리하는', 이 또한 디자인 패턴의 일종이라 하더라.. 하하 재밌다.!  

여튼 이번 파트에서 꽤 재밌는 부분이 나왔다. <카피온 라이트 패턴을 빼내기> 단원에서 add_item 함수를 수정하는데, 특정 데이터(장바구니, 상품)에 종속되지 않고, 제네럴하게 접근 가능한 함수를 만든 후 특정 데이터에 종속적인 함수에서 제너럴한 함수를 그저 호출하기만 하는 패턴이 나온다. 

 

이는 변경에도 유리해 보였다. 해쉬와 오브젝트를 인자로 하는 특정 데이터에 종속적인 다른 함수를 만들어야 할 때 제너럴한 녀석을 그저 호출하면 굳이 똑같은 코드를 반복하지 않아도 되기에 좋아보였다.

이번 파트에서 조금 이해가 어려웠던 부분은 함수가 하는 일을 분류 하는 것인데, cart에 대한 동작, item에 대한 동작, 비즈니스 규칙과 같은 계층을 분리하는 일 이었다. cart, item은 이해가 쉽사리 됐는데, 비즈니스 규칙이란게 이해가 되지않아 여러번 읽었던 것 같다. 허나 쉬는 시간 파트에서 해준 설명이 명확하게 이해하는데 큰 도움이 됐다. 장바구니는 쇼핑몰을 만드는데 일반적인 개념이라면, 비즈니스 규칙은 장바구니 내 상품들이 10000원 이상이라면 무료 배송과 같은 회사? 마다 다른 규칙들을 말하는 것이었다.

챕터 5까지 읽었는데, 지금까지 대부분 저자는 '6, 7장에서 자세히 말하겠습니다.' 라고 설명했는데, 6장이 드디어 내일 나온다. 기대가 될 수 밖에 없다.!

---

10일차

<카피-온-라이트> 불변성을 보장하는 카피-온-라이트

카피-온-라이트의 규칙은 다음과 같다.

[카피-온-라이트 규칙]

1. 복사본 만들기. (자바스크립트의 slice 함수를 사용)
2. 복사본 변경하기. - 복사본이라 어떤 변경을 하더라도 원본에 영향을 주지 않는다.
3. 복사본 리턴하기. - 변경한 작업을(쓰기) 원본에 적용시기기 위해서, '원본' = '복사본' 으로 대입시켜주면 된다.

이번 파트에서는 카피 온 라이트에 대해서 설명한다. 불변성의 중요함은 앞선 장에서도 많이 보여왔다. 테스트 용이, 재사용성 증가... 등등 많은 이유에서도 데이터의 불변성은 지켜서 나쁠건 없어 보였다. 저자는 그 불변성을 유지시켜 주는 방법으로 카피 온 라이트를 강조한다.

규칙 2, 복사본 변경하기 단계에서 복사본을 변경하더라도 원본 입장에서 보면 원본은 변경 되지 않았기에 쓰기가 아니라 '읽기'이다! 변경한 내용을 원본에 대입할 때 만이 '쓰기' 작업이 되는 것이다.

참고로 slice나 ES6에 있는 ... spread 연산자는 배열을 얕게 복사한다. 때문에 배열의 주소는 다를테지만 만약 배열안에 다른 오브젝트나 배열이 있다면 그것의 주소는 그대로 사용한다. 즉, 중첩된 배열을 얕게 복사한 배열의 요소를 변경한다면 원본의 요소는 변경될 것이다. 때문에 중첩된 오브젝트의 불변성을 유지하고 싶다면 깊은 복사가 필요할 것이다.