Community

개발자 99% 커뮤니티에서 수다 떨어요!

← Go back
[DAY6] 4장 실용주의 편집증
#pragmatic
2년 전
584

오늘 TIL 3줄 요약

  • 모든 소프트웨어엔 버그가 있다. 믿지 말고 제약하자.

  • 여러군데를 오염시키는 것보다 일찍 실패하는 게 낫다.

  • 리소스를 할당한 함수나 객체에게 리소스를 해제할 책임 역시 있다.

TIL (Today I Learned) 날짜

2022. 03.24

오늘 읽은 범위

4장. 실용주의 편집증

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

계약에 의한 설계 DBC

  • 선행 조건 : 루틴이 호출되기 위해 참이어야 하는 것. 즉, 루틴의 요구 사항

  • 후행 조건 : 루틴이 자기가 할 것이라고 보장하는 것.

  • 클래스 불변식 : 호출자의 입장에서 볼 때, 이 조건이 언제나 참인 것을 클래스가 보장한다.

코드를 작성하기 전에 유효한 입력 범위가 무엇인지, 경계 조건이 무엇인지, 루틴이 뭘 전달한다고 약속하는지, 혹은 더 중요하게는 무엇을 약속하지 않는지 등을 나열하는 것만으로 더 나은 소프트웨어를 작성하는 데에 엄청난 도움이 된다.

죽은 프로그램은 거짓말 하지 않는다

모든 오류는 정보를 준다. 오류를 애써 무시하고 싶을 수도 있다. 하지만 오류 메시지가 있다면, 오류가 발생했다는 뜻이다. 제발 읽고 대응해라.

리소스 사용의 균형

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

잘 모르겠을 땐 언제나 스코프를 줄이는 편이 낫다.

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

작은 단계들을 밟아라. 언제나.

언제나 신중하게 작은 단계들을 밟아라. 더 진행하기 전에 피드백을 확인하고 조정하라. 피드백의 빈도를 여러분의 제한 속도라고 생각하라.

미래가 어떤 모습일지 더 많이 예측하려 할수록 여러분이 틀릴 가능성은 계속 높아질 것이다. 불확실한 미래에 대비한 설계를 하느라 진을 빼는 대신 언제나 교체 가능한 코드를 작성하여 대비하면 된다. 여러분의 코드를 더 적절한 무언가로 대체하기 쉽게 설계하라.

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

예외 상황은 "설마 이런 것 까지 발생하겠어", 오류는 "흠 별일 아닐거야" 하고 넘어가고 싶은 마음.

이런 마음을 버리고 명시적으로 확인하고, 오류가 발생하는 근본적인 원인을 찾아내려는 노력을 해봐야겠다.