" 삶은 멈추지 않는다. 우리가 작성하는 코드도 마찬가지다. "
TIL (Today I Learn)
- Assignment 08
- 2022-03-26
오늘 읽은 범위
- 5장 구부러지거나 부러지거나
- Topic 28 결합도 줄이기
- Topic 29 실세계를 갖고 저글링하기
- Topic 30 변환 프로그래밍
- Topic 31 상속세
- Topic 32 설정
3줄 요약
- 묻지 말고 말하라 Tell, Don’t Ask, TDA.
- 상태를 쌓아 놓지 말고 전달하라.
- 환경에 적응하지 못하는 생물은 멸종한다.
책에서 기억하고 싶은 내용을 써보세요
Topic 28 결합도 줄이기
- 높은 결합도는 변경의 적이다.
- 묻지 말고 말하라 Tell, Don’t Ask, TDA.
- 다른 객체의 내부 상태에 따라 판단을 내리고 그 객체를 갱신해 서는 안 된다는 것이다.
- 데메테르 법칙 Law of Demeter, LoD
- 어떤 클래스 C에 정의된 메서드가 다음 목록에 속하는 것만 사용할 수 있다고 제한한다.C의 다른 인스턴스 메서드
- 메서드의 매개 변수
- 스택이나 힙에 자신이 생성하는 객체의 메서드
- 전역 변수
- 어떤 클래스 C에 정의된 메서드가 다음 목록에 속하는 것만 사용할 수 있다고 제한한다.C의 다른 인스턴스 메서드
- 무언가에 접근할 때 “.”을 딱 하나만 쓰려고 노력해 보라.
- 전역 데이터를 피하라.
- 외부로 노출된 인스턴스 변수가 잔뜩 있는 싱글턴은 여전히 전역 데이터이다. 그저 이름이 좀 길어졌을 뿐이다.
- 수정 가능한 외부 리소스는 모두 전역 데이터다.
- 전역적이어야 할 만큼 중요하다면 API로 감싸라.
- 상속은 결합을 늘린다
- 결국은 모두 ETC
- 직접적으로 아는 것만 다루는 부끄럼쟁이 코드를 계속 유지하라.
- Topid 29 실세계를 갖고 저글링하기
" 그냥 일어나는 일은 없다. 일어나도록 만들어진 것이다.
- 존 F. 케네디(John F. Kennedy) "
- 상태 기계는 이벤트를 어떻게 처리할지 정의한 명세일 뿐이다. 정해진 상태들이 있고 그중 하나가 ‘현재 상태’다. 상태마다 그 상태일 때 의미가 있는 이벤트들을 나열하고, 이벤트별로 시스템의 다음 ‘현재 상태’를 정의한다.
- 상태 기계는 개발자들에게 저평가되어 있다. 여러분이 상태 기계를 적용할 수 있는 곳을 한번 찾아보면 좋겠다
- ‘감시자-감시 대상’ 패턴은 수십 년간 쓰여 왔고, 잘 작동했다. 특히 사용자 인터페이스 시스템에서 널리 쓰이는데, 어떤 상호 작용이 일어났다는 것을 애플리케이션에 콜백으로 알려주는 방식을 사용한다.
모든 감시자가 감시 대상에 등록을 해야 하기 때문에 결합이 생긴다.
- 더군다나 일반적으로 감시 대상이 콜 백을 직접 호출하도록 구현하기 때문에 이 부분이 성능 병목이 될 수 있다.
- 게시 Publish -구독 Subscribe 혹은 발행-구독 모델은 줄여서 펍섭 pubsub이라고도 부르며 감시자 패턴을 일반화한 것이다. 동시에 감시자 모델의 결합도를 높이는 문제와 성능 문제도 해결한다.
- 게시-구독 모델에는 게시자와 구독자가 있고 이들은 채널로 연결된다.
- 각 채널에는 이름이 있다. 구독자는 관심사를 하나 이상의 채널에 등록하고, 게시자는 채널에 이벤트를 보낸다.
- 게시-구독 모델은 추가적인 결합 없이 비동기 이벤트 처리를 구현하기에 아주 좋은 기술이다.
- 단점은 현재 어떤 일이 벌어지고 있는지 파악하기가 힘들다는 것이다.
- 이벤트를 사용하여 코드가 반응하도록 할 수 있다는 것은 명백하다. 하지만 이벤트를 이리저리 연결하는 것도 쉽지만은 않다. 그래서 ‘스트림 stream’이 필요하다.
- 이벤트의 리스트를 다룬다
- 일반적으로 이벤트 스트림은 이벤트가 발생할 때마다 채워진다. 이 말은 이벤트를 발생시키는 감시 대상들을 병렬적으로 실행시킬 수 있다는 것이다.
- 이벤트가 어디서 발생하든 이벤트를 중심으로 공들여 만든 코드는 일직선으로 수행되는 코드보다 더 잘 반응하고 결합도가 더 낮다.
" 이벤트는 모든 곳에 있다. "
Topic 30 변환 프로그래밍
- 프로그램이란 입력을 출력으로 바꾸는 것이라는 사고방식으로 돌아갈 필요가 있다.
- 프로그래밍은 코드에 관한 것이지만, 프로그램은 데이터에 관한 것이다.
- 요구 사항에서 입력과 출력이 무엇인지 찾으면 전체 프로그램을 나타내는 함수가 정해진다.
- 애너그램(anagram)이란 단어의 철자 순서를 바꾸어서 만든 다른 단어를 말한다.
변환은 프로그래밍을 변환한다 - 코드를 일련의 (중첩된) 변환으로 생각하는 접근 방식은 프로그래밍을 해방 시킨다
Topic 31 상속세
" 객체 지향 언어로 프로그래밍하는가?
상속을 사용하는가?
아마 여러분에게 필요한 것은 상속이 아닐 것이다. "
- 상속은 타입을 조합하는 방법이라고 설명하는 시뮬라 방식은 C++나 자바 같은 언어가 계승했다.
- 타입을 좋아하는 이들은 상속으로 클래스 간의 관계를 표현한다.
- 상속은 동작을 다양하게 구성 하는 방법이라고 설명하는 스몰토크 방식은 루비나 자바스크립트 같은 언어 에서 찾아볼 수 있다.
- 타입을 싫어하는 이들은 입력하는 글자 수를 줄이기 위해 상속을 쓴다.
- 상속도 일종의 결합이다. 더는 상속을 쓸 필요가 없게 해 주는 세 가지 기법
- 1) 인터페이스와 프로토콜
- 인터페이스나 프로토콜이 강력한 까닭은 이들을 타입으로 사용할 수 있고, 해당 인터페이스를 구현하는 클래스라면 무엇이든 그 타입과 호환되기 때문이다.
- 다형성은 인터페이스로 표현하는 것이 좋다.
- 2) 위임
- Has-A가 Is-A보다 낫다.
- 3) 믹스인과 트레이트
- 방법과 명칭은 언어마다 제각각 --> 기존의 것과 새로운 것의 기능 집합을 합치는 것
- 믹스인으로 기능을 공유하라
- 1) 인터페이스와 프로토콜
- 정글 전체를 끌어들이지 않도록 조심하라.
Topic 32 설정
- 외부 설정으로 애플리케이션을 조정할 수 있게 하라.
- 설정 데이터를 동적으로 바꿀 수 있다는 점은 우리가 고가용 성 애플리케이션을 만들 때 매우 중요하다.
- 환경에 적응하지 못하는 생물은 멸종한다. (like 도도새)
- 하지만 지나치게 하지는 말라.
- 게으름 때문에 결정을 내리지 않고 설정을 추가하여 사용자에게 미루지 말라.
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
- 싱글턴 패턴이 사용하기 편하다 보니 다소 남용하며 살지 않았는지 반성하게 된다. 하지만 객체 할당을 처음 해두고 불러만 오는 (=내부 값은 변하지 않는) 용도로만 사용 중이라 크게 문제되진 않지 않을까.
- 실제로 이벤트 기반 아키텍처를 설계하다가 FSM을 도입했다. 현 개발 언어가 golang 이기 때문에 관련 라이브러리를 찾았지만 마땅한게 없더라. 너무 복잡하거나 애매하게 나사가 빠져있는 경우가 많았지. FSM의 가장 효율적인 모델은 Boost에 cpp로 구현된 모델이라 생각했기에 이 모델을 그대로 수용하는 golang FSM을 만들었고 아직까지 말썽 일으키지 않고 잘 굴러가고 있다. 이 친구 이름은 내 이름을 따 "HSM" 이라고 했었는데 언젠간 프로젝트 종료 후 좀 더 정리하여 외부에 오픈해도 괜찮을 것 같다.
- pubsub 모델은 처음 들어보는 디자인 패턴이다. 따로 공부하고 정리해서 팀원들한테 공유해야지.
- 이 책은 중간중간 토픽을 시작하며 누군가의 명언(?)을 인용하고 있는데 꽤나 심도있게 고른것 같다. 상속세를 설명하면서는 당신이 원한 것은 바나나 하나였지만, 당신이 받은 것은 바나나를 들고 있는 고릴라와 정 글 전체라니. 이 글만 봐도 어떤 점이 상속의 문제인지 대번에 알 수 있다. 이런 말들은 다 어디서 가져오는지... 아무튼 정성이겠지.
- 처음 개발업무를 시작할 때부터 사수님이 config를 굉장히 중요하게 생각하셨다. 그 모토가 아직까지 이어져 config 모듈을 보다 효율적이고 깔끔하게 사용할 수 있게 고도화도 진행중이다. 처음에는 굳이 필요한가라는 생각을 했던 것 같다. 하지만 머지않아 target domain을 바꿔야할 때 config만 변경 후 재시작하여 깔끔하게 해결했다. 내부 설정또한 일종의 "결합"이기 때문에 외부 설정을 활용하는 것도 ETC의 정신이겠지.
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요
- 작가가 말하고자 하는 의도는 알겠지만 실제로 코드에 어떻게 적용하게 될지는 선뜻 확신이 들지 않는다. 책 한 번 읽었다고 그게 되면 신기한거겠지만 어째 갈길이 멀다는 생각이...
'Book > Pragmatic Programmer' 카테고리의 다른 글
제 6장 동시성 (0) | 2022.03.29 |
---|---|
간단한 현실 점검 (연습문제 16) (0) | 2022.03.27 |
제 4장 실용주의 편집증 (0) | 2022.03.26 |
제 3장 기본 도구 (0) | 2022.03.24 |
제 2장 실용주의 접근법 (0) | 2022.03.22 |
댓글