[클린코드] CHAP 08 경계

CHAPTER 08 경계

💡 시스템에 들어가는 모든 소프트웨어를 직접 개발하는 경우는 드물며, 따라서 어떤 식으로든 이 외부코드를 우리 코드에 깔끔하게 통합하는 것이 중요하다

외부코드 사용하기

• 인터페이스 제공자와 사용자 사이에 존재하는 특유의 긴장으로 인하여 시스템 경계에서 문제가 생길 소지가 많다.
• java.util.map 클래스를 이용하여 메소드의 파라미터를 생성하여 넘기면, 해당 메서드에서 필요하지 않은 기능까지 제공한다는 문제점 발생.
• 제네릭을 이용하여 map 객체에 저장해야 할 유형을 지정하여 클라이언트에게 책임을 일부 넘길 수 있지만, 코드의 의도가 분명히 드러나지 않아 꺠끗한 코드라 보기는 어렵다.

public class Sensors {
    private Map sensors = new HashMap();

    public Sensor getById(String id) {
        return (Sensor) sensors.get(id);
    }
 }

→ 클래스로 경계를 감싸 원하는 기능만 제공하고 의도를 분명히 하는 예시

경계 살피고 익히기

• 외부 패키지 사용 시 해당 패키지의 테스트는 우리 책임이 아니지만, 우리가 사용할 코드를 테스트하는 편이 바람직하다.
• 외부 코드는 익히기도, 통합하기도 어려우며 어떤 버그인지 찾아내기 어렵다.
• 문서를 읽으며 사용법을 익히고 코드를 작성하는 방법 대신 간단한 테스트 케이스를 작성하여 외부 코드를 익히는 것이 좋다.
  • 학습테스트라고 하며 API를 사용하려는 목적에 초점을 맞춘다.
  • 통제된 환경에서 API를 제대로 이해하는지 확인

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

• 투자하는 노력보다 얻는 성과가 더 크다
• 패키지의 새 버전이 나오면 기존 학습 테스트를 돌려 예상대로 도는지 검증할 수 있다.
• 학습 테스트를 이용한 실제 학습 여부와 상관 없이 이러한 경계 테스트가 존재한다면, 패키지의 새 버전으로 이전하기 쉬워진다. 그렇지 않다면 낡은 버전을 필요 이상으로 오랫동안 사용하려는 유혹에 빠지기 쉽다

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

• 연동해야 할 API 를 아직 전달받지 못한 경우, 우리가 바라는 인터페이스를 구현하면 우리가 인터페이스를 전적으로 통제한다는 장점이 생긴다.
  • 코드 가독성이 높아지고, 코드의 의도도 분명해진다.
• 연동 대상 API를 전달받은 이후에는 인터페이스의 구현체를 구현하여, adapter 패턴으로 API 사용을 캡슐화 할 수 있다.

깨끗한 경계

• 소프트웨어 설계가 우수하다면 변경하는데 많은 투자와 재작업이 필요하지 않다.
• 통제하지 못하는 코드를 사용할 때는 너무 많은 투자를 하거나 향후 변경 비용이 지나치게 커지지 않도록 주의
• 경계에 위치하는 코드는 깔끔하게 분리해야 하고, 기대치를 정의하는 테스트 케이스도 작성해야 한다.

경계 관리 방안

• 새로운 클래스로 경계를 감싼다.
• Adapter 패턴을 이용하여 우리가 원하는 인터페이스를 패키지가 제공하는 인터페이스로 변환한다.