노마드코더 북클럽 실용주의 프로그래머 TIL 네번째

2022년 3월 24일 TIL

오늘 TIL 3줄 요약

• 계약에 대한 설계, 단정문을 사용해서 함수의 입출력, 변수의 검증을 최대한 빠른 시점에 하자.
• 있을 수 없는 일이란 있을 수 없다.¹
• 스코프를 활용하자.

오늘 읽은 범위

• 4장. 실용주의 편집증 (170/477 ~ 205/477)

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

• 여러분은 완벽한 소프트웨어를 만들 수 없다. (170/477)
• 실용주의 프로그래머는 자기 자신 역시 믿지 않는다. (171/477)
• 함수형이든 객체 지향이든 절차형이든 모든 프로그래밍 언어에서 DBC(Design By Contract)는 여러분을 생각하게 한다. (176/477)
• TDD는 멋진 기법이다. 하지만 다른 많은 기법과 마찬가지로 '정상 경로'에만 집중하도록 유도하기도 한다. 그러나 바깥세상은 나쁜 데이터와 나쁜 사람들, 나쁜 버전, 나쁜 명세로 가득차 있다. (177/477)
• 일반적으로 죽은 프로그램이 끼치는 피해는 이상한 상태의 프로그램이 끼치는 피해보다 훨씬 적은 법이다. (186/477)
• 언제나 신중하게 작은 단계들을 밟아라. 더 진행하기 전에 피드백을 확인하고 조정하라. 피드백의 빈도를 여러분의 제한 속도라고 생각하라. '너무 큰' 단계나 작업은 하지 않게 될 것이다. (203/477)

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

• Elixir에 대한 내용..
  • 특정 언어에 대한 책은 아니지만 Elixir 얘기가 조금 나와서 반가웠다.
  • Fault-tolerant. Elixir나 Erlang을 처음 접할 때 늘 언급 되는 단어이다. 본문에도 나와있지만 프로세스가 에러가 발생하면 종료해버리고 새로 프로세스를 실행하는 식이다. 실제 작업시에는 억지로 프로세스가 죽는 시점 이벤트를 받아서 데이터들을 후처리 하려고 하는 등, Fault-tolerant와는 거리가 있는 식으로 만들기도 했었는데 지금 다시 만들면 좀 더 나은 구조로 만들 수 있지 않을까..?
  • guard 함수를 guard에 따라서 오버로딩할 수 있도록 하는 내용. guard에는 모든 함수를 사용할 수 있지는 않다는 점이 빠져있긴 하지만 guard만 아니라 패턴매칭을 통해서 유효한 리스트, 특정 키의 존재 여부까지도 검증할 수 있다. 하지만 본문처럼 정의하지 않고 에러를 발생시키지는 않고 보통 guard내 패턴 매칭을 뺀 항상 도달하는 말단 함수를 만들어서 예외를 처리하도록 만들었다. 이러나 저러나 서비스 중인 서버가 죽이지 않게 하려고 그렇게 했는데, 오히려 그냥 죽여버리는 쪽이 패킷 변조하는 나쁜 사람들을 걸러낼 수 있어서 좋지 않았을까?
• 계약에 의한 설계는 조건을 함수 앞뒤로 붙여가며 만든다는게 쉽지 않을것 같다. C++로 주로 일하는 지금 포인터에 대한 nullptr 검사는 함수 상단에 자주 붙이고 있긴한데, 사실 불필요한 부분이라고 느끼는 경우가 종종 있다. 하지만 왠지 안넣어두면 찝찝하단 말이지...