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

안녕하세요 😀

 유로띠 입니다 😉

 

 

 

 

 

 

실용주의 프로그래머

---

TIL (Today I Learned)

3줄 요약

 

✏️  구부러지는 유연한 코드를 작성하자.

✏️  묻지 말고 말하라, TDA

✏️  내 코드가 도도새가 되지 말자.

 

DAY 5

오늘 읽은 범위: 구부러지거나 부러지거나

 

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

🟢  가능한 한 느슨하고 유연한 코드를 작성해야 한다. (P.181)

🟢  유연함을 유지하는 한 가지 좋은 방법은 물론 가능한 한 코드를 적게 작성하는 것이다. 이런 모든 기법을 활용하면 여러분의 코드가 부러지지 않고 구부러질 것이다. (P.182)

 

결합도 줄이기

🟢  높은 결합도는 변경의 적이다. (P.182)

🟢  소프트웨어의 구조는 유연해야 한다. (P.183)

🟢  결합도가 낮은 코드가 바꾸기 쉽다. (P.184)

🟢  다음과 같은 결합의 증상을 놓치지 않도록 주의해야 한다. (P.184)

관계없는 모듈이나 라이브러리 간의 희한한 의존 관계

한 모듈의 '간단한' 수정이 이와 관계없는 모듈을 통해 시스템 전역으로 퍼져 나가거나 시스템의 다른 곳에서 무언가를 깨뜨리는 경우

개발자가 수정하는 부분이 시스템에 어떤 영향을 미칠지 몰라 코드의 수정을 두려워하는 경우

변경 사항에 누가 영향을 받는지 파악하고 있는 사람이 없어서 결국 모든 사람이 참석해야 하는 회의 

🟢  묻지 말고 말하라. tell, Don't Ask, TDA

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

🟢  전역 데이터를 피하라. 싱글톤도 전역 데이터다. 외부 리소스도 전역 데이터다.

해법은 반드시 이 리소스들을 여러분이 작성하는 코드로 모두 감싸는 것이다. (P.191)

 

실세계를 갖고 저글링하기

🟢  유한 상태 기계(FSM) - 기본적으로 상태 기계는 이벤트를 어떻게 처리할지 정의한 명세일 뿐이다. 정해진 상태들이 있고 그중 하나가 '현재 상태'다. 상태마다 그 상태일 때 의미가 있는 이벤트들을 나열하고, 이벤트별로 시스템의 다음 '현재 상태'를 정의한다. (P.195)

 

🟢  감시자 패턴 - 이벤트를 발생시키는 쪽인 '감시 대상'과 이런 이벤트에 관심이 있는 클라이언트인 '감시자'로 이루어진다. (P.199)

🟢  게시-구독 - 게시(publish)-구독(subscribe) 혹은 발행-구독 모델은 줄여서 pubsub이라고도 부르며 감시자 패턴을 일반화한 것이다. 게시-구독 모델에는 게시자와 구독자가 있고, 이들은 채널로 연결된다. 각 채널에는 이름이 있다. 구독자는 관심사를 하나 이상의 채널에 등록하고, 게시자는 채널에 이벤트를 보낸다. (P.201)

🟢  반응형 프로그래밍과 스트림 - 스트림은 이벤트를 일반적인 잘 구조처럼 다룰 수 있게 해 준다. 또한 스트림은 비동기적으로 작동할 수도 있는데, 이벤트가 도착했을 때 여러분의 코드가 이벤트에 응답할 기회를 얻는다. (P.203)

 

변환 프로그래밍

🟢  프로그램이란 입력을 출력으로 바꾸는 것이라는 사고방식으로 돌아갈 필요가 있다. (P.207)

🟢  한쪽 끝에서 원료 데이터를 공급하면 반대쪽 끝에서 완성 제품인 정보가 나온다. 우리는 모든 코드를 이런 방식으로 생각하고 싶다. (P.210)

🟢  상태를 쌓아 놓지 말고 전달하라. 애플리케이션이 입력을 출력으로 바꾸어 나가는 진행 상황을 데이터로 자유롭게 표현할 수 있다. 이말인즉슨 결합을 대폭 줄일 수 있다는 것이다. (P.216)

 

상속세

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

🟢  안타깝지만 두 가지 상속 모두 문제가 있다. (P.226)

🟢  더 나은 대안 - 인터페이스와 프로토콜, 위임, 믹스인과 트레이트 (P.229)

🟢  인터페이스나 프로토콜이 강력한 까닭은 이들을 타입으로 사용할 수 있고, 해당 인터페이스를 구현하는 클래스라면 무엇이든 그 타입과 호환되기 때문이다. (P.230)

🟢  위임을 사용하면 클라이언트에게 프레임워크으 API를 전혀 노출하지않는다. 결합이 사라진 것이다. 그뿐만 아니라 우리는 더 이상 우리가 사용하는 프레임워크의 API에 제약을 받지 않고, 필요한 API를 마음대로 만들 수 있다. (P.232)

🟢  믹스인, 트레이트, 카테고리, 프로토콜 확장 - 클래스나 객체에 상속을 사용하지 않고 새로운 기능을 추가하여 확장하고 싶다. 기존 클래스와 그에 덧붙이는 믹스인의 동작을 모두 합한 새로운 클래스나 객체를 만든 것이다. (P.233)

 

설정

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

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

🟢  설정 정보를 (얇은) API 뒤로 숨겨라. 그러면 설정을 표현하는 세부 사항으로부터 여러분의 코드를 떼어 놓을 수 있다. (P.237)

🟢  어떤 형태를 사용하든지 애플리케이션을 실행 시켰을 때 설정 정보가 애플리케이션의 동작을 제어해야 한다. 설정 정보를 바꾸기 위해 코드 빌드가 필요해서는 안 된다. (P.238)

🟢  여러분의 프로젝트가, 여러분의 경력이 도도의 전철을 밟지 않도록 하라. (P.239)

 

 

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

✅  늘 이야기 했던 것 처럼 코드는 결합도를 낮춰야 한다. 예시에 나온 결합의 증상을 읽어보니 너무나 정확하여 깜짝 놀랐다. 운영과 거의 비슷한 테스트 환경을 갖추고 있어야 코드의 변경에 대해 영향도를 파악할 수 있고 파악을 하고 결합도가 높은 것을 리팩토링하여 낮춰야 겠다고 생각한다.

✅  책 마지막에 도도새의 전철을 밟지 않도록 하라는 말이 와닿았다. 내 경력이 멸종되지 않으려면 유연함을 가지고 구부러지되 부러지지 않도록 코드를 작성해야 겠다.

 

 

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

⭐️  유한 상태 기계

유한 상태 기계는 유한한 개수의 상태를 가질 수 있는 오토마타, 즉 추상 기계라고 할 수 있다.

이러한 기계는 한 번에 오로지 하나의 상태만을 가지게 되며, 현재 상태(Current State)란 임의의 주어진 시간의 상태를 칭한다.

이러한 기계는 어떠한 사건(Event)에 의해 한 상태에서 다른 상태로 변화할 수 있으며, 이를 전이(Transition)이라 한다.

특정한 유한 오토마톤은 현재 상태로부터 가능한 전이 상태와, 이러한 전이를 유발하는 조건들의 집합으로서 정의된다.

 

게임의 AI 처리를 위한 FSM 예시

⭐️ pub/sub

redis -pub/sub

gcp cloud pubsub