[실용주의 프로그래머] TIL (2022.03.25) 4장. 실용주의 편집증

다시보려고 쓰기·2022년 3월 24일

The Pragmatic Programmer 노개북 노마드코더 북클럽

실용주의 프로그래머 (The Pragmatic Programmer)

목록 보기

5/11

실용주의 프로그래머 (The Pragmatic Programmer)

오늘 TIL 3줄 요약

실용주의 프로그래머는 자기 자신을 믿지 않는다.
문서화는 책임을 지고 확실하고 명확하게
너무 앞서가지는 말고

TIL (Today I Learned) 날짜

2022.03.25

오늘 읽은 범위

4장. 실용주의 편집증

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

DBC
계약에 의한 설계 Design by Contact DBC
프로그램의 정확성을 보장하기 위해 소프트웨어 모듈의 권리와 책임을 문서화하고 합의하는 데에 초점을 맞춘다.

루틴의 전제와 선언 : 선행조건(Precondition), 후행조건(Postcondition), 클래스 불변식(Class invariant)
(p.149)

만약 호출자가 루틴의 모든 선행 조건을 충족한다면 해당 루틴은 종료시 모든 후행 조건과 불변식이 참이 되는 것을 보장한다.(p.150)

<p.54 Topic 10 - 직교성>에서 '부끄럼쟁이'코드를 작성하라고 권했다면, 이번 Topic에서는 '게으름뱅이' lazy 코드를 강조한다. 시작하기 전에 자신이 수용할 것은 엄격하게 확인하고, 내어 줄 것에 대해서는 최소한도를 약속하는 것이다.
함수형이든 객체 지향이든 절차형이든 모든 프로그래밍 언어에서는 DBC 는 여러분을 생각하게 한다.(p.151)

클래식 불변식 -> 상태 state

DBC와 TDD
단위테스트, 테스트 주도 개발 TDD(Test-Driven Development), 속성 기반 테스트 등에도 계약에 의한 설계(DBC)가 필요하다.

DBC는 테스트 환경 구성이나 목mock이 필요없다.
테스트는 하나가 한 가지 경우만 다루는 데 비해 DBC는 모든 입력값에 대해 성공과 실패를 정의한다.
TDD와 다른 테스트는 빌드 과정 중 '테스트'할 때만 수행되지만, DBC와 단정문은 설계, 개발, 배포, 유지 보수 전체에 걸쳐 사용된다.
DBC는 더 효율적이고 더 DRY하다. 아무도 데이터를 검증하지 않는 상황에 대비하기 위해 모든 사람이 데이터를 검증한다.
(p.152)

단정문이나 DBC방식을 사용하여 선행조건과 후행조건, 불변식을 검증하면 더 일찍 멈추고, 문제에 대한 보다 정확한 정부를 알려줄 수 있을 것이다. (p.154)

의미론적 불변식 Sementic invariant
철학적 계약 - 절대로 어겨서는 안되는 요구사항을 표현할 수 있다.

의미론적 불변식은 무언가 품은 진짜 의미의 중심이 되어야 하며, 훨씬 역동적으로 변하는 비즈니스 규칙처럼 일시적인 정책에 영향을 받으면 안된다.
명확하고 모호한 점이 없게 서술하도록 노력하라.
(p.156)

데이터가 우리가 생각하는 대로인지, 서비스에서 작동하는 코드가 우리가 생각하는 그 코드인지 확인해야 한다. 필요한 라이브러리들이 올바른 버전으로 실제로 로드됐는지도 확인해야 한다.

모든 오류는 정보를 준다. 일단 그놈의 오류 메시지 좀 읽어라. (p.159)

'하지만 물론 그런 일은 절대 일어나지 않을 거야.'라는 생각이 든다면 그런 일을 확인하는 코드를 추가하라. 가장 간단하게 추가하는 방법은 단정문 assertion을 사용하는 것이다. 단정문은 엄청나게 유용하다. 매개 변수나 결과가 절대 null이어서는 안된다면 명시적으로 검사하라.
(p.163)

헤드라이터를 앞서가지 말라. 헤드라이트는 투사거리라고 부르는 범위까지만 밝힐 수 있다. 우리는 너무 먼 미래는 내다볼 수 없고, 정면에서 벗어난 곳일수록 더 어둡다. 그래서 실용주의 프로그래머들에게는 확고한 규칙이 있다 "작은 단계들을 밟아라. 언제나."

언제나 신중하게 작은 단계들을 밟아라. 더 진행하기 전에 피드백을 확인하고 조정하라. 피드백의 빈도를 여러분의 제한 속도라고 생각하라.
(p.178)