[개발자의 서재] "클린코드" 8. 경계

경계가 무슨 뜻인가요?

소프트웨어를 개발하다 보면 필연적으로 외부 라이브러리 혹은 다른 팀이 개발한 모듈 혹은 서비스를 이용해야 합니다. 심지어 아직 개발되지도 않은 모듈과의 연동을 고려하면서 프로젝트를 진행해야 할 때도 있습니다. 이때, 외부 코드와의 의존성을 적절히 관리하지 못하면 소프트웨어의 불안정성이 극도로 높아지게 됩니다.

클린코드에서는 외부 코드와의 의존성을 관리할 수 있는 부분을 "경계"라고 정의합니다. 경계가 만들어지는 이유를 크게  1) 외부 코드의 사용, 2) 아직 개발되지 않은 모듈과의 연동으로 구분합니다. 다행인 것은 이를 다루는 방법이 하나로 통합되어 복잡하게 신경 쓸 것이 없다는 것입니다 ㅎㅎ

경계에서 의존성을 관리하는 방법이 뭐죠?

통제할 수 없는 것에 시간을 허비하지 말고, 통제할 수 있는 것에 집중하라

자기계발 분야에서 아주 유명한 격언입니다. 하지만 개발의 세계에서도 통용되는 문장입니다. 우리가 통제할 수 없는 외부 라이브러리에 의존하지 말고, 통제할 수 있는 무언가를 준비하라는 뜻으로 해석할 수 있습니다.

 

어답터 패턴을 아신다면 이해가 빠를 것 같습니다. 어답터 클래스를 이용해서 소프트웨어와 외부 코드를 분리하는 것입니다. 이렇게 하면 외부 라이브러리가 변경되더라도 소프트웨어는 변경하지 않고 어답터 클래스만 변경하면 됩니다.

 

또한, 외부 라이브러리의 경우 일반성을 고려하여 매우 많은 메소드가 제공됩니다. 개발자들에게 혼란을 주어 같은 기능에 대해 여러 구현을 만들도록 유도시킬 수 있습니다. 이는 결국 중복을 만드는 것이지요. 어답터 클래스를 이용하여 소프트웨어에 필요한 인터페이스만 제공하는 것은 개발자에게 가이드라인을 제공하는 효과도 있습니다.

• 여기서는 어답터 클래스를 구체적인 예시로 들었지만 이런 방식처럼 외부 API 서버 사이에서 인터페이스를 맞춰주는 API 서버를 하나 더 실행하거나, 타입을 변환해주는 함수 등 다양한 해결책이 존재할 수 있습니다.

 

어답터 패턴을 아직 잘 모르겠다면?

• [디자인 패턴] 어답터(Adapter) 패턴이란

 

외부 라이브러리를 사용할 때 알아두면 좋은 팁이 있을까요?

학습 테스트

잘못된 개발 방법을 하나 보여드리겠습니다.

1. 외부 라이브러리를 활용해서 기능을 전부 구현합니다.
2. 테스트 케이스를 작성합니다.
3. 테스트 케이스가 실패하면 코드의 어느 부분이 잘못되었는지 찾아봅니다.

• TDD의 관점에서 보면 1, 2도 잘못된 순서지만 여기서는 3에서 겪는 어려움에 집중해보겠습니다.

 

위의 순서를 거치고 나면 우리가 작성한 코드는 외부 라이브러리와 비즈니스 로직이 혼재되어 어느 부분에서 에러가 발생한 지 추적하기 매우 어려워집니다. 외부 라이브러리를 잘못 사용한 것인지, 비즈니스 로직을 잘못 구현한 것인지 혹은 둘 다 잘못된 것인지 알기 어려운 것이죠.

 

이 문제를 해결하기 위해 "학습 테스트"의 도입을 권장합니다. 학습 테스트란 외부 라이브러리의 사용법을 공부하기 위한 테스트를 뜻합니다. 외부 라이브러리를 사용하기 위해 공부한 지식을 여러분의 머리 속에만 두는 것이 아니라 코드로 실체화시키고 직접 실행해보는 것이죠.

 

또한 개발자가 학습 테스트를 작성하면서 라이브러리에 대해 더욱 깊은 이해를 할 수 있다는 장점도 있습니다.

 

같이 보면 좋은 글

• [개발자의 서재] "실용주의 프로그래머" 7.중복의 해악
• [개발자의 서재] "실용주의 프로그래머" 8.직교성