[노개북 챌린지] 실용주의 프로그래머 5

실용주의 프로그래머 5장 < 구부러지거나 부러지거나 >

Today reading range

- 오늘 읽은 범위


실용주의 프로그래머 5장 < 구부러지거나 부러지거나 >

Impressive content

- 인상 깊었던 내용


삶은 멈추지 않는다. 우리가 작성하는 코드도 마찬가지다. 현대의 미친 듯이 빠른 변화 속도를 따라가려면 모든 수단을 동원하여 가능한 한 느슨하고 유연한 코드를 작성해야 한다. -181p.

Topic28. 결합도 줄이기

우리가 어떤 것 하나만을 골라내려고 해도, 그것이 우주의 다른 모든 것과 얽혀 있음을 깨닫게 된다.

- 존 뮤어(John Muir), << 나의 첫 여름 >>

Tip44 결합도가 낮은 코드가 바꾸기 쉽다. -184p.

다음과 같은 결합의 증상을 노치지 않도록 주의해야한다.

  • 관계없는 모듈이나 라이브러리 간의 희한한 의존 관계
  • 한 모듈의 '간단한' 수정이 이와 관계없는 모듈을 통해 시스텀 전역으로 퍼져나가거나 시스템의 다른 곳에서 무언가를 깨뜨는 경우
  • 개발자가 수정하는 부분이 시스템에 어떤 영향을 미칠지 몰라 코드의 수정을 두려워하는 경우
  • 변경사항에 누가 영향을 받는지 파악하는 사람이 없어서 결국 모든 사람이 참석해야하는 회의

모든 객차가 서로 연결되어 있듯이 매서드나 속성들이 모두 연결되어 있다. 이런 코드를 열차 사고라고 부른다. -185p

Tip 45 묻지말고 말하라.

이 원칙은 다른 객체의 내부 상태에 따라 판단을 내리고 그 객체를 갱신해서는 안 된다는 것이다.

LoDs는 어떤 클래스 C에 정의한 메서드가 다음 목록에 속하는 것만 사용할 수 있다고 제한한다. -188p

  • C의 다른 인스턴스 메서드
  • 메서드의 매개 변수
  • 스택이나 힙에 자신이 생성하는 객체의 메서드
  • 전역 변수

이 원칙을 다음과 같이 더 쉬운 표현으로 바꿔보았다.

Tip 46 메서드 호출을 엮지 말라.

무언가에 접근할때 '.' 을 딱 하나만 쓰려고 노력해 보라.

전역 데이터 하나하나는 애플리케이션의 모든 메서드에 갑자기 매개 변수가 추가된 것과 같은 효과를 낸다. 전역 데이터는 모든 메서드 안에서 사용할 수 있으니 말이다. -190p.

Tip 47 전역 데이터를 피하라

Topic29. 실세계를 갖고 저글링하기

사람이 컴퓨터에 맞추기보다는 컴퓨터가 우리 세계 안으로 들어와야한다. 그리고 우리 세계는 엉망이다. -193p

우리를 도아줄 네 가지 전략을 살펴보자.

  1. 유한 상태 기계Finite State Machine, FMS
  2. 감시자Observer 패턴
  3. 게시-구독
  4. 반응형 프로그래밍과 스트림

하지만 감시자 패턴에는 문제가 하나 있다. 모든 감시자가 감시 대상에 등록해야되기 때문에 결합이 생긴다.

게시Publish-구독Subscribe 혹은 발행-구독 모델은 줄여서 펍섭pubsub 이라고도 부르며 감시자 패턴을 일반화한 것이다. 동시에 감시자 모델의 결합도를 높이는 문제와 성능 문제도 해결한다.

게시-구독 모덜은 추가적인 결합없이 비동기 이벤트 처리를 구현하기에 아주 좋은 기술이다. ... 대신 단점은 게시-구독 모델을 아주 많이 사용하는 시스템에서는 현재 어떤 일이 벌어지고 있는지 파악하기 힘들다는 것이다.

스트림은 이벤트를 일반적인 자료 구조처럼 다룰 수 있게 해 준다.

2021년 기준으로 반응 이벤트 처리의 사실상 표준은 https://reactivex.io/ 웹사이트에서 정의했다. 이 웹 사이트는 언에 무관한 원칙들을 정의하고 몇가지 공통 구현 사항을 문서화했다.

우리가 사용하는 곳은 https://reqres.in/ 로 누구에게나 테스용 REST 인터페이스를 제공한다.

하지만 이벤트가 어디서 발생하든 이벤트를 중심으로 공들여 만든 코드는 일직선으로 수행되는 코드보다 더 잘 반응하고 결합도가 더 낮다.

Topic30. 변환 프로그래밍

자신이 하고 있는 걸 하나의 과정으로 서술할 수 없다면, 자기가 뭘 하고 있는지 모르는 것이다.
- W. 에드워즈 데밍(W. Edwards Deming)

우리는 설계를 고민할 때 (데이터)변환을 만드는 것에 대해서는 거의 생각하지 않는다. ... 우리는 이렇게 코드에만 집중하면 핵심을 놓칠 수 있다고 본다. 프로그램이란 입력을 출력으로 바꾸는 것이라는 사고방식으로 돌아갈 필요가 있다.

Tip 49 프로그래밍은 코드에 관한 것이지만, 프로그램은 데이터에 관한 것이다.

파이프 라인을 사용하면 자동으로 데이터 변환의 관점에서 생각하게 된다. 여러분이 |> 를 볼 때마다 여러분은 데이터가 한 변환에서 다음 변환으로 흘러간느 것을 실제로 보는 셈이다.

자바스크립트에 |>를 추가하는 논의도 2021년 현재 진행 중이다.

X언어에는 파이프라인이 없는데요.
...

하지만 실망하지않아도 된다. 변환을 중심으로 생각하는데 특별한 문법이 꼭 필요하지않다. ... 다만 단계마다 임시 변수에 값을 저장해야될 뿐이다. (아래 예제 참고)

const content = File.read(file_name);
const lines = find_matching_lines(content, pattern);
const result = truncate_lines(lines);

데이터를 전체 시스템 여기저기의 작은 웅덩이에 흩어 놓는 대신, 데이터를 거대한 강으로, 흐름으로 생각하라.

Topic31. 상속세

당신이 원한 것은 바나나 하나였지만, 당신이 받는 것은 바나나를 들고 있는 고릴라와 정글 전체다.

  • 조 암스트롱(Joe Armstrong)

상속은 타입을 조합하는 방법이라고 설명하는 시뮬라 방식은 C++나 자바 같은 언어가 계승했다. 상속은 동작을 다양하게 구성하는 방법이라고 설명하는 스몰토크 방식은 루비나 자바스크립트 같은 언어에서 찾아볼 수 있다.

상속도 일종의 결합이다.

어떤 이들은 상속을 새로운 타입을 정의하는 방법이라고 여긴다.

더는 상속을 쓸 필요가 없게 해 주는 세 가지 기법을 소개하겠다.

  • 인터페이스와 프로토콜
  • 위임
  • 믹스인과 트레이트

Tip 53 서비스에 위임하라. Has-A가 Is-A보다 낫다.

믹스인...클래스나 객체에 상속을 사용하지 않고 새로운 기능을 추가하여 확장하고 싶다.

언어에 무관한 기능이라고 생각해 주면 좋겠다. 중요한 것은 이 기능을 구현했을 때 할 수 있는 일, 바로 기존의 것과 새로운 것의 기능 집합을 합치는 것이다.

Topic32. 설정

애플리케이션이 출시된 이후 바뀔 수도 있는 값에 코드가 의존하고 있다면 그 값을 애플리케이션 외부에서 관리하라.

기본적으로 나중에 바뀌리라 알고 있는 것, 소스 코드 본체 바깥에 표현할 수 있는 것을 찾아라. 그리고 설정 더미에 던져 넣어라.

대신 설정 정보를 (얇은) API 뒤로 숨겨라.

서비스형 설정에는 몇 가지 장점이 있다.

  • 여러 애플리케이션이 설정 정보를 공유할 수 있다. 인증과 접근 제어를 붙여서 애플리케이션마다 보이는 정보가 다르게 만들 수도 있다.
  • 여러 인스턴스에 걸쳐서 전체 설정을 한번에 바꿀 수 있다.
  • 설정 데이터를 전용 UI로 관리할 수 있다.
  • 설정 데이터를 동적으로 계속 바꿀 수 있다.

외부 설정을 사용하지 않는다면 코드는 적응성이나 유연성을 어느 정도 포기해야만 한다. 이것은 얼마나 나쁜 일일까? 글쎄, 프로그램의 세계에서 잠시 벗어나 실제 세상의 이야기를 하자면 환경에 적응하지 못하는 생물은 멸종한다.

Thoughts I had while reading the book

- 오늘 책을 읽으면서...


최근 프로젝트 작업을 하면서 이벤트 때문에 머리가 아팠던 일이 있어서 Topic 29번을 집중해서 읽으려고 노력했다.(완벽하게 이해하지는 못한거 같다.) 하지만 이벤트를 좀 더 다양한 방법으로 구현할 수 있도록 변형해보고 싶다는 생각이 들었다. 저번에 올렸던 JS API 중 Observer API를 내가 생각했던 것보다 더 다양한 방법으로 이용할 수 있을지 연구해봐야겠다.

연습 문제 20

  • 5분동안 '네트워크 인터페이스가 꺼짐' 이벤트를 세 번 받으면 운영 직원에게 알려라. => 반응형 프로그래밍과 스트림(O)
  • 일몰 후에 층계 밑에서 동작이 감지된 다음 층계 위에서 동작이 감지되면 위층의 전등을 켜라. => 감시자 패턴(X, 게시-구독)
  • 다양한 보고 시스템에 주문이 완료되었음을 알리고 싶다. => 유한 상태 기계(FMS) (X,게시-구독)
  • 고객에게 자동차 대출을 집행할 수 있는지 평가하기 위하여 애플리케이션이 세 가지 다른 서비스에 요청을 보내고 응답을 기다려야 한다. => 게시-구독 (X, 스트림)

ㅋㅋㅋ다 틀렸네ㅋㅋ다시 읽어야되나보다..😂

엘릭서의 and_then은 JS promise의 then과 비슷한 기능을 하는것 같다.

연습 문제 21

  1. 주문에 부가세와 배송비가 더해진다.
    • 입력 : 주문 ID
    • 출력 : 주문 ID 가격과 가격에 부가세(가격 * 세율)와 배송비가 더해진 값
  2. 정해진 파일 경로에서 애플리케이션의 설정 정보를 읽어 들인다.
    • 입력 : 파일 경
    • 출력 : 애플리케이션의 설정 정보
  3. 웹 애플리케이션에 누군가 로그인한다.
    • 입력: 아이디와 패스워드
    • 출력: 회원가입 여부

(다 틀렸다..!! 데이터 변환을 중점으로 생각하자!!)

시뮬라의 상속은 타입에 타입을 더하는 상속이라면 스몰토크의 상속은 더 다양한 동작을 위한 상속이라는 의미인걸까.

Topic 32. 설정을 보면서 나도 이번에 node.js로 공부할 떼 서비스형 설정을 따로 만들어야겠다는 다짐을 했다!

Things you're curious about, things you don't understand.

- 궁금한 내용, 이해되지 않았던 내용


FSM 부분이 제대로 이해되지 않았다. 예시 코드를 JS로 변경해서 구현해보는것도 좋을 것같다.

좋은 웹페이지 즐겨찾기