실용주의 프로그래머 4장: 실용주의 편집증

3장 기본 도구

 

누구도 완벽한 프로그래머를 만들 수 없다는 현실을 어떻게 장점으로 바꿀 수 있을까? 에 대한 장

실용주의 프로그래머는 자신도 믿지 않기 때문에 실수에 대비한 방어책을 마련한다.

 

 

23. 계약에 의한 설계

 

 

소프트웨어 모듈에서도 "계약"이라는 방식을 사용할 수 있다.

 

DBC: Design By Contract

정확한 프로그램은 더 많지도, 적지도 않게 딱 그만큼만 하는 프로그램

 

선행 조건precondition: 루틴의 요구 사항, 위반되었을 경우에는 루틴을 호출하지 않는다.

후행 조건postcondition: 루틴이 완료되었을 때 세상의 상태. 루틴이 결국은 할 일을 한 후 종료될 것임을 보장한다.

클래스 불변식class invariant: 루틴이 끝난 시점에는 불변식이 참이 되어야 한다.

 

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

 

lazy code: 시작하기 전에 요구 사항을 엄격하게 확인하고, 내어 줄 것은 최소한도로 약속

 

cf) TDD는 멋진 기법이지만, 다른 많은 기법과 마찬가지로 "정상 경로"에만 집중하도록 요구한다. 그러나 세상은 나쁜 데이터와 버전, 사람, 명세로 가득하다.

 

코드를 작성하기 전에 유효한 입력 범위, 경계 조건 등을 작성하는 것은 소프트웨어 작성에 큰 도움이 된다.

DBC를 지원하지 않는 언어에서도 DBC는 설계 기법으로 작동한다. (대표적으로 Eiffel, Clojure 등은  DBC 지원)

 

의미론적 불변식: 경영진이 바뀌면 바뀌는 등의 단순한 정책과 혼동하면 안 된다. 

 

 

24. 죽은 프로그램은 거짓말을 하지 않는다

 

디폴트 구문을 다는 이유는 "있을 수 없는 일"이 발생했을 때 그 사실을 알 수 있어야 하기 때문이다.

죽은 프로그램이 끼치는 피해는 이상한 상태의 프로그램이 끼치는 피해보다 적은 경우가 많으니, 문제를 인식하면 되도록 빨리 종료시켜라.

 

 

25. 단정적 프로그래밍

 

"그런 일은 일어나지 않는다"라는 생각이 든다면 그런 일을 확인하는 코드를 추가하라.

assert 등의 단정문을 사용한다.

오류 처리를 해야 하는 곳에 단정문을 사용해서는 안 된다. 결코 일어나면 안 되는 것을 감시하자.

 

성능 문제 때문에 배포 후에 단정 기능을 끄는 것은 권장하지 않는다.

 

 

26. 리소스 사용의 균형

 

리소스를 사용하는 루틴이 해제 역시 책임져야 한다.

잘 모르겠을 땐 스코프를 줄이는 편이 낫다.

참조를 망가뜨리지 않으려면 리소스는 할당한 순서의 역순으로 해제해야 한다.

 

리소스가 정말로 해제되었는지 점검하는 코드를 작성해라

 

+ 연습 문제. C나 C++ 개발에서 포인터가 가리키는 메모리 해제 후에 포인터 값을 NULL로 설정하는 이유는? 

 → 포인터가 유효한 메모리를 가리키는지 확인하는 것이 어렵기 때문에, 메모리 할당 해제 후 나중에 그 메모리를 참조하는 경우가 있다. 다른 용도로 다시 할당된 메모리를 참조하는 것을 막기 위해, NULL 포인터를 참조하면 런타임 오류가 발생하는 원리를 이용한다.

 

 

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

 

작은 단계를 밟는 것이 중요하다

미래의 유지 보수를 고려하더라도, 볼 수 있는 미래까지만 고려해라.

더 많이 예측하려 할수록 틀릴 가능성도 높아진다.