오늘 TIL 3줄 요약

• 완벽한 코드를 작성할 수 없기에 방어적으로 코드를 짠다.

• DBC, 프로그램의 정확성을 보장하기 위한 계약에 의한 설계.

• 계획된 리소스의 할당과 해제, 시작한 것을 끝내라.

TIL (Today I Learned) 날짜

2022.03.23-2022.03.24

오늘 읽은 범위

4장. 실용주의 편집증

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

• 계약에 의한 설계

  • DBC(Design By Contract) → 계약에 의한 설계 개념

  • 프로그램의 정확성을 보장하기 위해 소프트웨어 모듈들의 권리와 책임을 문서화.

  • 선행조건: 루틴의 선행조건이 위반된 경우에는 루틴이 호출되어서는 안된다.

  • 후행조건: 루틴이 완료되었을 때 상태. 무한반복은 허용되지 않는다.

  • 클래스 불변식: 호출자의 입장에서 이 조건이 언제나 참이라고 클래스가 보장한다.

  • 게으른 코드, 시작하기 전에 자신이 수용할 것에 대해서는 엄격하고 내어줄 것에 대해서는 최소한도를 약속하는 것.

    
    

• 단정적 프로그래밍

  • “이런 일은 절대 일어날 리 없어” 이런 류의 자기기만은 하지 말자.

  • 단정문을 사용해서 불가능한 상황을 예방하라.

  • 실행되어야만 하는 코드는 절대 assert 속에 두지 마라.

  • 단정은 코드에 과부하를 준다. ... 단정은 디버깅 도구일 뿐이다.
    

• 언제 예외를 사용할까

  • 예외가 있다는 것은 즉 컨트롤의 이동이 즉각적이고 로컬하지 않다는 것.

  • 예외를 정상적인 처리 과정의 일부로 사용하는 프로그램은 고전적인 스파게티 코드의 가독성 문제와 관리성 문제를 전부 떠안게 된다. → 캡슐화를 깨뜨림.

  • 에러 처리기는 또 다른 대안이다. 에러 처리기는 에러가 감지되었을 때 호출되는 루틴이다.
    

• 리소스 사용의 균형

  • 시작한 것을 끝내라.

  • 단순히 리소스를 할당하는 루틴이나 객체가 리소스를 해제하는 책임을 진다는 것을 의미.

  • 즉, 리소스를 할당하는 루틴이 해제 역시 책임져야 한다는 것.
    

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

프로그래밍을 하다가 특정 예외가 발생할 상황을 고려해 임시코드를 코드와 함께 빌드를 했었다. (아마 아직도 그대로 내장?되어 있을 것 같지만) 주석처리된 트레이스와 함께. 아무도 제동을 걸지도 않았지만 이 책을 접했었더라면 하는 아쉬움이 남는다. 완벽한 소프트웨어를 만들 수 없다. 마음 아프지만 그래서 계약에 의한 프로그래밍이 더욱 더 빛을 발할 수 있는게 아닌가.

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

• 예외적인 상황, 무엇이 예외적인지.. 책에서 말하는 ‘경우에 따라 다르다'의 예가 잘 이해되지 않았다.

  
  

오늘 읽은 다른사람의 TIL

• https://ilpyoyang.tistory.com/218
  

  → 매일 다른 분들의 TIL를 읽으면서 발견하는 재미가 쏠쏠하다. 블로그에 정리가 잘 되어있고 이해되지 않은 내용에 DBC에 대한 흥미있는 의문점이 있어서 도움이 되었다. 😀