업무를 하게 된다면 패키지를 구매하거나 오픈소스를 이용하여 개발하곤 합니다. 회사가 크다면 사내 다른 팀이 제공하는 컴포넌트를 사용하지요. 외부 코드를 자신의 조직 코드에 잘 통합해야 합니다. 그 경계를 잘 구별하는 방안에 대해 살펴봅시다.
인터페이스를 제공하는 측은 적용성을 최대한으로 구성합니다. 쓰는 사람은 자신에게 맞는 기능이 있길 바라지요. 그렇기 때문에, 원치 않은 기능을 사용할 수도 있게 됩니다.
따라서 외부 인터페이스 조차도 언제든 변할 수도 있음을 인지하고, 이를 클래스안에 숨겨서 필요한 기능만 노출시키면 제어권을 “나”에게 옮길 수 있습니다.
외부 라이브러리를 가져오면 빠르게 기능개발을 할 수 있지요. 만약 이 패키지를 사용하고 싶으면 어디서 어떻게 시작하는게 좋을까요?
타 라이브러리를 가져왔지만 쓰기 힘든 경우를 생각해봅시다. 배우고, 제대로 쓰고 있는지도 파악해야하고, 내 버그인지 라이브러리의 버그인지 쫓아갈 때도 있습니다.
이러한 기능에 대해 빠르게 익히는 방안을 책에선 ‘학습 테스트’1 라는 용어로 소개합니다. 마찬가지로 TDD로 작업합니다.
학습 테스트와 맞바꾸어야 하는 cost는 없습니다. 쓰려면 API를 배워야 하니까요. 오히려 필요한 지식만 확보하는 방법입니다. 이해도를 확실히 올려줍니다.
경계의 또다른 유형은 아는 코드와 모르는 코드를 분리하는 경계입니다. 이는 필요 이상으로 다른 코드를 알 수없는 경우, 아직 구현되지 않은 코드에 대해 생각할 필요가 있는 경우를 의미합니다.
아직 구현되지 않은 부분에 대한 공통적으로 필요한 경계를 생각하고, 그 내용을 추상화하여 이를 통해 대화하면 구현하는 쪽이 인터페이스를 통제하게 됩니다.
ADAPTER 패턴을 통해 구현할 수도 있고, Mock 객체를 적절히 이용하여 테스트할 수도 있습니다.
통제할 수 없는 코드를 사용할 때는 변경에 많은 비용이 들지 않도록 합시다.
이를 위한 방법은 경계에 위치한 코드를 말끔히 분리하는 것입니다. 외부 코드에 휘둘리지 않도록 외부 라이브러리를 직접 호출하지 않고, 간접적으로 작성해봅시다.