Don't give up!

[클린코드] 8장 경계 본문

개발서적/클린 코드

[클린코드] 8장 경계

Heang Lee 2021. 7. 27. 16:24
이 글은 로버트 마틴의 '클린 코드'를 읽고 TIL(Today I Learned)로써 정리한 내용을 기록하는 글입니다.
자세한 내용은 책을 통해 확인하실 수 있습니다.

알라딘: 클린 코드 Clean Code (aladin.co.kr)

 

클린 코드 Clean Code

로버트 마틴은 이 책에서 혁명적인 패러다임을 제시한다. 그는 오브젝트 멘토(Object Mentor)의 동료들과 힘을 모아 ‘개발하며’ 클린 코드를 만드는 최상의 애자일 기법을 정제해 책 한 권에 담았

www.aladin.co.kr

경계

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

외부 코드 사용하기

  • 패키지 제공자나 프레임워크 제공자는 적용성을 최대한 넓히려 애쓴다.
  • 사용자는 자신의 요구에 집중하는 인터페이스를 바란다.
  • 이러한 긴장으로 인해 시스템 경계에서 문제가 생길 소지가 많다.
//나쁜 코드 - 형변환이 매번 있으며 sensors의 권한이 사용하는 모두에게 존재함.
Map sensors = new HashMap();
Sensor s = (Sensor)sensors.get(sensorId);

//Generics 사용하여 개선 - 코드 가독성은 높아지지만 권한 문제는 해결x, Map 인터페이스가 변경되면 수정해야할 부분이 생긴다.
Map<String, Sensor> sensors = new HashMap<Sensor>();
Sensor s = sensors.get(sensorId);

//Map을 캡슐화하는 Sensors 클래스 정의하여 개선 -  권한 문제도 해결할 수 있음.
public class Sensors {
  private Map sensors = new HashMap();
  
  public Sensor getById(String id) {
    return (Sensor)sensors.get(id);
  }
}
  • 외부 API를 캡슐화하면 나머지 프로그램이 설계 규칙과 비즈니스 규칙을 따르도록 강제할 수 있다.
  • 외부 API를 이용할 때는 이를 이용하는 클래스나 클래스 계열 밖으로 노출되지 않도록 주의해야 한다.

경계 살피고 익히기

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

학습 테스트

  • 학습 테스트는 프로그램에서 사용하려는 방식대로 외부 API를 호출한다.
  • 학습 테스트는 다음의 순서대로 진행한다.
    1. 외부 패키지의 문서를 자세히 읽기 전에 첫 번째 테스트 케이스를 작성한다.
    2. 오류를 해결하기 위해 문서를 읽고 테스트를 해결한다.
    3. 얻은 지식을 토대로 간단한 단위 테스트 케이스들이 담긴 테스트 클래스로 표현한다.
    4. 테스트 클래스로부터 얻은 지식을 바탕으로 독자적인 클래스로 외부 API를 캡슐화한다.
  • 학습 테스트는 필요한 지식만 확보하는 손쉬운 방법이다.
  • 패키지 새 버전이 나오면 학습 테스트를 돌려 차이가 있는지 확인할 수 있다.
  • 학습 테스트만 돌려도 우리 코드와 호환되는지 확인할 수 있다.
  • 이러한 경계 테스트가 있다면 패키지의 새 버전으로 이전하기 쉬워진다.

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

  • 때로는 우리 지식이 경계를 너머 미치지 못하는 코드 영역도 있다.
  • 코드를 작성하는 우리는 경계가 어디쯤인지 대략적으로 알 수 있다. (필요한 경계 인터페이스를 알 수 있음.)
  • 자체적으로 우리가 바라는 인터페이스를 정의하라.

어댑터 패턴 (ADAPTER PATTERN)

  • 어댑터 패턴은 클래스의 인터페이스를 사용자가 기대하는 다른 인터페이스로 변환하는 패턴이다.
  • API 사용을 캡슐화해 API가 바뀔 때 수정할 코드를 한곳으로 모으면 구현을 나중으로 미룰 수 있다.
  • 우리가 바라는 인터페이스를 구현하면 우리가 인터페이스를 전적으로 통제한다는 장점이 생긴다.
  • 코드 가독성도 높아지고 코드 의도도 분명해진다.
  • 테스트도 아주 편하다. API 인터페이스가 나온 다음 테스트 케이스를 생성해 API를 올바로 사용하는지 테스트할 수 있다.

구현을 나중으로 미루고 바라는 인터페이스를 구현하라 

정리

  • 외부 API는 우리가 통제할 수 없는 영역이며 제공자와 사용자의 목적이 달라 권한 등의 문제가 발생할 수 있다.
  • 경계에 위치하는 코드는 깔끔히 분리하라.
  • 기대치는 정의하는 테스트 케이스를 작성하라.
  • 통제가 불가능한 외부 패키지에 의존하는 대신 통제가 가능한 우리 코드에 의존하라.
  • 외부 패키지를 호출하는 코드를 가능한 줄여 경계를 관리하라. (새로운 클래스로 경계를 감싸거나, 어댑터 패턴을 사용해 원하는 인터페이스를 패키지가 제공하는 인터페이스로 변환하라.)