실용주의 프로그래머 02

8. 좋은 설계의 핵심

ETC : easier to change

교체하기 쉬운지 스스로 항상 생각하면서 코드를 짤 것
좋은 설계는 나쁜 설계보다 바꾸기 쉽다.

복잡함의 통일성
수많은 디자인 패턴이나 아키텍처 SOLID 등의 원칙이 존재하지만 결국에는 유일한 목적은
변경의 용이성 임
도구에 집착하지 말고 본질 을 봐야한다.
이 패턴을 썼느냐가 중요한 것이 아니라, 그래서 나중에 바꾸기 쉬워졌냐 가 설계의 유일한 채점기준이다.

의식적 수련

좋은 설계는 천재적인 영감이 아니라, 일상적인 작업 속에서 ETC 인지를 자문하는 태도에서 나온다.
설계 능력은 습관 이다.
- 개발자는 항상 깨어있는 의식으로 코드의 미래를 고민해야함

9. DRY. 중복의 해악

`모든 지식은 시스템 내에서 단 한 번만, 애매하지 않고, 권위 있게 표현되어야 한다.`

DRY ( Don`t Repeat Yourself )
- 지식의 유일성을 강조함.
- 소프트웨어는 현실 세계의 지식을 컴퓨터로 번역함.
- 한 쪽을 수정하고 나머지 다른 한쪽을 수정하는 것을 잊어버린다면, 시스템을 거짓말을 하게 됨.
  - 신뢰성 감소

`DRY는 지식의 중복, 의도의 중복에 대한 것`

문법을 넘어서 의미로..
- 코드가 다르게 생겼어도 의도가 같다면 중복 이다.
- 코드가 같아도 의도가 다르면 중복이 아니다
코드 이면에 담긴 비즈니스 로직 과 변경의 이유 를 통찰해야함.

`재사용하기 쉽게 만들어라. 사람들은 쉽지 않으면 하지 않을 것이다`

아무리 좋은 원칙도 지키기 어려우면 무용지물임.
개발자는 바쁘고, 효율을 따지는 게으른 존재이다.
- 무언가를 새로 만드는 것 보다 기존의 것을 찾고, 이해하고, 적절하게 재사용하는 것이 더 쉽다고 느끼는 순간
- 재사용 대신 복 붙 을 선택함.
  - 저항이 작은 경로 로 설계해야함.
어떻게 재사용하기 쉽게 만드나
1. 검색 용이성
  1. 공통 모듈이나 유틸리티 코드를 찾기 쉬운 곳에 위치
2. 접근성
  1. 공통 기능을 사용하기 쉽고 안정적인 API 로 제공해야함
  2. 복잡한 내부 구현을 알 필요 없이 바로 가져다 쓸 수 있게 함.
3. 커뮤니케이션
  1. 코드 리뷰
  2. 스크럼 등으로 다른 팀원이 무엇을 만들고 있는지 공유
  3. 중복 구현을 사전에 방지한다.

10. 직교성(orthogonality)

나비 효과 없애기
- 내가 코드를 한 줄 고쳤을 때, 시스템 전체가 흔들리는 비극을 막자

1. 내가 이걸 고치면 어디까지 터질까 고민하기

직교적인 시스템
- 예약 시스템을 수정했는데
- 다른 구독관련 모듈까지 영향을 적게 주거나 아예 주지 않음
- 시스템적으로 좋음!

2. 개발자가 당장 실천할 고민

부끄럼쟁이 코드 를 짜고 있는지 고민하기
- 내 모듈의 내부 구현을 다른 모듈에 노출 X
전역 변수는 적인가?
- 필요한 데이터는 명시적으로 파라미터로 넘기자!
- 자바에서는 static 이 그 예시가 될 수 있겠다..
이거 하나만 떼어서 테스트 가능한가?
- 단위 테스트를 작성하기 쉽다면, 설계가 직교적임

11. 가역성

1. 최종 결정이란 없다

결정의 가변성을 받아들여라.
- 초기에 최고의 선택은 불가능하다
- 요구사항은 항상 변한다.
- 지금 시점에서의 최선의 선택 만 존재하지, 언제든 뒤집힐 수 있음
- 유연한 대처

2. 결정이 돌에 새겨진 것이 아니라 바닷가의 모래 위에 쓰인 글씨라 생각

모래 위의 글씨는 파도라는 변화가 오면 지워지고 다시 쓸 수 있다.
이 코드는 언제든 버려진다 라는 생각을 하고 개발
특정 기술에 강하게( 프레임워크, DB 등 ) 결합되지 않도록 해야 한다.
기술 교체 비용을 최소화 해야 한다.

3. 여러분의 코드가 로큰롤을 할 수 있게 하라. 락을 할 수도 롤을 할 수도 있게 하는 것이다.

Rock : 흔들기 → 튼튼한 프로그램
Roll : 구르기 → 유연한 프로그램
진화 가능한 아키텍처를 지향
근데 그게 말이 쉽지 ..

프로젝트를 진행하다가 보면 기획이 변경되는건 다반사
개발자는 그냥 코드를 유연하게 변경가능하게 짜도록 노력하고 손에 익히는 방법뿐임.

12. 예광탄

완벽한 계획보다는 불완전한 실행이 낫다
- 머릿속의 상상인 추측 보다
- 실제 구현을 통한 피드백 이 나음.
- 예광탄은 탄착군 확인이 가능함.
흐름이 뚫리면 → 그떄부터 디자인 패턴을 입히고 살을 붙여라.
심리적 안정감 UP

예광탄은 골격을 미리 짜서 구조에 대해 검증할때 사용하면 좋음

13. 프로토타입과 포스트잇

프로토타입은 대충 만든 베타 버전 이 아니라
- 위험 요소를 분석하고 학습하는 것임.
- 포스트잇으로 로직을 짜다가 오류 발견 → 포스트잇 한 장 값
이거 다듬어서 실제 제품으로 씁시다 라는 말이 나오는 경우
- 프로토타이핑이 아니라 예광탄 임

예광탄 vs 프로토타입

구분

예광탄

프로토타입

목적	전체 시스템 뼈대	특정 위험 요소 검증용
수명	영구적임	검증 후 폐기
비유	골격	정찰별 (미리 맞기)
재료	실제 사용된 언어와 환경	포스트잇, 스트립트 언어, 그림판

지금 프로젝트는 사실상 예광탄이라고 보면 됨
자료조사의 영역은 프로토타입 이다.
뭐 동기식 IO 호출과 비동기식 IO 에 대한 성능 테스트는 프로토타입이라고 볼 수 있을 듯

14. 도메인 언어

코드를 짜는 경우 프로그래밍 문법 에 갇히지 말고, 해결하려는 문제의 언어(비즈니스 용어) 로 코드가 읽도록 해야한다.
자바, 파이썬 등은 범용 언어임
- 모든 문제를 풀 수 있지만, 비즈니스 문제를 설명하기엔 너무 기계적

번역가보다는 원어민 이 되어야 함.

// 개발자만 알아봄
if (user.type == 1 && order.total > 10000) { ... }

보다는

// 기획자도 대충 알아봄
if (user.isVIP() && order.isBigOrder()) { ... }

이런식으로 무슨의미인지 설명할 수 있는 코드가 좋은 코드이다.

더 좋은 방법으로는

# 아예 문장처럼 씀
Scenario: VIP 고객 주문
  Given VIP 고객이
  When 10000원 이상 주문하면
  Then 할인을 적용한다

뭐 이런게 좋다는데 솔직히 이건 불가능할 거 같음.

앤서블이라는 외부 도메인 언어같은 것으로 쉽게 표현이 가능한데
```
- name: nginx 설치
  apt: name=nginx state=latest
```
- 이런식으로 (도커 컴포즈도 외부 도메인 언어라고 생각해도 될듯)
- 뭐 .. 그렇다고함.
결론적으로는
1. 코드가 소설 처럼 읽혀야 한다
2. 설정이 복잡하면 외부로 뺴라
3. 과유불급
  1. 내부 DSL 에서 왠만하면 처리 ㄱㄱ ( 자바나, 파이썬 같은 언어 )

15. 추정

정답은 없음 오차를 줄여나가는 과정
1. 130일 정도 걸려요 ← 상대방이 정확성 기대
2. 대략 6개월, 7개월 이런식으로 유연성을 가질 수 있도록 일정을 잡는 것이 유리하다.
  1. 단위 자체가 오차 범위를 암시함.
실천 추정 기법
1. 모델링과 분해
  1. 쇼핑몰을 만든다고 하면
    1. 로그인
    2. 상품 목록
    3. 결제
    4. 배송 추적
    등으로 쪼갬. → 각 컴포넌트 별로 추정 합산
  큰 문제를 분할 정복하게 된다면 → 오차들이 상쇄되어 전체적 정확도가 상승함.
2. 미사일에 페인트칠하기
  1. 하나의 값보다는 범위로 대답하기
    1. 뭐 잘 풀리면 10일정도구요..
    2. 서버 터지는 등의 문제가 있다면 25일 정도입니다..
    등으로 상대방도 리스크가 존재한다는 사실 인지
3. 코끼리 먹기
  1. 프로젝트 전체 일정을 한 번에 추정 X
  2. 스프린트 기간을 정해서
    1. 스프린트 기간인 2주 정도가 지나면 또 일정을 리팩토링하는 등의 행위 ㄱ
팁 : 나중에 연락드릴게요 전략 활용!
1. 얼마나 걸리냐고 물어보는 경우, 절대 그 자리에서 대답 X

8. 좋은 설계의 핵심

ETC : easier to change

교체하기 쉬운지 스스로 항상 생각하면서 코드를 짤 것
좋은 설계는 나쁜 설계보다 바꾸기 쉽다.

복잡함의 통일성
수많은 디자인 패턴이나 아키텍처 SOLID 등의 원칙이 존재하지만 결국에는 유일한 목적은
변경의 용이성 임
도구에 집착하지 말고 본질 을 봐야한다.
이 패턴을 썼느냐가 중요한 것이 아니라, 그래서 나중에 바꾸기 쉬워졌냐 가 설계의 유일한 채점기준이다.

의식적 수련

좋은 설계는 천재적인 영감이 아니라, 일상적인 작업 속에서 ETC 인지를 자문하는 태도에서 나온다.
설계 능력은 습관 이다.
- 개발자는 항상 깨어있는 의식으로 코드의 미래를 고민해야함

9. DRY. 중복의 해악

`모든 지식은 시스템 내에서 단 한 번만, 애매하지 않고, 권위 있게 표현되어야 한다.`

DRY ( Don`t Repeat Yourself )
- 지식의 유일성을 강조함.
- 소프트웨어는 현실 세계의 지식을 컴퓨터로 번역함.
- 한 쪽을 수정하고 나머지 다른 한쪽을 수정하는 것을 잊어버린다면, 시스템을 거짓말을 하게 됨.
  - 신뢰성 감소

`DRY는 지식의 중복, 의도의 중복에 대한 것`

문법을 넘어서 의미로..
- 코드가 다르게 생겼어도 의도가 같다면 중복 이다.
- 코드가 같아도 의도가 다르면 중복이 아니다
코드 이면에 담긴 비즈니스 로직 과 변경의 이유 를 통찰해야함.

`재사용하기 쉽게 만들어라. 사람들은 쉽지 않으면 하지 않을 것이다`

아무리 좋은 원칙도 지키기 어려우면 무용지물임.
개발자는 바쁘고, 효율을 따지는 게으른 존재이다.
- 무언가를 새로 만드는 것 보다 기존의 것을 찾고, 이해하고, 적절하게 재사용하는 것이 더 쉽다고 느끼는 순간
- 재사용 대신 복 붙 을 선택함.
  - 저항이 작은 경로 로 설계해야함.
어떻게 재사용하기 쉽게 만드나
1. 검색 용이성
  1. 공통 모듈이나 유틸리티 코드를 찾기 쉬운 곳에 위치
2. 접근성
  1. 공통 기능을 사용하기 쉽고 안정적인 API 로 제공해야함
  2. 복잡한 내부 구현을 알 필요 없이 바로 가져다 쓸 수 있게 함.
3. 커뮤니케이션
  1. 코드 리뷰
  2. 스크럼 등으로 다른 팀원이 무엇을 만들고 있는지 공유
  3. 중복 구현을 사전에 방지한다.

10. 직교성(orthogonality)

나비 효과 없애기
- 내가 코드를 한 줄 고쳤을 때, 시스템 전체가 흔들리는 비극을 막자

1. 내가 이걸 고치면 어디까지 터질까 고민하기

직교적인 시스템
- 예약 시스템을 수정했는데
- 다른 구독관련 모듈까지 영향을 적게 주거나 아예 주지 않음
- 시스템적으로 좋음!

2. 개발자가 당장 실천할 고민

부끄럼쟁이 코드 를 짜고 있는지 고민하기
- 내 모듈의 내부 구현을 다른 모듈에 노출 X
전역 변수는 적인가?
- 필요한 데이터는 명시적으로 파라미터로 넘기자!
- 자바에서는 static 이 그 예시가 될 수 있겠다..
이거 하나만 떼어서 테스트 가능한가?
- 단위 테스트를 작성하기 쉽다면, 설계가 직교적임

11. 가역성

1. 최종 결정이란 없다

결정의 가변성을 받아들여라.
- 초기에 최고의 선택은 불가능하다
- 요구사항은 항상 변한다.
- 지금 시점에서의 최선의 선택 만 존재하지, 언제든 뒤집힐 수 있음
- 유연한 대처

2. 결정이 돌에 새겨진 것이 아니라 바닷가의 모래 위에 쓰인 글씨라 생각

모래 위의 글씨는 파도라는 변화가 오면 지워지고 다시 쓸 수 있다.
이 코드는 언제든 버려진다 라는 생각을 하고 개발
특정 기술에 강하게( 프레임워크, DB 등 ) 결합되지 않도록 해야 한다.
기술 교체 비용을 최소화 해야 한다.

3. 여러분의 코드가 로큰롤을 할 수 있게 하라. 락을 할 수도 롤을 할 수도 있게 하는 것이다.

Rock : 흔들기 → 튼튼한 프로그램
Roll : 구르기 → 유연한 프로그램
진화 가능한 아키텍처를 지향
근데 그게 말이 쉽지 ..

프로젝트를 진행하다가 보면 기획이 변경되는건 다반사
개발자는 그냥 코드를 유연하게 변경가능하게 짜도록 노력하고 손에 익히는 방법뿐임.

12. 예광탄

완벽한 계획보다는 불완전한 실행이 낫다
- 머릿속의 상상인 추측 보다
- 실제 구현을 통한 피드백 이 나음.
- 예광탄은 탄착군 확인이 가능함.
흐름이 뚫리면 → 그떄부터 디자인 패턴을 입히고 살을 붙여라.
심리적 안정감 UP

예광탄은 골격을 미리 짜서 구조에 대해 검증할때 사용하면 좋음

13. 프로토타입과 포스트잇

프로토타입은 대충 만든 베타 버전 이 아니라
- 위험 요소를 분석하고 학습하는 것임.
- 포스트잇으로 로직을 짜다가 오류 발견 → 포스트잇 한 장 값
이거 다듬어서 실제 제품으로 씁시다 라는 말이 나오는 경우
- 프로토타이핑이 아니라 예광탄 임

예광탄 vs 프로토타입

구분

예광탄

프로토타입

목적	전체 시스템 뼈대	특정 위험 요소 검증용
수명	영구적임	검증 후 폐기
비유	골격	정찰별 (미리 맞기)
재료	실제 사용된 언어와 환경	포스트잇, 스트립트 언어, 그림판

지금 프로젝트는 사실상 예광탄이라고 보면 됨
자료조사의 영역은 프로토타입 이다.
뭐 동기식 IO 호출과 비동기식 IO 에 대한 성능 테스트는 프로토타입이라고 볼 수 있을 듯

14. 도메인 언어

코드를 짜는 경우 프로그래밍 문법 에 갇히지 말고, 해결하려는 문제의 언어(비즈니스 용어) 로 코드가 읽도록 해야한다.
자바, 파이썬 등은 범용 언어임
- 모든 문제를 풀 수 있지만, 비즈니스 문제를 설명하기엔 너무 기계적

번역가보다는 원어민 이 되어야 함.

// 개발자만 알아봄
if (user.type == 1 && order.total > 10000) { ... }

보다는

// 기획자도 대충 알아봄
if (user.isVIP() && order.isBigOrder()) { ... }

이런식으로 무슨의미인지 설명할 수 있는 코드가 좋은 코드이다.

더 좋은 방법으로는

# 아예 문장처럼 씀
Scenario: VIP 고객 주문
  Given VIP 고객이
  When 10000원 이상 주문하면
  Then 할인을 적용한다

뭐 이런게 좋다는데 솔직히 이건 불가능할 거 같음.

앤서블이라는 외부 도메인 언어같은 것으로 쉽게 표현이 가능한데
```
- name: nginx 설치
  apt: name=nginx state=latest
```
- 이런식으로 (도커 컴포즈도 외부 도메인 언어라고 생각해도 될듯)
- 뭐 .. 그렇다고함.
결론적으로는
1. 코드가 소설 처럼 읽혀야 한다
2. 설정이 복잡하면 외부로 뺴라
3. 과유불급
  1. 내부 DSL 에서 왠만하면 처리 ㄱㄱ ( 자바나, 파이썬 같은 언어 )

15. 추정

정답은 없음 오차를 줄여나가는 과정
1. 130일 정도 걸려요 ← 상대방이 정확성 기대
2. 대략 6개월, 7개월 이런식으로 유연성을 가질 수 있도록 일정을 잡는 것이 유리하다.
  1. 단위 자체가 오차 범위를 암시함.
실천 추정 기법
1. 모델링과 분해
  1. 쇼핑몰을 만든다고 하면
    1. 로그인
    2. 상품 목록
    3. 결제
    4. 배송 추적
    등으로 쪼갬. → 각 컴포넌트 별로 추정 합산
  큰 문제를 분할 정복하게 된다면 → 오차들이 상쇄되어 전체적 정확도가 상승함.
2. 미사일에 페인트칠하기
  1. 하나의 값보다는 범위로 대답하기
    1. 뭐 잘 풀리면 10일정도구요..
    2. 서버 터지는 등의 문제가 있다면 25일 정도입니다..
    등으로 상대방도 리스크가 존재한다는 사실 인지
3. 코끼리 먹기
  1. 프로젝트 전체 일정을 한 번에 추정 X
  2. 스프린트 기간을 정해서
    1. 스프린트 기간인 2주 정도가 지나면 또 일정을 리팩토링하는 등의 행위 ㄱ
팁 : 나중에 연락드릴게요 전략 활용!
1. 얼마나 걸리냐고 물어보는 경우, 절대 그 자리에서 대답 X