[클린코드] 8장 경계 with Typescript

라이브러리, 패키지, 오픈 소스 등의 외부 코드를 우리 코드에 통합시키는 방법과

이런 소프트웨어 경계를 깔끔하게 처리하는 방법에 대해 알아본다.

소프트웨어 경계란, 인터페이스 제공자와 사용자 사이의 입장 차이로 발생하는 경계

 

• 인터페이스 제공자는 최대한 적용성을 넓히는 방향으로 설계한다.
• 인터페이스 사용자는 자신의 요구에 집중하는 인터페이스를 원한다.

---

외부 코드 사용하기

예를 들어 Map 객체는 굉장히 다양한 인터페이스로 수많은 기능을 제공하는데, 이런 유연성은 유용하지만 그만큼 위험이 크다.

• 객체 유형을 제한하지 않는다. 어떤 타입의 객체도 추가할 수 있다.
• 사용자에게 필요하지 않은 기능까지 제공한다.
  • 누구나 내장된 clear() 함수를 호출하여 내용을 지워버릴 가능성이 있다.

 

제너릭 사용하기

const sensors = new Map<string, Sensor>();

• 객체 유형을 지정할 수 있다.

 

경계 인터페이스를 캡슐화하기

class Sensors {
    private sensors = new Map<string, Sensor>();

    getById(id: string) {
        return sensors.get(id)
    }
}

• 필요한 인터페이스만 제공할 수 있다.
• 설계 규칙과 비즈니스 규칙을 따르도록 강제할 수 있다.

경계 인터페이스를 이용할 때는 이를 이용하는 클래스나 클래스 계열 밖으로 노출되지 않도록 주의한다.

경계 인터페이스의 인스턴스를 공개 API의 인수로 넘기거나 반환값으로 사용하지 않는다.

 

경계 살피고 익히기

외부 코드를 사용하기 전에 학습 테스트를 통해 외부 코드를 익힌다.

학습 테스트: 간단한 테스트 케이스를 작성하여 프로그램에서 사용하려는 방식대로 외부 API를 호출하는 것

• 통제된 환경에서 API를 제대로 이해하는지 확인할 수 있다.
• API를 사용하려는 목적에 초점을 맞추어 테스트할 수 있다.

 

학습 테스트는 공짜 이상이다.

학습 테스트에서 사용하는 테스트 케이스는 실제 코드와 동일한 방식으로 인터페이스를 사용하는 코드이다.

따라서 학습 테스트는,

• 패키지가 예상대로 작동하는지 검증한다.
• 패키지가 새로운 버전을 릴리즈했을 때 기존 코드와 호환되지 않으면 학습 테스트가 이를 바로 알아낼 수 있다.
  • 새 버전으로 이전하기 쉬워진다.

 

아직 존재하지 않는 코드를 사용하기

아는 코드와 모르는 코드 사이의 경계가 존재한다.

아직 정의되지 않은 경계 너머의 api를 인터페이스로 분리하고 캡슐화하여, API가 바뀔 때 수정할 코드를 한 곳으로 모아놓는다.

• 우리에게 필요한 인터페이스를 미리 구현해 놓는다. → api가 정의된 후 그 간극을 Adapter 클래스로 메꾼다.
  • 전적으로 인터페이스를 통제할 수 있다는 장점이 생김
• 적절한 Fake 클래스를 사용하면 테스트가 가능하다.
  • api가 정의된 후 경계 테스트 케이스를 생성해서 올바르게 사용하는지 테스트할 수 있다.

 

깨끗한 경계

• 경계에 위치하는 코드는 깔끔히 분리한다.
• 기대치를 정의하는 테스트 케이스를 작성한다.
• 통제가 불가능한 외부 패키지에 의존하는 대신 통제가 가능한 우리 코드에 의존하는 편이 훨씬 좋다.
• 외부 패키지를 호출하는 코드를 가능한 줄여 경계를 관리하자.
  • 새로운 클래스로 경계를 감싸기
  • ADAPTER 패턴을 사용해 우리가 원하는 인터페이스를 패키지가 제공하는 인터페이스로 변환

이런 방식으로 경계를 처리하면 코드 가독성과 일관성이 좋아져 외부 패키지가 변할 때 변경할 코드가 줄어든다.

---

마무리

학습 테스트란 기법을 처음 알게 되었다.

비단 외부 라이브러리를 사용할 때뿐 아니라, 다른 개발자가 만든 컴포넌트를 사용할 때도 이 기법을 활용하면 쉽게 사용법을 익히고 예상한 대로 동작하는지 확인할 수 있을 것 같다.

 

프론트엔드 개발을 하다 보면 백엔드에서 API 명세를 전달해 주기 전에 미리 작업을 시작하는 경우가 많은데 항상 고민이 되는 부분이다.

책에서 나온 ADAPTER 패턴을 적용하면 api 명세가 변경될 때 한 곳에 모아둔 코드만 변경하면 되기 때문에 빠르게 대응할 수 있다는 장점이 있다.

하지만 백엔드에서 보내주는 데이터와 프론트에서 UI에 뿌려주는 데이터와의 간극이 심해질 수 있다는 단점이 있다.

또 Adapter라는 계층이 하나 추가되는 것이기 때문에 코드가 복잡해질 염려가 있다.

프론트엔드에 적용하기에는 조금 까다로운 내용이었지만 경계를 구분하고 어떻게 매끄럽게 처리할 수 있을지 고민해 볼 수 있었다.