오늘 TIL 3줄 요약

• 계약에 의한 설계를 생각하라

• 단정문으로 불가능한 상황을 예방하라

• 작은 단계를 밟아라 언제나

TIL (Today I Learned) 날짜

2022.05.19

오늘 읽은 범위

4장 실용주의 편집증

책에서 기억하고 싶은 내용을 써보세요.

여러분은 완벽한 소프트웨어를 만들 수 없다. 완벽한 소프트웨어는 존재하지 않기 때문이다. 그렇다면 실용주의 프로그래머는 이런 암울한 현실을 어떻게 자신의 장점으로 바꿀 수 있을까? 이것이 이번 장의 주제다.

계약에 의한 설계(Design By Contract, DBC)

DBC는 단순하지만 강력한 설계 기법으로, 프로그램의 정확성을 보장하기 위해 소프트웨어 모듈의 권리와 책임을 문서화하고 합의하는 데에 초점을 맞춘다. 정확한 프로그램이란 자신이 하는 일이라고 주장하는 것보다 많지도 적지도 않게 딱 그만큼만 하는 프로그램이다.

DBC를 개발한 버트런드 마이어는 소프트웨어 시스템의 모든 함수와 메서드는 뭔가를 한다고 표현하는데, 그 뭔가를 시작하기 전에 해당 함수는 세상의 상태에 대해 어떤 전제 조건을 갖고 있을 테고, 루틴이 끝난 후에는 세상의 상태가 어떠할 것이라고 선언할 수 있을것이다. 이런 전제와 선언을 다음과 같이 설명한다.

• 선행조건 precondition

  루틴이 호출되기 위해 참이어야 하는것. 루틴의 요구사항

• 후행조건 postcondition

  루틴이 자기가 할 것이라고 보장하는 것. 루틴의 완료되었을 때 세상의 상태

• 클래스 불변식 class invariant

  호출자의 입장에서 볼 때는 이 조건이 언제나 참인 것을 클래스가 보장한다. 루틴이 끝나고 호출자로 제어권이 반환되는 시점에는 불변식이 참이 되어야 한다.

여기서 루틴과 그 루틴을 호출하려는 코드 간의 계약은 다음과 같다.

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

이런 개념을 잘 지원하는 언어들이 있다. 예를 들어 클로저는 라이브러리에 기반하여 선행 및 후행 조건뿐 아니라 더 포괄적인 도구를 제공한다. 함수형 언어의 경우도 이런 개념은 똑같이 유용하다.

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

• 가능한 한 빨리 문제를 발견하면 좀 더 일찍 시스템을 멈출 수 있으니 망치지 말고 멈춰라

  어떤 환경에서는 실행 중인 프로그램을 그냥 종료해 버리는 것이 적절치 못할 수도 있다. 그렇지만 기본 원칙은 똑같다.

단정적 프로그래밍

단정문(assertion)으로 불가능한 상황을 예방하라. 대부분의 언어 구현에서 조건이 참인지 거젓인지 확인하는 assert의 일종을 찾을 수 있을 것이다. 매개 변수나 결과가 절대 null이어서는 안 된다면 명시적으로 검사하라. 하지만 진짜 오류를 처리해야 하는 곳에 단정을 대신 사용하지는 말라. 단정은 결코 일어나면 안되는 것들을 검사한다.

리소스 사용의 균형

우리는 코딩할 때 언제나 리소스를 관리한다. 메모리, 트랜잭션, 스레드, 네트워크 연결, 파일, 타이머 등 무한히 사용할 수 없는 모든 종류의 것을 관리한다. 그렇지만 많은 개발자가 리소스 할당과 해제를 다루는 일관된 방침을 갖고 있지 않다.

• 자신이 시작한 것은 자신이 끝내라

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

• 리소스를 할당한 순서의 역순으로 해제하라

• 코드의 여러 곳에서 동일한 구성의 리소스들을 할당하는 경우에는 언제나 같은 순서로 할당해야 데드락 가능성을 줄일 수 있다

• 객체지향 언어로 프로그램잉을 한다면 리소스를 클래스 안에 캡슐화하는 것이 유용할 수 있다

• 예외를 지원하는 언어에서 리소스 해제가 골치 아플 수 있다

  • 변수 스코프를 사용한다. 예를 들어 C++나 Rust의 스택 변수가 있다.

  • try~catch 블록에서 finally절을 사용한다

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

헤드라이트는 ‘투사 거리'라고 부르는 범위까지만 밝힐 수 있다. 이 범위 바깥은 빛이 너무 분산되어 효과가 떨어진다. 또한 헤드라이트는 일직선 모양의 영역을 비추므로 커브나 언덕, 웅덩이처럼 정면을 벗어난 것은 밝히지 못할 수 있다. 마찬가지로 소프트웨어 개발에서도 우리의 ‘헤드라이트'는 제한되어 있다.

• 작은 단계들을 밟아라. 언제나

  언제나 신중하게 작은 단계들을 밟아라. 더 진행하기 전에 피드백을 확인하고 조정하라.

• 예언하지 말라

  너무 큰 작업은 ‘예언'을 해야하는 모든 작업인데, 경험에 기반한 추측을 벗어난 무모한 억측의 영역은 피해야 한다. 여러분이 볼 수 있는 미래까지만 고려해라. 여러분은 코드를 더 적절한 무언가로 대체하기 쉽게 설계함으로 대비하면 된다.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

모두가 교통법규를 완벽히 지키는건 아니기에 운전자는 늘 방어운전을 생각한다. 예외라는건 어떤 상황에나 존재하기에 우리는 우리가 짠 코드에도 방어코드를 짜야한다. 하지만 그 방어코드마저 완벽하지 않다.

이런 부분은 경험으로 계속 쌓아가야하는 부분이지 않을까 싶은 생각이 든다. 미래를 알 수 없기에, 최선을 다해 대체하기 쉽게 함수를 쪼개고, 중복을 없애고, 의존성을 낮추고..하나씩 해보면서 쌓아가야겠다.

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

이번 챕터는 집중이 잘 되지 않아서 몇번이고 되돌아 읽었던것 같다. 왜지..

오늘 읽은 다른사람의 TIL