[클린코드] 8. 경계 - 요약 및 인사이트

인사이트 정리

외부 라이브러리에도 버그가 있다는 것, 외부 라이브러리에 의존한다면
인터페이스가 바꼈거나 버전이 바꼈을 때 우리 코드와 호환되리라는 보장이 없다는 것에 매우 공감하면서 읽은 챕터였다.
이와 관련해 한 가지 경험이 떠올랐는데,
회사 프로젝트를 개발할 때 사용하던 momentjs가 업데이트가 중단되면서 dayjs로 교체하는 과정이였다.
dayjs를 모듈화 하지 않고 반환값으로 사용했기 때문에 교체하는데 많은 시간이 걸렸다. 이런 불편함으로 따로 util 함수를 만들어 라이브러리를 노출되지 않도록 했는데 이런 경험으로 외부 라이브러리에 너무 의존하면 안된다는 것을 깨달았다.

학습 케이스라는 개념도 배웠으니 앞으로 외부 라이브러리를 쓸 때 적용해봐야겠다는 생각을 할 수 있게 되었다.

요약

시스템에 들어가는 모든 소프트웨어를 직접 개발하는 경우는 드물다.
이 외부코드를 우리 코드에 깔끔하게 통합해야한다.

1. 외부코드 사용하기

- 패키지 제공자나 프레임워크 제공자는 적용성을 최대한 넓히려 애쓴다. 더 많은 환경에서 돌아가야 더 많은 고객이 구매하니까. 반면, 사용자는 자신의 요구에 집중하는 인터페이스를 바란다.
- 이런 긴장으로 인해 시스템 경계에서 문제가 생길 소지가 있다.
- 프로그램에서 Map<String, Sensor> 인스턴스를 여기저기로 넘긴다면, Map 인터페이스가 변할 경우, 수정할 코드가 상당히 많아진다.
- 경계 인터페이스인 Map을 Sensors 안으로 숨긴다. Sensors 클래스 안에서 객체 유형을 관리하고 변환하기 때문이다.
- Map과 같은 경계 인터페이스를 이용할 때는 이를 이용하는 클래스나 클래스 계열 밖으로 노출되지 않도록 주의한다.
- Map 인스턴스를 공개 API의 인수로 넘기거나 반환값으로 사용하지 않는다.

2. 경계 살피고 익히기

- 외부 패키지 테스트가 우리 책임은 아니다. 하지만 우리 자신을 위해 우리가 사용할 코드를 테스트하는 편이 바람직하다.
- 우리 버그인지 라이브러리 인지 찾아내느라 오랜 디버깅으로 골치를 앓는다.
- 곧바로 우리 쪽 코드를 작성해 외부 코드를 호출하는 대신 먼저 간단한 테스트 케이스를 작성해 외부 코드를 익히면 어떨까?
- 학습 테스트라고 부른다.

3. log4j 익히기

- log4j 패키지를 사용하려 한다고 가정하자. 문서를 자세히 읽기 전에 첫 번째 테스트 케이스를 작성한다.
- log4j가 돌아가는 방식을 상당히 많이 이해했으며 여기서 얻은 지식을 간단한 단위 테스트 케이스 몇 개로 표현했다.
- 모든 지식을 독자적인 로거 클래스로 캡슐화한다. 그러면 나머지 프로그램은 log4j 경계 인터페이스를 몰라도 된다.

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

- 학습 테스트는 이해도를 높여주는 정확한 실험이다. 패키지 새 버전이 나온다면 학습테스트를 돌려 차이가 있는지 확인한다.
- 학습테스트는 패키지가 예상대로 도는지 검증한다. 일단 통합한 이후라고 하더라도 패키지가 우리 코드와 호환되리라는 보장은 없다.
- 이런 경계 테스트가 있다면 패키지의 새 버전으로 이전하기 쉬워진다.

5. 깨끗한 경계

- 소프트웨어 설계가 우수하다면 변경하는데 많은 투자와 재작업이 필요하지 않다.
- 경계에 위치하는 코드는 깔끔히 분리한다. 또한 기대치를 정의하는 테스트 케이스도 작성한다.
- 외부 패키지를 호출하는 코드를 가능한 줄여 경계를 관리하자.