5장. 구부러지거나 부러지거나

오늘 TIL 3줄 요약

• 결합도를 줄이자. 결합도가 낮아야 나중에 코드를 바꾸기 쉽다.

• 상속을 피하고 인터페이스와 믹스인, 위임을 활용하자.

• 설정 값은 외부에서 변경할 수 있도록 하자.

TIL (Today I Learned) 날짜

2022/03/27

오늘 읽은 범위

5장. 구부러지거나 부러지거나

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

• 결합도 줄이기
  • 결합도가 낮은 코드가 바꾸기 쉽다.
  • 메서드 호출을 엮지 말라.
  • 무언가에 접근할 때 ”.”을 딱 하나만 쓰려고 노력해 보라.
    • 엮는 것들이 절대로 바뀌지 않을 것 같다면 이 규칙을 지키지 않아도 된다. 외부의 라이브러리 역시 불안정하다고 여겨야 한다.
  • 전역 데이터는 여러 가지 방법으로 코드의 결합도를 높인다.
  • 싱글턴(singleton)도 전역 데이터다
  • 외부 리소스도 전역 데이터다
  • 상속은 결합을 늘린다
  • 결합된 코드는 바꾸기 힘들다. 코드의 한 곳을 바꾸면 달느 곳에 여파가 미칠 수 있다.
• 실세계를 갖고 저글링하기
  • 감시자 패턴: 이벤트를 발생시키는 쪽인 ‘감시 대상’과 이런 이벤트에 관심이 있는 클라이언트인 ‘감시자’로 이루어진다. 감시자 패턴에는 문제가 하나 있다. 모든 감시자가 감시 대상에 등록을 해야 하기 때문에 결합이 생긴다. 더군다나 일반적으로 감시 대상이 콜백을 직접 호출하도록 구현하기 때문에 이 부분이 성능 병목이 될 수 있다.
  • 게시-구독: 게시(Publish)-구독(Subscribe) 혹은 발행-구독 모델은 줄여서 펍섭이라고도 부르며 감시자 패턴을 일반화한 것이다. 게시-구독 모델에는 ‘게시자’와 ‘구독자’가 있고, 이들은 채널로 연결된다.
  • 이벤트를 중심으로 공들여 만든 코드는 일직선으로 수행되는 코드보다 더 잘 반응하고 결합도가 더 낮다.
• 변환 프로그래밍
  • 프로그래밍은 코드에 관한 것이지만, 프로그램은 데이터에 관한 것이다.
  • 프로그램이란 입력을 출력으로 바꾸는 것이라는 사고방식으로 돌아갈 필요가 있다. 이렇게 생각하면 그동안 고민하던 많은 세부 사항이 모두 사라진다. 구조는 명확해지고 더 일관적으로 오류를 처리하게 되어 결합도 대폭 줄어들 것이다.
  • 파이프 왼쪽의 값을 오른쪽 함수의 마지막 인자로 넘기는 것을 파이프라인 연산자라고 한다. 파이프라인 연산자는 실직적인 면에서 다르게 생각할 혁신적 기회를 제공한다. 파이프라인을 사용하면 자동으로 데이터 변환의 관점에서 생각하게 된다.
  • 객체 지향 프로그래밍 경험이 많다면 반사적으로 데이터를 숨기고, 객체 안에 캡슐화해야 한다고 느낄 것이다. 이런 객체들은 서로 이리저리 이야기하며 서로의 상태를 변경한다. 이런 방식은 결합을 많이 만들어 내고, 이는 결국 객체 지향 시스템이 바꾸기 어려워지는 큰 요인이 된다.
• 상속세
  • 코드를 공유하기 위해 상속을 쓸 때의 문제: 자식 클래스가 부모 클래스, 부모의 부모, 또 그 부모에게 연결되는 것은 물론이요, 자식 클래스를 사용하는 코드도 이 클래스의 모든 조상과 얽히게 된다.
  • 다형성은 인터페이스로 표현하는 것이 좋다. 인터페이스와 프로토콜은 상속 없이도 다형성을 가져다준다.
  • 상속은 개발자들이 점점 더 메서드가 많은 클래스를 만들도록 유도한다.
  • 믹스인으로 기능을 공유하라.
• 설정
  • 외부 설정으로 애플리케이션을 조정할 수 있게 하라.
  • 일반적으로 설정 데이터 안에 넣는 것은 다음과 같다.
    • 데이터베이스나 외부 API 같은 외부 서비스의 인증 정보
    • 로그 레벨과 로그 저장 위치
    • 애플리케이션이 사용하는 포트 번호, IP 주소, 기계나 클러스터 이름
    • 특정 실행 환경에만 적용되는 검증 매개 변수
    • 외부에서 지정하는 매개 변수, 예를 들어 배송비
    • 지역에 따른 세부 서식
    • 라이선스 키
  • 정보가 구조화되어 있고 사용자가 바꿀 수도 있는 경우라면 데이터베이스 테이블에 저장하는 편이 나을 것이다.
  • 서비스형 설정
    • 여러 애플리케이션이 설정 정보를 공유할 수 있다. 인증과 접근 제어를 붙여서 애플리케이션마다 보이는 정보가 다르게 만들 수도 있다.
    • 여러 인스턴스에 걸쳐서 전체 설정을 한번에 바꿀 수도 있다.
    • 설정 데이터를 전용 UI로 관리할 수 있다.
    • 설정 데이터를 동적으로 계속 바꿀 수 있다.

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

• 설정 파트에서 이런 내용을 미리 알았더라면 이전에 내가 한 프로젝트에서 처음부터 더 좋게 만들 수 있었겠다고 생각했다. 개인 프로젝트에서 계절마다 인사말에 바꾸어야 하는 부분이 있었는데 그 부분을 데이터베이스나 다른 부분에서 따로 바꿀 수 있게 설정하지 않고 고정해서 넣어버렸다. 그래서 그 인사말은 바꾸려고 할 때마다 나는 애플리케이션을 다시 배포했어야 했다.
• 이 생각이 맞을지 모르겠지만 상속세 파트를 읽으면서 파이썬 장고 프레임워크가 떠올랐다. 최근 장고를 배우면서 클래스를 대부분 상속받아서 작성하게 되었는데 부모 클래스의 메소드, 변수들을 전부 알 수가 없어서 배우기 힘들었던 경험이 있다.