실용주의 프로그래머 #7일차

🧑🏻‍💻 오늘 TIL 3줄 요약

 

• 세상에 완벽한 소프트웨어는 없다.
• 실용주의 프로그래머는 자기 자신 역시 믿지 않는다.
• 계약으로 설계하라. 수용할 것은 엄격하게, 내어 줄 것은 최대한도로

TIL (Today I Learned)

 

• 2022. 3. 24.

📕 오늘 읽은 범위

 

• 4장. 실용주의 편집증

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

 

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

실용주의 프로그래머는 자기 자신 역시 믿지 않는다. 어느 누구도, 심지어는 자기 자신도 완벽한 코드를 작성할 수 없음을 알기 때문에 실용주의 프로그래머는 자신의 실수에 대비한 방어책을 마련한다. _p.146

계약에 의한 설계

• 정직한 거래를 보장하는 최선의 해법 중 하나는 ‘계약contract’이다.
  계약은 자신과 상대편의 권리 및 책임을 정의한다. 그뿐만 아니라 한쪽이 계약을 어겼을 경우의 대응도 계약 사항에 포함된다. _p.147

 

•  DBC: 계약에 의한 설계 Design By Contract _p.147

 

• DBC는 모든 입력값에 대해 성공과 실패를 정의한다. 반면에 테스트는 하나가 한 가지 경우만 다룬다. _p.152

 

•  DBC는 방어적 프로그래밍보다 더 효율적이고 더 DRY하다. 방어적 프로그래밍에서는 아무도 데이터를 검증하지 않는 상황에 대비하기 위해 모든 사람이 데이터를 검증한다. _p.152

 

• 의미론적 불변식 semantic invariant'은 무언가가 품은 진짜 의미의 중심이 되어야 하며, 훨씬 역동적으로 변하는 비즈니스 규칙처럼 일시적인 정책에 영향을 받으면 안 된다. 우리가 의미론적 불 변식이라는 용어를 사용하는 것은 이 때문이다. _p.156

 

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

• 일찍 작동을 멈춰라. _p.160

 

• 방금 있을 수 없는 일이 발생했다는 것을 코드가 발견했다면 프로그램은 더는 유효하지 않다고 할 수 있다. 이 시점 이후 로 하는 일은 모두 수상쩍은 게 된다. 되도록 빨리 종료할 일이다. _p.161

단정적 프로그래밍

• 단정문으로 불가능한 상황을 예방하라. _p.162

 

• 배포 이후에도 단정 기능을 켜둬라. _p.164

 

리소스 사용의 균형

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

 

•  리소스를 할당한 순서의 역순으로 해제하라. 이렇게 해야 한 리소스가 다른 리소스를 참조하는 경우에도 참조를 망가트리지 않는다. _p.171

 

•  코드의 여러 곳에서 동일한 구성의 리소스들을 할당하는 경우에는 언제나 같은 순서로 할당해야 교착(deadlock) 가능성을 줄일 수 있다. 프로세스 A가 resource1을 이미 확보하고서 resource2를 획득하려고 하고 있는데 프로세스 B는 resource2를 확보한 상태로 resource1을 막 요청하려고 한다면, 두 프로세스 모두 영원히 기다리게 될 것이다. _p.171

🤔 오늘 읽은 소감은?

  편집증(偏執症) 또는 파라노이아(영어: paranoia)는 심각한 걱정이나 두려움으로 자신이 주변으로부터 피해를 받을 것이라는 병리적인 의심을 고집하는 이상심리학적 상태를 일컫는다. 대개 비이성적 사고나 착각의 상태에 이르게 된다.

- 위키백과

  우리 모두는 불확실성으로 넘처나는 세계에 살고있다. 이 장에서 완벽한 소프트웨어를 만들 수 없다고 하는 부분도 세상엔 우리가 모르는 어떤 기상천외한 일이 발생할 수 있으므로 인지의 범주 내에서 통제하려고 노력을 하여 어느 지점 까지 수렴시키는 것이 최선일 것이다. 어플리케이션을 개발하다보면 이런 비슷한 말을 들은 적 있을 수도 있겠다. '당신이 개발하는 제품은 두 가지 유형의 사람이 이용한다고 가정 해야 하는데, 바로 냉소적인 업계 유수의 전문가 혹은 언제든지 무언가를 엉망으로 만들어버릴 준비가 되어있는 잼민이들이다.' 이런 무한한 스펙트럼 속에서 개발자들은 스스로의 코드를 보호하기 위한 방어적 코딩을 한다. 여기서 더 나아가 그 이 장에서는 개발자 본인도 이 위협 중 하나로 간주하고 오류를 최소화하기 위한 광기 방법들을 보여주는데, 이것이 어떤 피해를 받을 것을 예측하여 합리적으로 '실용적으로' 대처를 해둔 개발자의 편집증이 아닐까?