Post

Clean Code 08장. 경계

TIL(Today I Learn)

2024.07.05


오늘 읽은 범위

8장. 경계


책에서 기억하고 싶은 내용을 써보세요.

경계

  • 이 장에서는 소프트웨어 경계를 깔끔하게 처리하는 기법과 기교를 배운다.

외부 코드 사용하기

  • 인터페이스 제공자와 인터페이스 사용자 간에 입장 차이가 있다. 인터페이스 제공자는 최대한 많은 기능을 제공함으로써 적용성을 높히려 한다. 인터페이스 사용자는 자신의 시스템이 필요로 하는 기능만 가지고 싶어 한다.

  • Map 사례로 보는 입장 차이
    • 인터페이스 제공자는 Map 안에 저장된 객체가 삭제되는 것을 원치 않는다.
    • 인터페이스 사용자는 Map에서 제공하는 clear() 메서드를 이용하여 객체를 삭제한다.
  • Map<String, Sensor> 사례로 보는 입장 차이
    • 인터페이스 제공자는 Map<String, Sensor> 안에 저장된 객체가 조작되는 것을 원치 않는다.
    • 인터페이스 사용자는 Map에서 제공하는 인터페이스를 이용하여 제공자의 의도에 벗어난 동작을 수행한다.
  • Sensors 사례
    • Sensors 클래스는 경계 인터페이스인 Map을 자체 클래스 안에 숨겨둔다.
      • Map 인터페이스가 변하더라도 나머지 프로그램에 영향을 미치지 않는다.
      • Sensors 클래스 안에서 객체 유형을 관리하므로 제네릭 사용 유무는 문제되지 않는다.
    • Sensors 클래스는 프로그램에 필요한 인터페이스만 제공한다.
      • 코드는 이해하기 쉬워지며 개발자의 의도에 벗어난 동작을 원천 차단할 수 있다.
  • 따라서! Map과 같은 경계 인터페이스를 이용할 때는, 이를 밖으로 노출하지 않는다. 또는 Map 인스턴스를 공개 API의 인수로 넘기거나 반환값으로 사용하지 않는다.

경계 살피고 익히기

  • 외부 라이브러리 코드는 배우기 어려우며, 우리 회사의 코드와 통합하는 것도 쉽지않다. 문제 해결을 위해 간단한 테스트 케이스를 작성함으로써 라이브러리를 익히는 과정이 중요하다. 이를 학습 테스트라고 한다.

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

  • 학습 테스트의 장점
    • 라이브러리 사용법에 대한 이해도를 높여줄 수 있다.
    • 새로운 버전의 라이브러리가 출시되면 기존에 작성된 학습 테스트와 비교하여 호환성 확인이 가능하다.
    • 이와 같은 인터페이스에 대한 경계 테스트가 있다면 패키지의 새 버전으로 쉽게 이전이 가능하다.

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

  • 경계와 관련해 또 다른 유형은 우리가 아는 코드와 모르는 코드를 분리하는 경계다. 모르는 코드 영역에 대한 인터페이스를 설계하면 우리가 인터페이스를 통제할 수 있다. 필요한 인터페이스를 직접 설계했으므로 가독성도 좋고 의도도 분명한 코드를 작성할 수 있다. Fake 클래스를 이용한 테스트 케이스 작성도 쉽게 할 수 있다.

깨끗한 경계

  • 소프트웨어 설계가 우수하다면 변경에 많은 투자와 재작업이 필요하지 않다.
  • 특히, 경계와 같은 부분의 설계가 미흡하다면 프로그램 변경 발생 시, 변경 비용이 훨씬 커질 수 있다.
  • 우리 코드에서 외부 패키지를 세세하게 알아야 할 필요가 없다.
  • 통제가 불가한 외부 패키지에 의존하는 대신 통제가 가능한 우리 코드에 의존하는 편이 훨씬 좋다.
  • 외부 패키지를 호출하는 코드를 가능한 줄여 경계를 관리하는 것이 중요하다.
  • 새로운 클래스로 경계를 감싸거나 ADAPTER 패턴을 사용하여 우리가 원하는 인터페이스로 변환할 수 있다.
  • 깨끗한 경계를 유지하면 외부 패키지가 변했을 때 우리가 변경해야 할 코드는 줄어들 것이다.


오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.

  • 외부 라이브러리를 제대로 활용하면 프로그램 개발 시간을 많이 단축할 수 있다.
    학습 테스트를 통해 외부 라이브러리를 검증할 수 있다면, 라이브러리 버전 변경에 쉽게 대응할 수 있을 것이다.

  • 다양한 라이브러리 덕분에 개발을 쉽게 할 수 있다. 반대로 말하면 라이브러리에 지배받는 프로그램 코드가 만들어졌다.
    이번 장에서 배운 것처럼 외부 라이브러리와의 경계를 제대로 설계할 수 있다면 코드를 깔끔하게 유지할 수 있을 것이다.

  • 이번 장의 내용은 개발자의 경험에 따라 느낄 수 있는 범위가 다를 수 있겠다는 생각을 했다.
    다양한 개발 경험을 하며 설계에 대한 고민을 많이 한다면 깨끗한 경계를 구성할 수 있을 것이다.


궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.


This post is licensed under CC BY 4.0 by the author.