[노개북] 실용주의 프로그래머 (4장. 실용주의 편집증)

오늘 읽은 범위 🔖 4장. 실용주의 편집증

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

• 계약에 의한 설계 (DBC, Design by Contract): 코드를 작성하기 전에 값의 입력 범위, 경계 조건, 루틴이 전달하는게 뭔지 정의하는 일종의 설계 기법이다. 
• 일찍 작동을 멈춰라 (p. 160)
• 절대 일어나지 않는 일은 없다. 단정문으로 불가능한 상황을 예방하라 (p. 162)
  • 진짜 오류처리를 해야하는 곳에 단정을 대신 사용하지는 말라 (p. 163)
• 단정 기능을 켜 둬라, 실서비스에서도 (p. 165)
  • 성능 이슈가 있는 경우 문제가 되는 단정문만 끄도록 하자
• 내가 사용한 리소스는 내가 해제하자
• 작은 단계들을 밟아라. 언제나. 더 진행하기 전에 피드백을 확인하고 조정하라. "아기 발걸음" 원칙 (p. 178)
  • 너무 큰 작업의 범위는? '예언'을 해야하는 모든 작업으로 경험에 기반한 추측을 벗어난 무모한 억측의 영역

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

• 계약에 의한 설계는 기획자와 작성할 수 있는 영역인지 궁금했다. 지금은 화면 설계와 일부 필드명이 기입된 기획서를 보고 의견을 조율하면서 만드는데, 요구사항에 따라 선행 조건, 후행 조건, 불변식을 작성하면 시간도 많이 들고 작성할 문서 양이 정말 많을 것 같다.
• assert는 실무에서 써본적이 없다. 써보지도 않고 성능 문제를 우려했는데 성능 문제가 있는 assert는 빼라는 내용을 읽고 당연하지만 조금 허무한 해결책이라고 생각했다.
• 문제를 해결하는 일에 정신없이 몰두하다보면 코뿔소처럼 수많은 일을 들이받고 앞으로 밀고 나간다는 생각이 들 때가 있다. 그러면 작은 업무를 지나 너무 큰 작업까지 해버리기 쉽고, 운이 나쁘면 지금까지 했던 일을 일부 되돌려야할 때도 있다. 작은 단계를 밟아야한다는 내용을 읽고 공감했다.

🔍 궁금하거나 잘 이해되지 않는 내용

• Design By Contract: 계약 프로그래밍(Contract Programming)이라고도 한다. 책에 나온 언어 외에 Kotlin, Scala에서 지원하고 그 외에는 서드파티를 이용해서 구현 가능하다. 관련해서 참고하기 좋은 JAVA 예제와 글 -> https://skyul.tistory.com/86

---

오늘의 TIL 3줄 요약

 

• 계약에 의한 설계 (DBC, Design by Contract): 코드를 작성하기 전에 값의 입력 범위, 경계 조건, 루틴이 전달하는게 뭔지 정의하는 일종의 설계 기법이다. 
• 절대 일어나지 않는 일은 없다. 단정문으로 불가능한 상황을 예방하라
• 작은 단계들을 밟아라