<div id="readability-page-1" class="page"><div id="content">
		<main id="main" role="main">

		
			<article id="post-1735">
			
		<div>
			




<h2 id="3장-막간-결합과-추상화">3장. 막간: 결합과 추상화</h2>



<p>이 장에선 도메인 모델링이라는 핵심 주제에서 벗어나서 ‘추상화’에 대해 집중한다.</p>



<p>대규모 시스템에서는 시스템의 다른 부분에서 이루어진 결정에 의해 의사결정이 제한될 수 있다. 그래서 만약 A 컴포넌트가 B 컴포넌트를 변경할 수 없는 경우, 서로 ‘결합’되었다고 한다.</p>



<p>작은 범위에서 결합된 코드들이 서로 잘 맞물려서 돌아가는 거는 ‘응집’되었다고 표현하고 이는 바람직하다.</p>



<p>하지만 넓은 범위에서 결합이 생기면 코드를 변경하는 비용이 크고, 아예 변경이 불가능할 수도 있다. 그래서 추상화를 통해 세부 사항을 감추면 시스템 내 결합 정도를 줄일 수 있다. B를 변경하면서 A도 변경하는 것 대신 사이에 놓인 추상화가 B에 의존하는 부분만 수정하면 A는 변경하지 않아도 되기 때문이다.</p>



<figure><img src="https://i0.wp.com/www.cosmicpython.com/book/images/apwp_0302.png" alt="apwp 0302"></figure>



<h3 id="추상화로-테스트를-쉽게-만들기">추상화로 테스트를 쉽게 만들기</h3>



<p>책에선 두 파일 디렉터리를 동기화하는 코드를 작성하면서 이를 설명한다.</p>



<p>제시된 요구사항에 맞춰서 한 함수로 구현하면, 파일을 읽고, 같은 파일인지 확인한 후, 동기화를 수행하는 코드를 작성한다. 이러면 함수 내에 도메인 로직과 IO 코드가 결합되어 있다. 단순히 함수를 테스트하고 싶어도 테스트 코드에도 임시 파일을 생성하는 IO 로직이 들어가야 되며, 실제 IO가 발생하지 않고 실행 과정만 출력 시키고 싶다거나, 클라우드 같은 원격 서버와의 동기화로 변경하려고 한다면, 결합된 도메인 로직도 변경해야 한다.<br>(실패할 수 있는 구간에서 실행 과정을 확인하는 테스트를 dry run이라고 부른다. 소방서에서 실제로 물을 뿌리지 않고 화재 훈련하는 거에서 가져왔다.)</p>



<p>테스트 하기 쉽게 코드를 다시 작성하려면 어떻게 해야 할까?</p>



<p>먼저 코드에서 뚜렷한 책임을 구분한다. 여기선 다음과 같이 구분한다.</p>



<ol><li>동기화 할 두 디렉토리의 파일들을 읽고, 동기화 방식을 선택하기 위한 데이터를 만듦.</li><li>파일마다 어떤 동기화 방식을 적용할지 선택함. (책에선 new, renamed, duplicated가 있었음.)</li><li>실제로 동기화를 수행함. 파일을 복사하거나 이름을 똑같이 맞춰주거나 제거함.</li></ol>



<p>그 다음, 이 책임들을 각각 추상화를 통해 단순하게 만든다. 어떻게 파일을 읽을지 동기화 시킬 지는 감추고, 비즈니스 로직은 동기화하는 과정에만 초점을 맞출 수 있게 한다. 그러기 위해선 각각의 책임에서 “무엇을 하길 원하고, 어떻게 달성할지”를 구분한다. ‘무엇’이 추상화되어야 하고, ‘어떻게’는 세부 사항으로써 감춰져야 한다. 예로 들어 2번의 경우, 파일마다 각각 동기화 방식을 선택하길 원하고, 어떻게 동기화 방식을 결정할 지는 감춰지게 된다.</p>



<h3 id="선택한-추상화-구현하기">선택한 추상화 구현하기</h3>



<p>이 과정의 목표는 실제 파일 시스템 없이도 테스트를 할 수 있게 하는 것이다. 그러기 위해서 외부에 아무런 의존성이 없는 코드의 ‘핵’을 만들고 외부에서 이 핵에 어떻게 반응하는지 살펴볼 수 있게 해야 한다.<br>(게리 번하트는 Functional Core, Imperative Shell 라고 이 접근 방법을 설명했다.)</p>



<p>그래서 핵을 먼저 분리한다. 코드에서 IO 없이 데이터만 주어지면 로직으로 처리 가능한 부분을 찾아서 분리한다. 예를 들어 위에 2번은 이렇게 분리 가능한 핵에 해당되고, 하나의 함수로 분리하면 실제 파일 시스템 없이 2번에 대해서만 테스트가 가능해진다.</p>



<h3 id="의존성-주입으로-해결하기">의존성 주입으로 해결하기</h3>



<p>가짜 IO에 대해서도 테스트 할 수 있도록, 1번과 3번을 구현할 때, IO 대상을 외부에서 받아오도록 수정할 수 있다. 1번 과정의 코드가 실제 파일 시스템이 아닌 함수의 매개변수를 통해 외부에서 파일 시스템 객체를 받아서 파일을 읽게 하는 것이다. 외부의 파일 시스템은 파일을 읽고 쓰는 기능이 인터페이스로 열려 있어야 한다.</p>



<p>이렇게 하면 IO가 테스트를 위해 바뀌더라도 우리가 지금까지 구현한 동기화 코드가 수정되지 않는다. 단, 이제부터 매번 명시적으로 파일 시스템을 주입 시켜줘야 된다. 이를 “테스트가 야기한 설계 손상”이라고 부르기도 한다.</p>



<h3 id="mock-patch는-사용하지-않는-이유">mock.patch는 사용하지 않는 이유</h3>



<p>Python에선 mock.patch를 쓰면 코드를 수정하지 않고 단위 테스트를 수행할 수 있다. 하지만 책의 저자들은 이 방법이 코드 냄새를 유발한다고 생각하고, 위의 과정처럼 코드의 책임을 명확하게 구분하고, 테스트 더블로 대체하기 쉽게 책임들을 작은 크기로 만드는 게 도움이 된다고 생각한다.<br>(테스트 더블은 테스트 시 복잡한 실제 시스템을 고려하지 않도록 만들어주는 객체들이다. stub이나 dummy  같은 것들을 말한다.)</p>



<p>여기선 정확히는 세 가지 이유를 들었다.</p>



<ol><li>단위 테스트는 가능하지만 원격 서버나 dry run 기능 추가는 할 수 없다.</li><li>mock.patch로 수정한다는 거 자체가 테스트 코드가 세부 사항과의 결합이 강해진다.</li><li>mock을 과용하면 테스트 스위트의 가독성이 떨어진다. 뭘 위한 테스트인지 알기 어렵다.</li></ol>



<p>3번의 경우는 저자들은 TDD가 테스트 이전에 설계를 위한 기법이라고 생각하기 때문에 테스트에서 설계를 알아볼 수 없으면 문제가 있다고 본다.</p>



<h3 id="마무리-올바른-추상화를-찾기-위한-자기-검증">마무리: 올바른 추상화를 찾기 위한 자기 검증</h3>



<p>휴리스틱한 방법이지만 책에 적혀 있는 것. 이건 연습을 통해 나아진다고 한다.</p>



<ul><li>지저분한 시스템의 상태를 표현할 수 있는 익숙한 파이썬 객체가 있는가? 그렇다면 이 파이썬 객체를 사용해 시스템 상태를 반환하는 단일 함수를 상상해봐라.</li><li>시스템의 구성 요소 중 어떤 부분에 선을 그을 수 있는가? 이 선을 통해 구분되는 각각의 추상화 사이의 이음매를 어떻게 만들 것인가?</li><li>시스템의 여러 부분을 서로 다른 책임을 지니는 구성 요소로 나누는 합리적인 방법은 무엇일까? 명시적으로 표현해야 하는 암시적 개념은 무엇인가?</li><li>어떤 의존 관계가 존재하는가? 핵심 비즈니스 로직은 무엇인가?</li></ul>
			
			
								</div>
</article>

			
	
			

		
		</main>
	</div></div>

Wraithkim의 지식공방

3장. 막간: 결합과 추상화 이 장에선 도메인 모델링이라는 핵심 주제에서 벗어나서 ‘추상화’에 대해 집중한다. 대규모 시스템에서는 시스템의 다른 부분에서 이루어진 결정에 의해 의사결정이 제한될 수 있다. 그래서 만약 A 컴포넌트가 B 컴포넌트를 변경할 수 없는 경우, 서로 ‘결합’되었다고 한다. 작은 범위에서 결합된 코드들이 서로 잘 맞물려서 돌아가는 거는 ‘응집’되었다고 표현하고 이는 바람직하다. 하지만 넓은 범위에서 […]

Architecture Patterns with Python – 4

댓글