실용주의 프로그래머(The Pragmatic Programmer) 챌린지 5일차 TIL

오늘 TIL 3줄 요약

- 우리는 완벽한 소프트웨어를 만들 수 없다 / 실용주의 프로그래머는 자기 자신 역시 믿지 않는다.

- 계약으로 설계하라 (Design By Contract)

- 자신이 시작한것은 자신이 끝내라 / 지역적으로 행동하라

TIL 날짜

- 2022-03-24

오늘읽은 범위

- 4장. 실용주의 편집증

책에서 기억하고 싶은 내용

우리는 완벽한 소프트웨어를 만들 수 없다.

실용주의 프로그래머는 자기 자신 역시 믿지 않는다. 

계약에 의한 설계(DBC)

-함수의 전제와 선언

1. 선행 조건

루틴의 요구사항(파라미터)

2. 후행 조건

자기가 할 것이라고 보장하는것 / 무한반복 X

3. 클래스 불변식 (추후에 추가 예정)

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

 

DBC 구현 => 단정문

사고가 발생했다면 사고가 난 지점에서 일찍 멈추는 것이 문제를 찾고 원인을 밝히는데 유리하다. (의미없는 결과값 X)

죽은 프로그램이 끼치는 피해는 이상한 상태의 프로그램이 끼치는 피해보다 훨씬 적은 법이다.

단, 디버깅행위가 디버깅 하려는 시스템의 행동을 바꾸지 않도록 주의해야한다.

테스트되고 배포된 상태여도 단정 기능을 켜두는 것이 이익이다.

 

리소스 사용의 균형

자신이 시작한 것은 자신이 끝내라 (리소스를 할당하는 함수나 객체가 리소스를 해제하는 책임 역시 져야한다)

지역적으로 행동하라. (잘 모르겠다면 스코프를 줄여라)

 

- 중첩 할당

1. 리소스를 할당한 순서의 역순으로 해제하라. => 한 리소스가 다른 리소스를 참조하는 경우에도 참조를 망가트리지 않는다.

2. 코드의 여러 곳에서 동일한 구성의 리소스들을 할당하는 경우에는 언제나 같은 순서로 할당해야 교착(Deadlock)가능성을 줄일 수 있다. => (ProcessA = resource1 O / resource2 X ), (ProcessB = resource1 X / resource2 O )

 

헤드라이트를 앞서가지 말라

소프트웨어 개발에서도 헤드라이트(예상 범위)는 제한되어있다. 따라서 언제나 작은 단계들을 밟아라.

너무 큰 작업 (예언이 필요한 작업)을 하지 말고 미래에 대비하기위해선 언제나 교체 가능한 코드를 작성하라.

블랙스완 - 예언하지 말라. (Motif VS OpenLook => Web)

오늘 읽은 소감 / 떠오르는 생각

오늘은 분량은 짧았지만 고려해보지 않은 부분에 대한 팁들이 많아서 어려웠던것 같다. assert 기능을 좀더 적극적으로 사용하고, 168페이지의 코드 내용처럼 놓치는 리소스없이 효율적으로 코드를 구성해야겠다.

궁금한 내용

클래스 불변식 개념을 아직 이해하지 못했다. 개별적으로 좀더 알아보는 시간이 필요하다!