<aside> 🔑 오늘 TIL 3줄 요약

</aside>

• 예언하지 말고, 나 자신을 믿지 않는것이 안전한 프로그래밍이다.
• 안전을 위해서는 적절한 기술들이 많이 있다. 이를 적극적으로 활용하자.
• 완벽한 프로그램은 없지만, 완벽하게 하는 방법은 존재한다.

TIL (Today I Learned) 날짜

2022. 3. 23

오늘 읽은 범위

~4장. 실용주의 편집증

<aside> 📝 책에서 기억하고 싶은 내용

</aside>

서문

<aside> ⛔ 여러분은 완벽한 소프트웨어를 만들 수 없다.

</aside>

• 불안전한 시스템, 어림도 없는 기간, 우스꽝스러운 도구, 불가능한 요구 사항으로 가득 찬 세상에서 안전하게 살아 보자. ( 책 도입 부터 강렬한 문구가 반긴다... )

계약에 의한 설계

• 왜 필요한가?

  • 자기 자신도 완벽한 코드를 작성할 수 없음을 알기 때문에 실수에 대한 방어책 마련! ( p146 )

• 계약 ( constract ) : 문서화하고 검증하는 것이 ‘계약에 의한 설계’의 핵심이다. ( p148 )

  • 선행 조건 → 루틴의 요구 사항이다. 제대로 된 데이터를 전달하는것은 호출하는 쪽의 책임

  • 후행조건 → 무한 반복은 허용되지 않는다.

  • 클래스 불변식 → 언제나 참인 것을 클래스가 보장한다.

    진짜 의미는 상태state이다. 객체지향이라 클래스이지, 함수에서는 상태가 적용된다. 부연 설명 ( p151 )

• 어떻게 하느냐? ( p149 ~ p150 )

  • 클로저$\scriptstyle Clojure$ 에서는 ‘스펙$\scriptstyle spec$’ 이라는 라이브러리를 사용
  • 다른 언어에서도 DBC용 아닌걸로 사용할 수있음! ( 이부분은 추가 조사 필요할듯.. )

• DBC( Designed By Contract ) 구현하기 ( p153 )

  • 코드 작성전

    • [ ] 유효한 입력 범위가 무엇인지
    • [ ] 경계 조건이 무엇인지,
    • [ ] 루틴이 뭘 전달하라고 약속하는지 or 더 중요하게는 무엇을 약속하지 않는지

    를 나열해 보자.

  • 자동 검사가 없어도 주석이나 단위 테스트로 넣어 둘 수 있음!