클린코드 8장 경계

시스템에 들어가는 모든 소프트웨어를 직접 개발하는 경우는 드물다. 때로는 어떤 식으로든 외부 코드를 우리 코드에 깔끔하게 통합해야만 한다. 이 장에서는 소프트웨어 경계를 깔끔하게 처리하는 기법과 기교를 살펴본다.

외부 코드 사용하기 #

• 인터페이스 제공자와 사용자 사이에는 특유의 긴장이 존재한다.
  • 패키지 제공자는 적용성을 최대한 넓히려 애쓴다. 더 많은 환경에서 돌아가야 더 많은 고객이 구매하니까.
  • 반면, 사용자는 자신의 요구에 집중하는 인터페이스를 바란다. 이런 긴장으로 인해 시스템 경계에서 문제가 생길 소지가 많다.
• 자바의 Map 예시 → 경계 인터페이스인 Map을 Sensors라는 커스텀 클래스로 숨기고 Sensors에서 필요한 인터페이스를 제공함.
  • 외부 패키지를 자신의 클래스로 감싸서 인터페이스를 다시 정의하려는 의도인 것 같은데 갠적으로 이 예시에선 제네릭 쓰는게 나아보인다.

경계 살피고 익히기 #

• 외부 패키지 테스트는 우리 책임이 아니다. 하지만 우리 자신을 위해 우리가 사용할 코드를 테스트하는 편이 바람직하다.
• 곧바로 우리쪽 코드를 작성해 외부 코드를 호출하는 대신 먼저 간단한 테스트 케이스를 작성해 외부 코드를 익혀보자 → 학습 테스트

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

• 학습 테스트는 이해도를 높여줄 뿐만 아니라 패키지가 예상대로 도는지 검증도 한다.
• 통합한 이후라고 하더라도 패키지가 우리 코드와 항상 호환되리라는 보장은 없다.
• 패키지 새 버전이 나올 때 마다 새로운 위험이 생긴다. 학습테스트를 통해 위험을 감지 할 수 있다.

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

• 경계와 관련해 다른 유형은 아는 코드와 모르는 코드를 분리하는 경계다. 때로는 우리 지식이 경계를 너머 미치지 못하는 코드 영역도 있다.
• 자체적으로 인터페이스를 정의하자. 우리가 바라는 인터페이스를 구현하면 우리가 인터페이스를 전적으로 통제한다는 장점이 생긴다.
• 코드 가독성도 높아지고 코드 의도도 분명해진다.
• 외부 api가 완성된 후에는 어댑터 패턴으로 api 사용을 캡슐화한다.
• 이와 같은 설계는 테스트도 아주 편하다.

깨끗한 경계 #

• 경계에서는 흥미로운 일이 많이 벌어진다. 변경이 대표적이다.
• 소프트웨어 설계가 우수하다면 변경하는데 많은 투자와 재작업이 필요하지 않다. 엄청난 시간과 노력과 재작업을 요구하지 않는다.
• 통제하지 못하는 코드를 사용할 때는 너무 많은 투자를 하거나 향후 변경 비용이 지나치게 커지지 않도록 각별히 주의하자.
• 경계에 위치하는 코드는 깔끔히 분리하고, 기대치를 정의하는 테스트 케이스도 작성한다.
• 통제가 불가능한 외부 패키지에 의존하는 대신 통제가 가능한 우리 코드에 의존하는 편이 좋다.