제 4장 실용주의 편집증

어느 누구도,
심지어는 자기 자신도
완벽한 코드를 작성할 수 없음을 알기 때문에

 

TIL (Today I Learn)

• Assignment 07
• 2022-03-25

---

오늘 읽은 범위

• 4장 실용주의 편집증

---

3줄 요약

• 계약에 의한 설계 Design By Contract, DBC.
• 단정문으로 불가능한 상황을 예방하라.
• 언제나 교체 가능한 코드를 작성하여 대비하면 된다. (결국은 ETC)
  

---

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

• 여러분은 완벽한 소프트웨어를 만들 수 없다. 삶의 공리로 인정하고 받아들여라. 
• 실용주의 프로그래머는 자기 자신 역시 믿지 않는다.

 

Topic 23 계약에 의한 설계

• 계약에 의한 설계 Design By Contract, DBC.
• DBC는 단순하지만 강력한 기법으로, 프로그램의 정확성을 보장하기 위해 소프트웨어 모듈의 권리와 책임을 문서화하고 합의하는 데에 초점을 맞춘다. 
• 루틴과 그 루틴을 호출하려는 코드 간의 계약은 다음과 같다.  만약 호출자가 루틴의 모든 선행 조건을 충족한다면 해당 루틴은 종료 시 모든 후행 조건과 불변식이 참이 되는 것을 보장한다.
• 이번에는 ‘게으름뱅이 lazy’ 코드를 강조하고 싶다. 
  • 시작하기 전에 자신이 수용할 것은 엄격하게 확인하고, 내어 줄 것에 대해서는 최소한도를 약속하는 것이다.
•  명시적으로 검증해야 할 매개 변수가 하나라도 있다면 호출자가 검증을 수행해야 한다. 호출되는 루틴은
  선행 조건을 위배하는 매개 변수를 결코 보지 못할 것이기 때문이다. 호출자가 마땅히 책임을 져야 한다. 
  예시) 제곱근 함수의 입력 범위를 sqrt 루틴의 선행 조건에 표현함으로써 입력의 정확성 확보라는 짐을 호출자에게 지운다. 호출자가 마땅히 책임을 져야 한다. 그러면 여러분은 입력값이 범위 내에 있다는 전제하에 sqrt 루틴을 안전하게 설계할 수 있게 된다.

 

 

 

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

 

“방어적 프로그래밍은 시간 낭비다. 그냥 멈추는 게 낫다”

 

• ‘있을 수 없는 일’이 발생했을 때 우리는 그 사실을 알아야 한다. 모든 케이스/스위치문에 디폴트 구문을 달아야 하는 이유다. 
• 일반적으로 죽은 프로그램이 끼치는 피해는 이상한 상태의 프로그램이 끼치는 피해보다 훨씬 적은 법이다.

 

 

 

Topic 25 단정적 프로그래밍

• 그런 일은 절대 일어날 리 없어. 이런 식으로 자신을 기만하지 말자, 특히 코딩할 때는.
  • 대신 확인하는 코드를 추가하라. 가장 간단하게 추가하는 방법은 단정문 assertion을 사용하는 것이다. 
• 단정은 결코 일어나면 안 되는 것들을 검사한다. 진짜 오류 처리를 해야 하는 곳에 단정을 대신 사용하지는 말라.
• 성능 문제가 있다 하더라도 정말 문제가 되는 단정문만 끄도록 하자. 나머지는 그대로 둬라.

 

 

 

Topic 26 리소스 사용의 균형

• 자신이 시작한 것은 자신이 끝내라. 지역적으로 행동하라.
  • 리소스를 할당하는 루틴이 해제 역시 책임져야 한다는 것이다. 
• 스코프를 벗어나면서 열렸던 파일도 닫힌다. 끝. 파일을 닫고 리소스를 해제하는 것을 기억할 필요가 없다.
  • 즉, 잘 모르겠을 땐 언제나 스코프를 줄이는 편이 낫다.
• 리소스를 할당한 순서의 역순으로 해제하라.
• 언제나 같은 순서로 할당해야 교착deadlock 가능성을 줄일 수 있다.
• 우리가 선호하는 방법은 주요 자료 구조마다 표준적인 할당과 해제 기능을 제공하는 모듈을 하나씩 작성하는 것이다.

 

 

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

• 소프트웨어 개발에서도 우리의 ‘헤드라이트’는 제한되어 있다. 
  • 언제나 신중하게 작은 단계들을 밟아라. 더 진행하기 전에 피드백을 확인하고 조정하라. 피드백의 빈도를 여러분의 제한 속도라고 생각하라
  • 예언하지 말라. 여러분이 볼 수 있는 미래까지만 고려해야한다. 
  • 대신 언제나 교체 가능한 코드를 작성하여 대비하면 된다. (결국은 ETC)

 

---

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

• 이 책을 읽다보면 보통 공감이 되는 부분이 많지만 이번에는 다소 찔리는게 많은 장이었다.
• 보통 개발할 때 네트워크 소켓처럼 많은 로직이 딸려오는 리소스 할당 외에는 명확히 할당/해제를 명시하기 보단 스코프를 활용했었다. 이게 익숙해져버리기도 했고, 현대 언어가 제공하는 편의겠지만 어쩌면 너무 편하게만 살았나 살짝 걱정되기도 한다.
• 로직 개발 시 DBC 처럼 선수 조건을 체크한다기 보단 인자 검증부터 모든걸 '관련자가 해야지' 하는 마음으로 해당 로직으로 전가한 경우가 많았던 것 같다. 
  • 검증해야할 인자가 하나라도 있다면 호출자가 검증할 것...(메모)
  • 다음부터는 실제 업무에도 적용해보자.
• 마지막 헤드라이트 관련 내용을 읽다보니 내가 그 스포츠 카의 운전자였을지도 모른다는 생각이 든다.'향후 ~게 된다면' 라는 가정을 너무 넓게 펼치고 개발했던 부분들이 꽤 있었던 것 같거든(반성) 리팩토링을 진행하며 어느정도 정리를 하고있긴 했지만 정의했던 타입이나 정의는 아직도 남아있던 것으로 기억한다.
  • 어차피 사용되는 부분만 컴파일 되니 언젠간 쓰이게 된다면 코드만 남겨두는 것은 괜찮다고 생각했는데. 역시 아예 지워버리는게 나은거겠지. VCS를 사용하더라도 한참 뒤에 사용할 일이 생긴다면 그 히스토리를 찾긴 쉽지 않을 것이라 아직 버리지 않은 것도 있지만, 그정도로 먼 미래라면 그때가서 새롭게 짜는게 나을거야.

 

---

 

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요

• 게으름뱅이 코드라지만 진짜 게으름뱅이는 선수 작업도 열심히 하지 않는다(뜨끔) 차라리 정찰병이라 하는게 낫지 않나.