오늘 TIL 3줄 요약

• DBC (Design By Contract ) : 계약에 의한 설계

• 방어적으로 코딩하라

• 미래를 예측하지 말라

TIL (Today I Learned) 날짜

2022. 03. 24

오늘 읽은 범위

4장. 실용주의 편집증

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

• 여러분은 완벽한 소프트웨어를 만들 수 없다

• 방어적으로 코딩하라

  • 단정문(assertion)으로 불가능한 상황을 예방하라

    • 잘못된 데이터를 찾아내기 위해

    • Ex ) assertTrue(”계좌는 반드시 양수여야함”, false);

  • 계약에 의한 설계

  • 버그 상황에서 헤어나는 도중에 어떤 손상도 입히지 말아야한다.

  • 단정적 프로그래밍 : 가정을 적극적으로 검증하라

  • 리소스 사용의 균형

    • 자신이 시작한 것은 자신이 끝내라

    • 지역적으로 행동하라

  • 헤드라이트를 앞서가지 말라

    • 언제나 작은 단계들을 고수해야한다.

• DBC와 테스트 주도 개발

  • DBC

    • 테스트 환경 구성이나 모의 객체가 필요 없다.

    • 모든 입력 값에 대해 성공과 실패를 정의한다.

    • 설계, 개발, 배포, 유지 보수 전체에 걸쳐 사용된다.

    • 방어적 프로그래밍보다 더 효율적이고 더 DRY하다

  • TDD

    • 하나가 한가지 경우만 다룬다.

    • 빌드 과정 중 ‘테스트’ 할 때만 수행된다.

    • 테스트 중인 코드 내의 내부 불변식을 확인하는 것에 초점을 두지 않는다. 그보다 공개 인터페이스를 확인하는 블랙 박스 방식에 더 가깝다.

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

‘우리는 완벽한 소프트웨어를 만들 수 없다’

내가 만든 산출물에 대한 버그나 이슈를 만들지 않기 위하여 방어적으로 프로그래밍 해야하는 이유와 사례들에 대해서 알 수 있었다. 디버깅을 잘 하는 것이 정말 잘하는 프로그래머라고 하는데, 디버깅을 잘 하기 위하여 “단정적 프로그래밍”도 필요하다고 느꼈다. (실제 사용해보지는 않아서 생소한 개념이었다.)

미래의 요구사항이나 일정 , 확장 가능성을 미리 고려하여 앞서 나가지 말고 작은 단계들을 밟아라 라고 하였는데, 프로그래밍 개발 시 너무 많은 요구사항과 기능들을 담으려고하지 말아야겠다. 일단 단계적으로, 대신 나중에 변경이 용이하도록 (이 말은 참 어려운것 같다.) 개발도, 학습도 작은 단계별로 나아가자

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

우리가 볼 수 있는 미래까지만 고려해서 설계하라, 코드를 더 적절한 무언가로 대체하기 쉽게 설계하라. 어디까지 그리고 대체하기 쉬운 것의 범위는 어떻게 알 수 있을까,,, 경험이 많아지면 저절로 습득 되는 것일까