[클린코드] 8장. 경계

8장. 경계

시스템에 들어가는 모든 소프트웨어를 직접 개발하는 경우는 드물다. 때로는 패키지를 사고, 오픈 소스를 이용하고, 라이브러리를 이용한다. 때로는 사내 다른 팀이 제공하는 컴포넌트를 사용한다.

어떤 식으로든 이 외부 코드를 우리 코드에 깔끔하게 통합해야만 한다.

외부 코드 사용하기

• 인터페이스 제공자와 인터페이스 사용자 사이에는 특유의 긴장이 존재한다.
• 제공자는 적용성을 최대한 넓히려 애쓴다. 더 많은 환경에서 돌아가야 더 많은 고객이 구매하기 때문이다.
• 반면에 사용자는 자신의 요구에 집중하는 인터페이스를 바란다.

예를 들어, Map은 저장할 때 객체 유형을 제한하지 않는다. 따라서 Map이 반환하는 Object를 올바른 유형으로 변환할 책임은 Map을 사용하는 클라이언트에 있다.

또한 Map을 인수로 넘기거나 반환값으로 사용하면 나중에 Map 인터페이스 변경시 모든 코드를 변경해야 한다. 이처럼 외부 코드를 사용할 떄는 주의할 필요가 있다.

경계 살피고 익히기

외부 코드를 사용하면 적은 시간에 더 많은 기능을 출시하기 쉬워진다. 하지만 이러한 외부 라이브러리는 사용할 때 충분한 테스트를 통해 버그가 없는지, 실제 서비스에 적용해도 되는지 체크해야 한다. 그렇지 않으면 나중에 버그 발생시 디버깅하기가 어려워진다.

log4j 익히기

로깅 기능을 직접 구현하는 대신 아파치의 log4j 라이브러리를 사용하면 더 많은 기능의 로그를 쉽게 사용할 수 있다. (요즘은 logback을 주로 사용한다.)

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

학습 테스트에 드는 비용은 없다. 학습 테스트는 패키지가 예상대로 도는지 검사한다.

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

아는 코드와 모르는 코드를 분리하는 경계다. 알려고 해도 알 수 없는 코드 경계가 있다. 이럴 때는 직접 인터페이스를 만들어서 아는 코드로 분리하면 된다. 어댑터 패턴을 사용하면 API 사용을 캡슐화해 API가 바뀔 때 수정할 코드를 한 곳으로 모을 수 있다.

깨끗한 경계

소프트웨어 설계가 우수하다면 변경하는데 많은 투자와 재작업이 필요하지 않다.

경계에 위치하는 코드는 깔끔히 분리한다. 또한 기대치를 정의하는 테스트 케이스도 작성한다. 통제 불가능한 외부 패키지에 의존하는 대신 통제가 가능한 우리 코드에 의존하는 편이 훨씬 좋다. 자칫하면 오히려 외부 코드에 휘둘리고 만다.

References

• 클린코드