[실용주의 프로그래머] 4장. 실용주의 편집증
1 주차
목 | Assignment #06
4장. 실용주의 편집증
📘 책에서 기억하고 싶은 내용
- 완벽한 소프트웨어는 만들 수 없고, 이를 인정하자
- 실용주의 프로그래머는 자기 자신도 완벽한 코드를 작성할 수 없음을 알기 때문에 자신의 실수에 대한 방어책을 마련한다.
- 계약에 의한 설계 (p.147)
루틴과 호출자 코드 간의 계약
- 만약 호출자가 루틴의 모든 선행 조건을 충족한다면 해당 루틴은 종료 시 모든 후행 조건과 불변식이 참이되는 것을 보장한다.
- 어느 한 쪽이라도 계약 내용을 지키지 못할 경우 양측이 동의한 내용에 따라 해결 방안이 실행된다.
DBC(Design By Contract) : 프로그램의 정확성을 보장하기 위해 소프트웨어 모듈의 관리와 책임을 문서화하고 합의하는 데에 초점을 맞추며, 문서화하고 검증하는 것이 핵심
- 선행 조건 : 루틴 요구사항, 루틴이 호출되기 전에 참이어야 하는 것
- 후행 조건 : 루틴이 완료되었을 때의 상태, 루틴이 할 것이라고 보장하는 것
- 클래스 불변식 : 루틴 종료 후 불변속성 보장
- 게으름뱅이 코드 : 시작하기 전에 자신이 수용할 것은 엄격하게 확인하고, 내어 줄 것에 대해서는 최소한도를 약속하는 것
- 의미론적 불변식 : 어겨서는 안 되는 고정된 규칙인 요구 사항 표현 고정된 규칙과 변동 가능성이 큰 정책을 혼동하지 말아야 함
- TDD를 하고 있음에도 DBC는 필요하다.
- 코드 작성 전 유효 입력 범위, 경계 조건, 선후행 조건 등을 나열하는 것만으로도 구현에 도움이 되며, 결국 DBC는 설계 기법이다.
- 선행 조건은 명시적으로 검증해야 할 매개 변수가 하나라도 있다면 호출자에서 검증을 수행해야 한다.
- 죽은 프로그램은 거짓말을 하지 않는다 (p.158)
그런 일은 절대 일어날 리 없어. 라는 사고에 빠지기는 쉽다.- 모든 오류는 정보를 준다.
- 죽은 프로그램이 끼치는 피해는 이상한 상태의 프로그램이 끼치는 피해보다 훨씬 적다.
- 단정적 프로그래밍 (p.162)
- 진짜 오류 처리를 해야 하는 곳에 단정을 대신 사용하지 말라.
- 단정문에 대한 오해
- 성능 저하
- 버그가 있을 때만 단정 검사가 실패함
- 릴리즈 이후에는 더 이상 단정이 필요하지 않음
- 단정문은 디버깅 도구임
- 리소스 사용의 균형 (p.167)
- 자신이 시작한 것은 자신이 끝내라 (내가 자원을 사용하기 시작했음 내가 해제해야 함)
try-with-resouce 과 같은 구문을 사용할 수 있다명 해당 범위에서만 자원이 사용되도록 해야 한다.- 리소스를 할당한 순서의 역순으로 해제하라. (참조가 망가질 경우를 대비)
- 코드의 여러 곳에서 동일한 구성의 리소스들을 할당하는 경우에는 언제나 같은 순서로 할당해야 교착 가능성을 줄일 수 있다.
- 리소스를 할당하는 것이 언제나 그 리소스를 해제할 책임까지 져야 한다.
- 리소스를 클래스 안에 캡슐화 하는 것이 유리하다. (GC가 수행되며 리소스가 해제됨)
- 자료구조에서 최상위 구조의 메모리 할당 해제 방안
- 최상위 구조가 하위 구조들을 해제할 책임을 지고, 하위 구조가 다시 재귀적으로 해제할 책임을 짐
- 최상위 구조만 할당 해제, 최상위 구조가 참조하던 하위 구조들은 연결이 끊어져 다른 곳에서 참조하지 않으면 사용되지 않음
- 최상위 구조가 하나라도 하위 구조를 가지고 있으면 자신의 할당 해제를 거부함
- 헤드라이트를 앞서가지 말라 (p.177)
- 더 진행하기 전에 피드백을 확인하고 조정하라.
- 볼 수 있는 미래까지만 고려하라.
- 미래가 어떤 모습일지 더 많이 예측하려 할수록 틀릴 가능성은 계속 높아질 것이다.
🤔 소감 및 생각
DBC 는 처음 접해보는 개념이었는데 DBC 가 가지고 있는 철학이나 방법 같은 부분이 새로웠던 것 같다.- 여러 공부를 병행하려니 체력적으로 점점 뒷받침해주지 않는 것 같다.. 체력을 키워야겠다고 생각했다.
🔍 새롭게 또는 다시 알게 된 내용
- 불변속성 : 어떤 객체의 상태가 프로그래머의 의도에 맞게 잘 정의되어 있다고 판단할 수 있는 기준을 제공하는 속성
