[TIL] 4장 실용주의 편집증

4장 실용주의 편집증

1. 책에서 기억하고 싶은 내용

여러분은 완벽한 소프트웨어를 만들 수 없다.
이 말에 상처받았는가? 그러면 안 된다. 삶의 공리로 인정하고 받아들여라. 그리고 축하하라.
완벽한 소프트웨어는 존재하지 않기 때문이다. -145p
실용주의 프로그래머는 방어적인 코딩에서 한 걸음 더 나아간다. 실용주의 프로그래머는 자기 자신 역시 믿지 않는다.
어느 누구도, 심지어는 자기 자신도 완벽한 코드를 작성할 수 없음을 알기 때문에 실용주의 프로그래머는 자신의 실수에 대비한 방어책을 마련한다. -146p

[23. 계약에 의한 설계]
정직한 거래를 보장하는 최선의 해법 중 하나는 '계약'이다. 소프트웨어 모듈이 서로 소통하는 것을 돕기 위해 계약과 동일한 개념을 사용할 수 있다. -147p
DBC(Design By Contract) : 단순하지만 강력한 기법으로, 프로그램의 정확성을 보장하기 위해 소프트웨어 모듈의 권리와 책임을 문서화하고 합의하는 데에 초점을 맞춘다.
정확한 프로그램이란? : 자신이 하는 일이라고 주장하는 것보다 많지도 적지도 않게 딱 그만큼만 하는 프로그램.
이 내용들을 문서화하고 검증하는 것이 '계약에 의한 설계'의 핵심이다.
  1) 선행조건 : 루틴의 요구사항.
  2) 후행조건 : 루틴이 완료되었을 때의 상태, 루틴은 언젠가 종료됨을 의미.
  3) 클래스 불변식

[24. 죽은 프로그램은 거짓말을 하지 않는다]
문제의 코드는 정상적인 상황에서는 실패하지 않았을 것이다. 하지만 우리는 지금 방어적으로 코딩하고 있다. 데이터가 우리가 생각하는대로인지, 서비스에서 작동하는 코드가 우리가 생각하는 그 코드인지 확인해야 한다. 필요한 라이브러리들이 올바른 버전으로 실제로 로드됐는지도 확인해야 한다.
모든 오류는 정보를 준다. -159p
망치지 말고 멈춰라. 방금 있을 수 없는 일이 발생했다는 것을 코드가 발견했다면 프로그램은 더는 유효하지 않다고 할 수 있다. 이 시점 이후로 하는 일은 모두 수상쩍은 게 된다. 되도록 빨리 종료할 일이다. -161p

[25. 단정적 프로그래밍]
그런 일은 절대 일어날 리 없어. 이런식으로 자신을 기만하지 말자, 특히 코딩할 때는.
이런 생각들이 든다면 그런 일을 확인하는 코드를 추가하라 : 단정문(assertion)을 사용하는 것이다. 매개변수나 결과가 절대 null이어서는 안 된다면 명시적으로 검사하라.
하지만 진짜 오류 처리를 해야 하는 곳에 단정을 대신 사용하지는 말라. 단정은 결코 일어나면 안 되는 것들을 검사한다. -163p
우리의 첫 번째 방어선은 가능한 오류를 모두 검사하는 것이고, 그 다음은 그러고도 놓친 것을 잡아내기 위해 단정을 사용하는 것이다. 프로그램을 출시 할 때 단정 기능을 꺼 버리는 것은 줄타기 곡예를 하면서 연습으로 한 번 건너 봤다고 그물 없이 건너는 것과 비슷하다. -165p

[26. 리소스 사용의 균형]
자신이 시작한 것은 자신이 끝내라, 이상적으로 말해서 리소스를 할당하는 루틴이 해제 또한 책임져야 한다는 것이다, -169p
지역적으로 행동하라.

[27. 헤드라이트를 앞서가지 말라]
우리는 너무 먼 미래는 내다볼 수 없고, 정면에서 벗어난 곳일수록 더 어둡다. 
작은 단계들을 밟아라. 언제나. 더 닞행하기 전에 피드백을 확인하고 조정하라. 피드백의 빈도를 여러분의 제한 속도라고 생각하라.
피드백 : 여러분의 행동을 독립적으로 확증하거나 반증하는 것이라면 모두 피드백이다. -178p
예언하지 말라. 대부분의 경우 내일은 오늘과 거의 같을 것이다. 하지만 확신하지는 말라. -180p

2. 궁금한 내용 과 잘 이해되지 않은 내용에 대한 정리

@DBC 구현