실용주의 프로그래머 - 5 (TIL)
범위
~4장 실용주의 편집증
내용
요약
- 완벽한 소프트웨어를 만들 수 없다!
- 단정적 프로그램
4장. 실용주의 편집증
여러분은 완벽한 소프트웨어를 만들 수 없다.
실용주의 프로그래머는 자기 자신 역시 믿지 않는다.
계약에 의한 설계
소프트웨어 모듈이 서로 소통하는 것을 돕기 위해 계약에 의한 설계를 사용
DBC
Degine By Contract(계약의 의한 설계)
- 선행조건
- 후행조건
- 클래스 불변식
만약 호출자가 루틴의 모든 선행 조건을 충족한다면, 해당 루틴은 종료 시 모든 후행 조건과 불변식이 참이 되는 것을 보장한다.
계약에 부응하지 못하는 것은 버그라는 것
계약으로 설계하라
클래스 불변식과 함수형 언어
함수형 언어는 input값이 바뀌지 않으므로 불변식 개념을 잘 이행하였음
DBC 구현
- 입력법위
- 경계조건
- 전달 약속
죽은 프로그램은 거짓말을 하지 않는다
방어적 프로그램
swtich() {
default: // 있을 수 없는 일이 생길 때 그 사실을 알 필요가 있음
}
잡은 후 그냥 놓아주는 것은 물고기뿐
예상치 못한 예외는 발생시켜 인지 후 개선한다.
망치지 말고 멈춰라
핸들링 할 수 없다면, 프로그램을 멈춰라
erlang은 그냥 프로그램이 죽어버림
단정적 프로그래밍
“그런 일은 절대 일어날 리 없어”라는 말로 자신을 기만하지마라
단정문으로 불가능한 상황을 예방하라
일어날 수 없는 상황을 일부로 만들어서 테스트하라
단정과 부작용
하지만 디버깅을 디버깅 해서는 안됀다.
단정 기능을 켜둬라
- 테스트가 모든 버그를 발견할 수 없다는 것은 인정
- 낙관주의자들은 프로그램이 험한 세상에서 돌아간다는 사실을 잊는다.
확인가능한 테스트를 맞췄을경우에는 어느정도 인정하자.
리소스 사용의 균형
- 메모리
- 트랜잭션
- 스레드
- 네트워크
- 연결
- 파일
- 타이머
자신이 시작한 것은 끝내라
리소스를 할당하는 함수나 객체가 리소스를 해제하는 책임 역시 져야 됌.
지역적으로 행동하라
중첩할당
- 리소스를 할당한 순서의 역순으로 해제하라. 이렇게 해야 한 리소스가 다른 리소스를 참조하는 경우에도 참조를 망가트리지 않는다.
- 코드의 여러 곳에서 동일한 구성의 리소스들을 할당하는 경우에는 언제나 같은 순서로 할당해야 교착 가능성을 줄일 수 있다.
객체와 예외
- 생성자 소멸자
균형잡기와 예외
나쁜 예외 처리 방식
// 할당 후 확인 까지 필요하다
int *a = new int
if (!a)
toDo check
리소스 사용의 균형을 잡을 수 없는 경우
동적인 자료구조를 사용하는 프로그램에서는 균형을 잡을 수 없는데 다음과 같이 처리할 수 있다.
- 최상위 구조가 자기 안에 들어 있는 하위 구조들을 해체할 책임을 진다
- 최상위 구조가 그냥 할당 해제된다.
- 최상위 구조가 하나라도 하위 구조를 가지고 있으면 자신의 할당 해제를 거부한다
균형을 점검하기
리소스 종류 별로 래퍼wrapper를 만들고 기록을 보관한다.
Memory Leaks 검사 도구: valgrind
헤드라이트를 앞서가지 말라
작은 단계들을 밟아라. 언제나.
마치며
시작하는 문구가 아주 마음에 들었다. 개발자로써 실수하여 장애가 나면 문제가 되는것은 맞다. 하지만 앞 장에서 나왔듯이 문제보단 해결책을 가져오는게 맞다. 신입때는 회사에 장애가 발생하였으면 온갖 죄책감에 압박에 아주 숨 쉬기가 어려웠었다. 하지만 어느 순간에 “모든 프로그램에는 버그가 있다”라는 생각을 인지하고 나니 그 때부터는 죄책감보다는 해결책을 찾아보려했었다. 잊지말자! 모든 프로그램에는 버그가 있다! 우리가 찬양하는 애플이나 마이크로소프트등 개발은 건축이 아니기에 기능이 추가 될 때마다 모르는 버그가 생길 수도 있는것이다.
이 책에서는 그걸 피하기 위해 방법을 제시한다. 단정적 프로그래밍 이라는 개념을 가지게 되는데, protobuf를 사용하여 우리는 들어오는 값들을 정의하고, 또한 validator를 사용하여 protobuf상에서 이미 입력값에 대해 명시할 수 있다.
그 외 메모리 할당과 관련해서도 좋은 내용이였다.
댓글남기기