챕터8 (#46)

챕터_8/노예찬.md

@@ -0,0 +1,92 @@
+8장에서는 설계에 대한 이야기를 시작하고 있다. 소프트웨어 설계의 정의가 무엇인지 설명하고, 다양한 설계 방법 중 계층형 설계에 대한 설명을 한다.
+
+## 소프트웨어 설계란 무엇인가?
+
+> 코드를 만들고, 테스트하고, 유지보수하기 쉬운 프로그래밍 방법을 선택하기 위해 미적 감각을 사용하는 것
+
+본 책에서는 위와 같이 설명한다. 내가 좋아하는 설계에 대한 정의는 책 '오브젝트'에서 얻은 것인데, 오브젝트라는 책에서는 설계의 정의를 다음과 같이 말한다.
+
+> 코드를 배치하는 행위
+
+동일한 구현이라하더라도 각 사람마다 코드를 배치하는 방법은 다르다. 하나의 기능을 구현하기 위해서, 코드를 어떤 위치에 배치할 것인가를 고민하는 행위를 바로 '설계'라고 한다.
+
+더 나아가 오브젝트 책에서는 '좋은 설계란 무엇인가'에 대해서 정의한다.
+
+> 좋은 설계란 오늘의 요구사항을 만족하면서, 내일의 변경에 유연하게 대처할 수 있는 것이다.
+
+설계가 단순히 코드를 배치하는 행위라면, 좋은 설계란 그 코드의 배치 행위를 통해서 내일의 변경에도 유연하게 대처할 수 있도록 만드는 것에 포커스가 맞추어져있다.
+
+이러한 설명은 본 책에서 설명하는 내용과 크게 어긋나지 않는다고 느껴진다.
+
+책에서는 소프트 웨어 설계의 행위를 3가지로 나누어 설명한다.
+
+1. 코드를 만드는 행위
+2. 테스트하기 쉬운 프로그래밍
+3. 유지보수하기 쉬운 프로그래밍
+
+그리고 이 3가지를 위해서 '미적 감각'을 사용하는 것이라고 말하고 있다. 아마도 '미적 감각'이라는 표현을 사용한 것은 이것이 논리적인 차원에서 논의될 수 있는 부분이기도 하면서도, 많은 연습을 통해서 익혀져야 하는 '감각'이기 때문이지 않을까하고 추측해본다.
+
+이렇게 설계에 대한 나름의 정의를 내린 다음, 더 구체적인 차원에서 이 책에서는 어떤 설계의 방법론을 다룰 것인지에 대한 소개를 한다. 바로 계층형 설계이다.
+
+## 계층형 설계란 무엇인가?
+
+계층형 설계란 무엇일까?
+
+> 계층형 설계는 소프트웨어를 계층으로 구성하는 기술입니다. 각 계층에 있는 함수는 바로 아래 계층에 있는 함수를 이용해 정의합니다. p.169
+
+꽤나 직관적인 이름을 가졌다. 계층형 설계는 이름에 드러나 있듯이 **"계층"** 이 핵심인 것 같다. 함수를 "계층"이라는 단위로 구조화하고, 각각의 계층은 바로 아래 계층에 있는 함수를 이용하도록 만든다.
+
+"계층"이라는 단어는 그 뜻에서부터, **'위계' 혹은 '단계'** 를 내포하고 있다. 그러니까, 소프트웨어에 주어져있는 여러 함수들에 대해서 "위계"를 부여하겠다는 의미를 가진 것이다.
+
+그렇다면, 여기서 궁금해지는 것은 **무엇을 기준으로 "위계"를 더하려는 것일까? 그 '기준'이 무엇인가?** 그 기준을 찾는 방법은 이 계층형 설계를 구현하는 4가지 패턴 중 첫번째 패턴을 통해서 확인할 수 있다.
+
+## 계층형 설계를 위한 4가지 패턴
+
+계층형 설계를 만들어나가기 위해서 4가지 패턴을 활용할 수 있다. 다음은 그 4가지 패턴의 이름이다.
+
+1. 직접 구현
+2. 추상화 벽
+3. 작은 인터페이스
+4. 편리한 계층
+
+8장에서는 이 네가지 패턴 중에서, 첫번째 패턴인 **직접 구현**만 설명하고 있다. 뒤를 살펴보니 9장에서 나머지 2,3,4번의 패턴을 살펴보는데 이렇게 직접 구현 패턴을 한 장을 할애하여 살펴보는 것으로 유추해봤을 때, 가장 핵심이 되는 패턴일 것 같다는 생각이 든다.
+
+이처럼 계층형 설계에서 가장 중요한 것으로 보이기도 하며, 코드에 계층을 부여하는 기준을 알 수 있다고 한 이 **직접 구현패턴** 은 무엇일까?
+
+### 직접 구현 패턴
+
+사실 책에서는 "직접 구현 패턴이란 ~ 이다" 와 같은 형식으로 정의를 내리지 않고 있다. 하지만, 직접 구현의 정의를 유추해 볼 수 있는 문장은 몇 군데에서 찾아볼 수 있다.
+
+> 이처럼 함수가 모두 비슷한 계층에 있다면 직접 구현했다고 할 수 있습니다. p.176
+
+> 직접 구현 패턴을 사용하면 모든 화살표가 같은 길이를 가져야 합니다. (중략) 이렇게 다양한 계층을 넘나드는 것은 같은 구체화 수준이 아니라는 증거입니다. p.187
+
+> 하지만 개선한 함수도 직접 구현 패턴을 적용한 것 같지 않습니다. 여전히 낮은 수준의 배열 인덱스를 참조하는 동작을 그대로 쓰고 있습니다. p195
+
+책에서 다양한 코드를 개선시켜가며 설명하고 있는 것과, 위의 문장들을 통해서 유추해보건데 직접 구현 패턴의 정의는 다음과 같이 내려볼 수 있을 것 같다.
+
+> 직접 구현 패턴은 하나의 함수(A)에서 호출하고 있는 여러 함수들(a,b,c)에 대해서 같은 추상화 수준의 함수를 호출하도록 만드는 것이다.
+
+그러니까, 하나의 함수 A에 직접 구현 패턴을 적용한다는 것은 A라는 함수에서 사용하고 있는 a,b,c라는 함수의 추상화 수준을 평탄하게 맞추는 것이라고 이해할 수 있다. 이 평탄화의 구체적인 내용은 책에서 여러 코드를 통해서 살펴볼 수 있다.
+
+이렇게 직접 구현 패턴의 정의를 정리해보았는데, 위에서 나는 이 직접 구현 패턴을 통해서 함수에 위계를 부여하고 계층을 만드는 기준을 살펴볼 수 있다고 했다. 직접 구현 패턴은 어떻게 계층에 대한 기준을 마련하는데에 도움을 주는 것일까?
+
+## 호출 그래프
+
+직접 구현을 한다는 것은 함수의 추상화 수준을 맞추는 것이다. 추상화 수준을 맞춘다는 표현을 조금 더 구체적으로 설명해보자면, 함수가 어떤 함수를 호출하고 있는지 그 수준을 일정하게 맞춘다는 것이다. A라는 함수에서 만약 a,b,c라는 동작을 수행한다고 해보자. a라는 동작을 수행하기 위해서는 js 언어의 문법을 직접 가져와 구체적인 내용을 표현하고 있다. b라는 동작을 위해서는 이미 구현된 다른 함수를 가져온다. c라는 동작도 마찬가지로 다른 함수를 가져온다. 그러면 a와 b,c는 서로 추상화 수준이 맞지 않는 것이다.
+
+이 추상화 수준을 맞추는 작업을 직관적으로 하기 위하여 호출 그래프라는 것을 그린다. 이 호출 그래프를 그리다보면, 각각의 함수가 호출하고 있는 함수의 그래프의 길이를 확인할 수 있는데, 길이가 일정하지 못한 함수가 눈에 보이면 그 해당 함수의 그래프 길이를 맞춰주어야 한다. 이렇게 함수를 그려나가다보면 자연히 함수들 사이에 계층이 생겨나는 것을 확인할 수 있다. 바로 함수 호출 그래프의 길이가 계층의 기준이 되는 것이다.
+
+사실 호출 그래프는 꼭 그릴 필요가 없다. 함수의 추상화 수준을 맞추는 것이 가장 중요하다. 그것을 쉽게 하기 위한 도구로써 호출 그래프를 사용하는 것이다. 결론은 함수의 추상화 수준을 맞추다보면, 자연히 함수들 사이에 계층이 부여된다는 사실을 확인할 수 있다.
+
+## 그래서 이게 뭐가 좋은거지?
+
+그런데, 궁금한 것은 이렇게 계층을 부여하는 것을 통해서 설계를 하면 무엇이 좋아지는 것일까? 책에서 말한 1)코드를 만들고, 2) 테스트하기 쉽고 3) 유지보수하기 쉬운 프로그래밍을 만든다는 측면에서 어떻게 도움이 되는 것일까?
+
+- 코드를 읽을 때, 같은 구체화 단계에 있기 때문에 읽기가 쉽다.
+- 하나의 구체적인 단계에만 집중해서 사고할 수 있다.
+- 직접 구현을 적용하다보면, 더 일반적인 함수를 많이 만들게 된다.
+  - 일반적인 함수는 구체적인 내용하나만 다루기 때문에 테스트하기가 쉬워진다.
+  - 일반적인 함수는 재사용하기 쉽다.
+
+이게 사실이라면, 꽤 큰 도움이 되는 것이라고 생각한다.