4장. 실용주의 편집증

이 글은 "실용주의 프로그래머" 도서를 읽고 내용과 느낌을 정리한 글입니다 :)

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

- 이것을 기정 사실로 받아들이지 않는다면, 불가능한 꿈을 뒤쫓으며 시간과 노력을 낭비하게 될 것이다.

- 이 암울한 현실을 어떻게 장점으로 바꿀 수 있는가가 본 장의 주제다.

- 우리는 다른 사람의 코드와 접촉하고, 적절하거나 혹은 그렇지 못한 입력을 받는다. 그래서 방어적으로 코딩하도록 가르침 받았다.

- 실용주의 프로그래머들은 자기 자신 역시 믿지 않는다. 따라서 그들은 '계약에 의한 설계'를 이용한다.

계약에 의한 설계

- 프로그램의 정확성을 보장하기 위해 모듈들의 권리와 책임을 문서화하고 검증하는 것이 DBC(계약에 의한 설계: Design By Contract)의 핵심이다.

- 선행조건(precondition) : 루틴이 호출되기 위해 참이어야 하는 것.

- 후행조건(postcondition) : 루틴이 자기가 할 것이라고 보자하는 것.

- 클래스 불변식(class invariant) : 호출자 입장에서 볼 때는 이 조건이 언제나 참이라고 클래스가 보장한다.

- 서브클래스는 사용자가 차이점을 모르고서도 기반 클래스 인터페이스를 통해 사용할 수 있어야 한다.

DBC

- 요구사항과 보증의 문제를 전면으로 내세운다. (입력 도메인의 범위가 무엇인지, 경계 조건이 무엇인지, 루틴이 뭘 전달한다고 약속하는지, 무엇을 전달한다고 약속하지 않는지)

- 이런 것들을 명시하지 않으면 우연에 맡기는 프로그래밍으로 돌아가게 될 것이다.

- 오류 발생시 소비자의 입장을 우선하라.

단정적 프로그래밍

- 단정문(assert)을 사용해서 불가능한 상황을 예방하라.

언제 예외를 사용할까

- 프로그래밍 언어에서 예외를 지원한다면, if else로 덕지덕지 된 코드를 깔끔하게 하나의 try catch문으로 잡아서 흐름을 명확하게 할 수 있다.

- 예외는 예외적인 문제에 사용하라.

시작한 것은 끝내라

- 리소스를 할당하는 루틴이나 객체가 리소스를 해제하는 책임 역시 져야한다.

- 리소스를 할당한 순서의 반대로 해제하라. 이렇게 해야 한 리소스가 다른 리소스를 참조하는 경우에도 리소스를 고아로 만들지 않는다.

- 여러 곳에서 동일한 리소스 집합을 할당하는 경우, 할당 순서를 언제나 같게 하라. 이렇게 해야 교찰(deadlock) 가능성이 줄어들 것이다.

- 최상위 구조 자신이 자기 안에 들어있는 하위 구조들의 할당을 해제할 책임이 있다.

- 최상위 구조에서 그냥 할당이 해제된다. 최상위 구조는 하나라도 하위 구조를 가지고 있을 경우 자기의 할당 해제를 거부한다.

- 정말 리소스가 적절하게 해제되었는지 점검하는 코드를 작성하라. 리소스의 할당과 해제를 기록해두어라.