개발자 99% 커뮤니티에서 수다 떨어요!
오늘 TIL 3줄 요약
계약에 명시된 사항을 정확히 지켜서 코드를 작성할 것.
앞서가지 말고 천천히 한 단계식 나아갈 것
코드들을 계속 의심할 것.
TIL (Today I Learned) 날짜
2022. 05. 19
오늘 읽은 범위
4장. 실용주의 편집증
책에서 기억하고 싶은 내용을 써보세요.
계약에 의한 설계(Design By Contact, DBC)
상식과 정직만큼 사람을 놀라게 하는 것은 없다. (p.147)
선행 조건 : 루틴의 요구 사항
후행 조건 : 루틴이 완료되었을 때의 상태.
클래스 불변식
계약으로 설계하라
DBC 구현 : 코드를 작성하기 전에 유효한 입력 범위가 무엇인지, 경계 조건이 무엇인지, 루틴이 뭘 전달한다고 약속하는지, 혹은 더 중요하게는 무엇을 약속하지 않는지를 나열하는 것만으로도 더 나은 소프트웨어를 작성하는 데에 도움이 된다. (p.153)
죽은 프로그램은 거짓말을 하지 않는다.
'있을 수 없는 일'이 발생했을 때 우리는 그 사실을 알아야한다. 데이터가 우리가 생각하는 대로인지, 서비스에서 작동하는 코드가 우리가 생각하는 그 코드인지 확인해야 한다. 필요한 라이브러리들이 올바른 버전으로 실제로 로드됐는지도 확인해야 한다. (p.159)
단정적 프로그래밍
단정문으로 불가능한 상황을 예방하라, 그런 일은 절대 일어날 리 없다는 믿음을 없애라.
단정문(assertion)을 사용하여 참인지 거짓인지 확인하라.
단정문을 쓸 때도 조건을 평가하는 코드에 부작용(side effect)이 일어날 가능성을 염두하라.
리소스 사용의 균형
자신이 시작한 것은 자신이 끝내라.
리소스를 할당하는 함수나 객체가 리소스를 해제하는 책임 역시 져야 한다.
지역적으로 행동하라.
중첩 할당 : 한 번에 여러 리소스를 사용하는 루틴에 적용하라.
리소스를 할당한 순서의 역순으로 해제할 것.
코드의 여러 곳에서 동일한 구성의 리소스들을 할당하는 경우엔느 언제나 같은 순서로 할당해야 교착 가능성을 줄일 수 있다.
객체와 예외 : OOP를 한다면 리소스를 클래스 안에 캡슐화하는 것이 유용하다.
균형 잡기와 예외 : C++의 스택 변수, 아니면 try~catch 블록의 finally 절을 사용하라.
균형을 점검하기 : 실용주의 프로그래머는 자신을 포함해서 아무도 믿지 않는다.
헤드라이트를 앞서가지 말라
소프트웨어 개발에서도 우리의 헤드라이트는 제한되어 있다. 너무 먼 미래는 내다볼 수 없고, 정면에서 벗어난 곳일수록 더 어둡다.
언제나 작은 단계들을 밟아라 : 피드백을 확인하고 조정하라.
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
Design By Contact라는 개념은 지키기가 참 어려운 것이다. 명세를 정확하게 지킨 소프트웨어를 개발하자.
프로그래머는 자신을 제외한 나머지 것들을 모두 의심하고 또 의심해야 한다. 저번 챕터의 주제인 코드들의 엔트로피가 상승되지 않도록 항상 ETC 코드를 지키면서 작성함을 염두해두고 이 챕터에서 심화된 생각으로 읽게 되었다.
오늘 읽은 다른사람의 TIL
님의 TIL (4장 실용주의 편집증)
오늘 올라온 TIL중에 제일 잘 써주신 것 같습니다.