- 2022.05.19. 목
- 4장. 실용주의 편집증
- 완벽한 프로그램을 만들 수는 없다. 그렇다고 해서 프로그램을 완벽하게 만들기 위한 노력을 게을리 해선 안된다.
- 좀 더 믿을만한 프로그램을 만들기 위해, 소프트웨어 모듈에 대한 제약을 문서화하거나, 참이어야만 하는 값에 단정문을 추가하여 값을 보장하거나, 예외를 처리하는 코드를 추가해 발생하는 예외나 에러를 적절히 처리할 수도 있다.
- 자기 자신을 의심하며 방어적으로 코드를 작성해야 한다.
21. 계약에 의한 설계
소프트웨어 모듈의 소통을 돕기 위해, 계약에 의한 설계를 도입하여 각 모듈의 권리와 책임을 문서화할 수 있다. 여기서 문서화하는 내용에는 루틴의 선행, 후행조건과 루틴을 통해 보장되는 것(클래스 불변식)이 포함된다. 이런 계약은 컴파일러가 대신 검사하게 해서 더 큰 이익을 얻을 수 있다.
클래스 불변식은 루틴 실행 여부와 상관 없이 언제든 그 조건이 참이지만, 후행 조건은 루틴을 실행한 다음에만 참이 되는 상태이다.
‘책을 한 페이지 읽는다’ 라는 루틴이 있을 때, (읽은 페이지를 또 읽지는 않는다고 가정하자..)
- 선행 조건: 남은 페이지 수가 1 이상이다
- 후행 조건: 읽은 페이지 수가 1 더해진다
- 클래스 불변식
- 읽은 페이지 수는 책의 총 페이지 수를 넘지 않는다
- 읽은 페이지 수는 0 이상이다
읽은 페이지 수 + 남은 페이지 수 == 총 페이지 수이다
이러한 불변식은 의미론적인 것이어야 하지, 동적인 비즈니스 정책에 영향을 받으면 안된다.
호출자가 루틴의 모든 선행조건을 만족한다면, 해당 루틴은 종료시 모든 후행조건과 불변식이 참이 될 것을 보증해야 한다. p186
여기서 강조할 것은 게으른 코드다. 시작하기 전에 수용할 것에 대해서는 엄격하게 하고, 내어줄 것에 대해서는 최소한도를 약속하는 것이다. p187
22. 죽은 프로그램은 거짓말을 하지 않는다
문제의 코드는 정상 조건 하에서는 실패하지 않았을 것이다. 하지만 우리는 지금 방어적으로 코딩하고 있다. p199
방금 불가능한 뭔가가 발생했다는 것을 코드가 발견한다면, 프로그램은 더 이상 유효하지 않다고 할 수 있다. 이 시점 이후로 하는 일은 모두 수상쩍은 게 된다. p201
23. 단정적 프로그래밍
“하지만 물론 그건 절대 일어나지 않을 거야”라는 생각이 든다면, 그걸 확인하는 코드를 추가하라. 이걸 하는 가장 간단한 방법은 단정문(assertion)을 사용하는 것이다. p202
단정문에 전달된 조건은 부작용이 있으면 안된다. 단정문에는 실행해야 하는 코드는 전달하면 안된다. 단정은 결코 일어나면 안되는 것을 대상으로 검사한다. if 문이나 에러처리 대용이 아니다.
24. 언제 예외를 사용할까
하지만 모든 것을 단정문으로 확인하면 코드가 지저분해지고, 성능 문제가 발생할 가능성도 있다. try-catch 등으로 예외를 한 곳에 모아 처리할 수 있다. 예외 처리는 정상적인 프로그램의 흐름으로 일부러 사용되어서는 안된다.
25. 리소스 사용의 균형
Tip 35. 시작한 것은 끝내라 p212
리소스를 할당했으면 그것을 해제하는 책임도 져야 한다. 리소스 할당을 해야 한다면, 이에 대한 책임을 한 루틴에 모아서 그 루틴이 할당과 해제에 대한 책임을 모두 지는 것이 안전하다.
- 할당한 순서의 반대로 해제한다. 그렇지 않으면, 나중에 할당된 리소스가 먼저 할당된 것을 참조하는 경우에 먼저 할당된 것이 이미 해제되어서 리소스를 찾지 못하는 상황이 생길 수도 있다.
- 동일한 리소스 집합을 여러 군데에서 할당한다면, 할당하는 순서를 통일해라. 데드락이 발생할 수도 있다.
