[실용주의 프로그래머] 스터디 6주차_4강 실용주의 편집증

p 145~180

 

Topic 23. 계약에 의한 설계 (DesignBy Contract,DBC)

• 모든 입력값에 성공과 실패를 정의한다.
• 문제를 찾고 원인을 밝히기 위해서는 사고가 난 지점에서 멈추는 것이 유리
• 의미론적 불변식, 어겨서는 안되는 요구사항을 표현

 

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

• 방어적 프로그래밍은 시간 낭비, 코드가 망가지면 그냥 멈추는게 낫다.
• 죽은 프로그램이 끼치는 피해가 이상한 상태의 프로그램이 끼치는 피해보다 훨씬 적다.

 

Topic 25. 단정적 프로그래밍

• 단정문으로 절대 일어나지 않을것 같은 불가능한 상황을 예방해야한다.
• 진짜 오류처리를 해야하는 곳에 단정을 사용하지 않는다. 
• 단정을 잘못 사용하면 디버깅이 디버깅하는 시스템의 행동을 바꿔버리는 하이젠버그적인 문제가 생긴다.
• 첫번째 방어선은 가능한 오류를 모두 검사하는 것, 그 외에도 놓친것을 잡아낼때 단정을 사용한다.

 

Topic 26. 리소스 사용의 균형

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

 

*연습 문제 17

일부 C나 C++ 개발자들은 어떤 포인터가 가리키는 메모리를 해제한 다음에는 반드시 그 포인터 값을 NULL로 설정한다. 왜 이것이 좋은 생각일까?

대부분의 C나 C++ 구현에서는 어떤 포인터가 정말로 유효한 메모리를 가리 키는지 확인할방볍이 없다. 어떤메모리 영역의 할당을해제한후나중에 프 로그램에서 그 메모리를 참조하는 실수가 자주 일어난다. 그때좀이면 포인 터가 가리키는 메모리는 다른 용도로 다시 할당되었을 수도 있다. 포인터 에 NULL을 지정하여 이런 잘못된 참조를 막으려는 것이다. 대부분의 구현에서 NULL 포인터를 참조하면 런타임 오류가 발생한다.

 

Topic 27. 헤드라이트를 앞서가지 말라

• 더 진행하기 전에 피드백을 확인하고 작은 단계를 밟아라.
• 단위테스트, 사용자 데모 및 사용자와의 대화로 피드백을 받아라
• 불확실한 미래를 설계하는 대신, 언제나 교체 가능한 코드를 작성하여 더 나은 설계를 하라

 

*Javascript memory 누수의 주요 원인

• 콘솔삭제
• 타이머 해제
• 클로저 사용안하는 변수 null 처리