4장. 실용주의 편집증

오늘 TIL 3줄 요약

• 불가능 한 것은 없다. ”~~ 하는 일은 없을 텐데”라는 식으로 자신을 기만하지 말고 단정문으로 불가능한 상황을 예방하라.

• 가능한 시스템을 빨리 멈춰라

• 시작한 것에서 끝을 보아라.(리소스 할당과 해제)

TIL (Today I Learned) 날짜

2022/03/24

오늘 읽은 범위

4장. 실용주의 편집증

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

• 계약으로 설계하라.
  • 선행 조건: 루틴이 호출되기 위해 참이어야 하는 것. 선행 조건이 위반된 경우에는 루틴이 호출되어서는 안 된다.
  • 후행 조건: 루틴이 자기가 할 것이라고 보장하는 것.
• 문제를 찾고 원인을 밝히기 위해서는 사고가 난 지점에서 일찍 멈추는 것이 유리하다.
• 오류 발생 시 소비자의 입장을 우선하라.
• 모든 예외를 catch나 rescue로 잡은 후 로그 메시지를 좀 찍은 다음 다시 예외를 발생시키는 것은 좋지 않은 방식이다. 이렇게 작성하지 않는 이유는 첫째, 애플리케이션 코드가 오류 처리 코드 사이에 묻히지 않는다. 더 중요한 두 번째 이유는 코드의 결합도를 높이지 않는다는 점이다.
• 일찍 작동을 멈춰라. 얼랭을 만든 조 암스트롱은 이런 말을 자주 했다고 한다. “방어적 프로그래밍은 시간 낭비다. 그냥 멈추는 게 낫다!”
• 단정문으로 불가능한 상황을 예방하라.
• 자신이 시작한 것은 자신이 끝내라.
• 지역적으로 행동하라.
• 작은 단계들을 밟아라. 언제나.
• 예언하지 말라. 볼 수 있는 미래까지만 고려해야한다. 미래가 어떤 모습일지 더 많이 예측하려 할수록 여러분이 틀릴 가능성은 계속 높아질 것이다.

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

• DBC와 테스트 주도 개발, 방어적 프로그래밍의 차이를 정확히 모르겠다.
• 연습 문제 16번에서 나는 6가지의 케이스 중에서 2가지만 실제로 일어날 수 있다고 생각했지만, 답 예시를 보고는 “그런 일은 절대 일어날 리 없어”가 바로 떠올랐다. 자신을 기만하지 말자.
• 리소스 사용의 균형 파트의 코드 리팩토링 과정을 보면서 처음에는 그냥 문제가 없어 보였지만 설명을 읽으면서 문제를 확인할 수 있었다. 그리고 리팩토링이 끝났을 때 “오~“하며 감탄이 나왔다.