킹의 개발일지
쏙쏙 들어오는 함수형 코딩 (16 ~ 20일차) 본문
16일차
<계층형 설계 패턴> 직접 구현
계층형 설계 패턴에서 1단계인 직접구현을 살펴본다.
freeTieClip 메서드를 예로 드는데, 처음 봤을 때 이 코드는 정말이 내가 짤 만도 한 코드였다. 제대로된 설계 없이 기능을 추가한 코드인데, 함수가 알아야 할 필요 없는 구체적인 내용을 담고 있다.
직접 구현을 하는 방법으로 다이어 그램을 그려서 계층을 나누는데, 처음 읽을 때 골머릴 앓았다.

연습문제로 주는 문제에서 계층을 주었어야 했는데, 비즈니스 룰이 들어가지 않기에 높은 계층들은 제거했고, for문과 같이 언어에서 제공하는 저층 함수를 '사용'하고 있는 함수였기에 '사이에 새로운 계층', '가장 낮은 계층' 두 가지에서 엄청 고민했다. 물론 저자가 설명하는 것을 잘 읽으니 이해가 가긴 했다만 다이어 그램으로 계층을 분리하는 것은 많은 연습이 뒤 따라야 할 것 같은 느낌이다.
그래도 이번 파트에서 비즈니스 규칙, 장바구니 기본동작 '층'에 조금이나마 익숙 해 질 수 있었다.
17일차
<계층간 화살표 길이를 줄이자.>
이번장을 읽고 나니, 뭔가 새삼 함수형 코딩이란 것에 입문 했구나 느꼈다.
직접 구현 패턴에 맞추려면 서로 다른 계층의 동작을 사용하면 안되는데, 예를 들어 remove_item_by_name 메서드를 보면 처음 설계에는 removeItems() : 카피-온-라이트 동작 계층과 for loop, array idx의 저층, 자바스크립 언어 기능으로 총 두 계층에 걸쳐 있기에 직접 구현 패턴에 맞지 않았다.

이를 해결하 방법으로 중간에 함수를 두어서 긴 화살표를 줄이는 것인데, 이걸 보고 맨처음 감상을 느꼈던 것이다.
for문 계층을 카피-온-라이트 동작 계층으로 올리기 위해서, indexOfItem이라는 메서드를 만들었는데, 함수 내용은 그저 for문 동작을 한다.
fuction indexOfItem (cart, name) {
for (var i = 0; i < cart.lenth; i++) {
if (cart[i].name === name) return i;
}
return null;
}
이렇게 중간단계의 함수를 만들어주고 아래와 같이 함수를 리팩토링한다.
function remove_item_by_name (cart, name) {
var index = indexOfItem(cart, name);
if (index !== null) return removeItem(cart, idx, 1);
return cart;
}
한 단계 래핑한 함수인데, 아직은 이게 굳이 필요한 건가 싶은 느낌이 든다. 왠지 함수 호출 스택만 더 늘어나는게 아닌가 싶은 느낌이 들 정도이다.
아직은 이렇게 래핑함으로써 이론적으로 remove_item_ by_name 함수를 for loop, array index에 그어져있는(자바스크립트 언어기능) 화살표를 indexOfItem 이라는 함수로(카피-온-라이트 동작, removeItems과 같은 레벨) 그어지게 해 화살표를 줄인다. 이것게 주는 장점은 아마 다음에 볼 수 있지 않을까 하는 생각이 든다.
이번장은 그저 직접 구현 규칙을 준수하기 위해 저층 함수를 고층으로 올리기 위해 몇가지 연습을 했다. 다음장부터 재사용하고 유지보수하기 쉽고 테스트 하기 좋은 패턴을 알려준다니 더 읽어봐야 겠다.
18일차
<계층형 설계 2>
저번장 리뷰
패턴1: 직접 구현
시그니처가 나타내는 문제를 함수로 적절하게 구체화 한다.
패턴2: 추상화 벽
인터페이스를 사용해서 코드를 제작
패턴3: 작은 인터페이스
최소한의 인터페이스를 유지하면서 정의
패턴4: 편리한 계층
코드와 코드가 속한 추상화 계층은 작업시 편리해야한다.
- 추상화 벽
: 팀 간 책임을 명확하게 나눌 수 있다. 학부시절 인터페이스 이야기를 하면서, 꼭 들었던 이야기가 바로 블랙 박스 이야기다. 블랙 박스 내부는 어떻게 돌아가는진 모르지만 우리는 블랙박스를 사용하면 특정 결과를 도출해 낼 수 있다는 것을 안다. 때문에 추상화 벽 너머에 있는 다른 부서는 함수가 어떻게 돌아가는지 알 필요없이 그냥 사용하기만 하면 그만이다.
이번 장으로 앞에서 이상한게 래핑 함수들을 많이 만드는것에 이해가 됐다.
래핑 함수는 함수간에 연결을 느슨하게 해서, 함수가 추상화 벽 넘어에 있는것은 모르게 함으로써 교체가 용이해 질 것이라는 생각이 들었다. 벽 넘어에 있는 함수는 얘가 배열인지, 객체인지 전혀 알 필요가 없다. 때문에 교체를 해야할 부분도 특정 함수로 줄어들 것이다. 일종의 프록시와도 같은 느낌이 들었다.
학부시절 느슨한 연결에 대해서 중요하다고 배웠지, 그땐 지금보다 지식이 없었고, 실제 쓰이는 코드를 보지 않았기에 그러려니하고 넘어갔다. 이번 챕터에서 다시 한번 그 용이함을 느낄 수 있었다. 배운것들을 코드에 적용할 수 있는 날이 어서 왔으면 좋겠다.
19일차
<추상화벽, 작은 인터페이스, 편리한 계층 패턴>
이번장에서 추상화 벽부터 작은 인터페이스, 편리한 계층 패턴을 살펴본다. 직접 설계를 몇 페이지에 거쳐 설명한 것과는 달리 추상화벽, 작은 인터페이스, 편리한 계층은 이번 차수때 '후욱~!' 하고 설명한다. 이해하려고 읽고 또 읽은 듯 했다.
작은 인터페이스 패턴은 새로운 기능을 만들 때 하위 계층에 기능을 추가하거나 고치는 것보다 상위 계층에 만드는 것이다. 즉, 저 레벨 방법들(배열, 반복문...)을 통해서 새로운 함수를 만드는 것 보단 이미 있는(추상화 벽에 있는) 메서드를 이용해서 함수를 만들어야 한다.
이는 생각해봤을 때 복잡한 함수는 추상화 벽에 있는 함수들이 엄청 많지 않고서야 지켜지기 꽤 힘들듯 하다.
편리한 계층은 저자가 앞서 설명한 부분들에 인간미(?)를 살짝 뿌린 느낌이다.
"비즈니스 문제를 해결하기 위해 일하는 개발자로서 거대한 추상 계층을 만들 시간적 여유가 없다." 즉, 기계처럼 패턴을 적용하지않고 언제 패턴을 적용하고 또 언제 멈춰야 하는지 실용적인 방법을 알려준다고 한다.
코드가 냄새가 난다? 이때 패턴을 적용해야 할 때라고 알려준다.
읽는다고 읽었지만 이해가 부족하다. 대략적인 감은 잡았지만, 그래도 다시한번 리뷰가 필요할 듯 하다.
20일차
<그래프가 코드에 대해 알려주는것>
*요악
1. 유지 보수성: 위로 연결된 것이 적은 함수가 바꾸기 쉽다.
왜냐하면 아래에 있는 함수일 수 록, 위에 있는 함수보다 더 많이 얽혀있기 때문이다. 때문에 자주 바뀌는 코드는 가능한 위쪽에 있어야 좋다.'
2. 테스트 가능성: 위쪽으로 많이 연결된 함수를 테스트하는 것이 더 가치 있다.
1에서 말한것 처럼, 밑에 있을수록 다른 함수들과 얽혀있다. 때문에 아래쪽에 있는 함수를 테스트하면 위쪽에 있는 함수들은 밑에 있는 함수를 믿고 사용할 수 있다.
3. 재사용성: 아래쪽에 함수가 적을수록 더 재사용하기 좋다.
낮은 수준의 단계로 함수를 빼내면 재사용성이 더 높아진다.
지금까지 액션, 계산, 데이터, 계층형 설계등을 익혀왔다. 하지만 여전히 계층형 설계 부분은 완벽히 이해한것 같진 않다. 느낌으로만 머릿속에 존재하는데, 지금껏 배운 방법들로 직접 해보는 단계가 꼭 필요해 보인다.
'독서 > 책너두 챌린지' 카테고리의 다른 글
| 쏙쏙 들어오는 함수형 코딩 28일차 (0) | 2023.09.08 |
|---|---|
| 쏙쏙 들어오는 함수형 코딩 (26 ~ 27일차) (0) | 2023.09.07 |
| 쏙쏙 들어오는 함수형 코딩 (11 ~ 15일차) (0) | 2023.09.07 |
| 쏙쏙 들어오는 함수형 코딩 (6 ~ 10일차) (0) | 2023.09.07 |
| 쏙쏙 들어오는 함수형 코딩 (1 ~ 5일차) (3) | 2023.09.07 |