클린 코드 8장 : 경계

때로는 우리 버그인지 라이브러리 버그인지 찾아내느라 오랜 디버깅으로 골치를 앓는다. 이런 상황은 그리 놀랍지도 않다.

 

이번 장은 외부코드(다른 팀, 라이브러리)와 내부 코드(우리 팀이 만든 코드)의 경계를 처리하는 방법을 서술한다.

 

학습 테스트

- 에러가 발생하였을 때, 외부 코드의 문제인지 내부 코드의 문제인지 어려울 때가 생긴다. 하지만, 외부코드는 익히는 것도 통합하는 것도 어렵다.

- 그렇기 때문에, 외부 코드를 호출하기 전, 간단한 테스트 케이스를 작성하여 외부 코드를 테스트하는 방식이 있는데 이를 학습테스트 라 부른다. (짐 뉴커크의 테스트 주도 개발에 나온다 한다.)

- 학습 테스트를 통하여, 통제된 환경에서 API를 호출하여, 제대로 이해하였는 지 확인하는 것이다.

- 패키지의 새 버전이 나왔을 때, 학습테스트를 돌려서 기능이 달라졌는 지 확인할 수 있다. 불통과 시 달라진 것이고, 통과 시 문제가 없는 것이다. 이를 통해서 버전업에 대한 부담이 최소화된다.

 

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

transmitter만 수정하면 된다!

- Transmitter Adapter는 다른 팀이, Communication Controller는 저자가 만드는 상황이다. 단, 아직 두 팀 다 대략적인 상황만 알지 구체적인 API 명세를 작성하지 못했다.

- Transmitter Class는 외부코드에서 필요한 정보(frequency, stream)을 transmit이라는 메서드를 통해서 받고, 이를 잘 가공해서 원하는 방식으로 Communication Controller에 전달하도록 설계되어있다. 이 같은 패턴을 ADAPTER 패턴이라 한다.

- 이를 통해서, Transmitter Adapter는 Communication Controller와 독립적으로 구분되고 Adapter와 Transmitter만 API를 맞추면 되기 때문에 독립적으로 코드를 짤 수 있게 된다. 또한, 독립된 클래스이므로 학습 테스트를 작성하는 것도 매우 쉬워진다.

 

※ ADAPTER 패턴

- 현실에 어댑터처럼, 기존 코드(Adaptee)의 값을 Adapter의 operation 메서드를 통해서 수정한다. 그리고 이 값은 Client가 사용할 수 있는 Interface(Target) 형태이기에 Client가 바로 사용할 수 있다. 

결론

경계에 위치하는 코드를 깔끔하게 분리하면 외부 코드에 휘둘리지 않을 수 있다.

이를 깔끔하게 관리하도록 하자.