실용주의 프로그래머 정리 4

실용주의 편집증

명심하자. 완벽한 소프트웨어는 만들 수 없다. 따라서 소프트웨어를 믿지 말자. 끊임없이 의심하고 방어 코드를 작성하자.(물론 적정선에서)

21. 계약에 의한 설계

계약에 의한 설계에서는 루틴, 함수, 메소드가 3가지를 지키며 동작하기를 기대한다.

• 선행조건: 함수가 정상적으로 동작하기 위한 조건이다.
• 후행조건: 함수가 실행된 이후 만족해야하는 상태(조건)을 의미한다.
• 클래스 불변식: 메소드 실행 전, 실행 후에는 특정 조건을 만족해야함을 의미한다.

계약에 의한 설계를 지원하는 아이펠같은 언어는 해당 조건을 기술해서 소프트웨어 안정성을 높인다.

개인적으로 자바에서 인터페이스가 계약이라고 생각한다. 실제로 계약에 의한 설계처럼 강한 조건 검사는 지원하지 않지만 인터페이스가 어떤 기능을 하고 어떻게 동작할 것인지에 대한 계약 역할을 한다고 생각한다. 이는 책임을 명확히 분리해주고 변경에 강한 코드를 작성하도록 도와준다. 리스코프 치환 원칙이 이를 잘 설명해준다.

책에서 말하는 계약에 의한 설계는 실무에서 사용하기에는 좀 거리가 있다고 느껴졌지만 일부분(인터페이스의 시그니처 처 정도)을 활용하면 좋은 코드를 작성할 수 있을 것이라고 생각한다.

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

코드에 문제가 있을때 프로그램을 죽이는 것이 차라리 낫다. 정합성이 깨지고 문제가 있는 상태에서 프로그램이 계속 돌아가면 더 큰 문제를 만들 수 있다. "있을수 없는 일이야"라고 추측하지 말고 항상 방어 코드를 만들자. 그리고 있을 수 없는 일이 생기면 프로그램을 종료 시키자.

23. 단정적 프로그래밍

죽은 프로그램은 거짓말을 하지 않는다에서 말한 것 처럼 "있을 수 없는 일"은 일어날 수 있다. 그리고 있을 수 없는 일이라고 가정하기 때문에 문제가 발생했을 때 더 찾기 힘들다. 이런 문제를 방지하려면 단정문을 사용하는 것이 좋다. 있을 수 없는 상태에 대해 단정문을 설정하고 프로그램을 종료시키자.

단정문을 사용할 때 주의해야할 점은 부수 효과를 일으키면 안된다는 것이다. 단정문이 부수 효과를 일으키면 더 찾기 힘든 오류를 만들 수 있다. 부수 효과 없이 단정문의 용도로만 단정문을 사용하라.

다음과 같은 단정문을 피하자. 엘리먼트를 가져오는 부수효과가 발생한다.

Test.ASSERT(iter.nextElement() != null);

24. 언제 예외를 사용할까

상황에 따라 예외를 적절히 사용하자. 다만 예외를 특정 정상 흐름의 일부로 사용하지 말자. 더 복잡한 로직을 만들게 될 것이다. 예외는 정말 예외 상황에만 사용하자.

예외 처리 로직을 따로 분리한 예외 처리기를 사용하는 것도 좋다. 일관된 예외 처리 로직으로 에러를 처리할 수 있다.

25. 리소스 사용의 균형

리소스를 할당한 주체가 리소스를 해제하도록 하자. 리소스 릭을 방지할 수 있고 버그를 줄일 수 있다. 또한 여러 리소스를 사용한다면 리소스를 할당한 순서의 반대로 해제하도록 하자. 리소스가 엉키는 일을 방지할 수 있다.

여러 곳에서 동일한 리소스 여러개를 할당하고 해제한다면 리소스 할당 순서를 일치시키자. 교착 상태를 방지할 수 있다. 자바에서 리소스 할당, 해제는 try-with 문을 사용하자. 사용할 수 없는 상황이라면 반드시 finally문에서 리소스를 해제하자.

리소스에 대한 레퍼런스 카운트를 관리해서 릭이 발생하는 리소스를 탐지하는 방법도 있다. 리소스를 안전하게 관리하고 싶으면 리소스 레퍼런스를 관리해서 점검하도록 하자.