Docs: 박승훈 4장

4장/박승훈.md

@@ -0,0 +1,165 @@
+## 들어가며
+
+"컴퓨터 역사를 통틀어 어느 누구도 완벽한 소프트웨어를 만들지 못했다."
+
+실용주의 프로그래머는 자기 자신 역시 믿지 않는다. 어느 누구도, 심지어는 자기 자신도 완벽한 코드를 작성할 수 없음을 알기 때문에 실용주의 프로그래머는 자신의 실수에 대비한 방어책을 마련한다.
+
+<br />
+
+## Topic 23 : 계약에 의한 설계
+
+> "정직한 거래를 보장하는 최선의 방법 중 하나는 '계약'이다."
+
+<br />
+
+### 계약이란?
+
+- 자신과 상대편의 권리 및 책임
+- 한쪽이 계약을 어겼을 경우의 대응
+
+<br />
+
+### DBC (Design by Contract)
+
+- 계약에 의한 설계 (DBC)
+- 프로그램의 정확성을 보장하기 위해 소프트웨어 모듈의 권리와 책임을 문서화하고 합의한다.
+- 정확한 프로그램 : 자신이 하는 일이라고 주장하는 것보다 많지도 적지도 않게 딱 그만큼만 하는 프로그램
+
+<br />
+
+### 소프트웨어 시스템과 계약
+
+- 선행 조건(precondition)
+
+  - 함수가 호출되기 전에 참이어야 하는 것
+  - 루틴의 요구사항
+  - 제대로 된 데이터를 전달하는 것은 호출하는 쪽의 책임
+
+- 후행 조건(postcondition)
+
+  - 루틴이 자기가 할 것이라고 보장하는 것
+  - 루틴이 완료되었을 때 세상의 상태
+
+- 클래스 불변식(class invariant)
+  - 루틴이 끝나고 호출자로 제어권이 반환되는 시점에는 불변식이 참이 되어야 한다.
+
+<br />
+
+### 게으름뱅이 코드
+
+- 게으름뱅이 코드(lazy code)
+- 시작하기 전에 자신이 수용할 것은 엄격하게 확인
+- 내어줄 것에 대해서는 최소한도를 약속
+
+<br />
+
+### DBC의 구현
+
+코드를 작성하기 전에 유효한 입력 범위가 무엇인지, 경계 조건이 무엇인지, 루틴이 뭘 전달한다고 약속하는지, 혹은 더 중요하게는 무엇을 약속하지 않는지 나열하기
+
+<br />
+
+### DBC와 일찍 멈추기
+
+DBC는 "일찍 작동을 멈춰라."라는 개념과 잘 어울린다. 단정문이나 DBC 방식을 사용하여 선행 조건과 후행 조건, 불변식을 검증하면 더 일찍 멈추고, 문제에 대한 보다 정확한 정보를 알려줄 수 있을 것이다. 문제를 찾고 원인을 밝히기 위해서는 사고가 난 지점에서 일찍 멈추는 것이 유리하다.
+
+<br />
+
+## Topic 24 : 죽은 프로그램은 거짓말을 하지 않는다
+
+> "버그 상황에서 헤어나는 도중에 어떤 손상도 입히지 않도록 보장해야 한다."
+
+오류의 원인은 다양하다. 모든 switch-case문에 default 구문을 달아야 하는 이유이다. '있을 수 없는 일'이 발생했을 때 우리는 그 사실을 알아야 한다.
+
+<br />
+
+### 방어적으로 코딩하기
+
+- 데이터가 우리가 생각하는 대로인지
+- 서비스에서 작동하는 코드가 우리가 생각하는 그 코드인지
+- 필요한 라이브러리들이 올바른 버전으로 실제로 로드되었는지
+- 오류가 발생했는지, 그렇다면 왜 발생했는지
+
+<br />
+
+### 망치지 말고 멈춰라
+
+가능한 빨리 문제를 발견하면 좀 더 일찍 시스템을 멈출 수 있으니 더 낫다. 방금 있을 수 없는 일이 발생했다는 것을 코드가 발견했다면 프로그램은 더는 유효하지 않다고 할 수 있다. 이 시점 이후로 하는 일은 모두 수상쩍은 게 된다. 되도록 빨리 종료할 일이다. 일반적으로 죽은 프로그램이 끼치는 피해는 이상한 상태의 프로그램이 끼치는 피해보다 훨씬 적은 법이다.
+
+<br />
+
+## Topic 25 : 단정적 프로그래밍
+
+> "'물론 그런 일은 절대 일어나지 않을 거야.'라는 생각이 든다면 그런 일을 확인하는 코드를 추가하라."
+
+<br />
+
+### 단정문에 관한 흔한 오해
+
+**테스트가 모든 버그를 발견한다**
+
+실제로는 프로그램이 조금만 복잡해져도 코드가 거칠 수 있는 경로의 전체 조합에서 지극히 적은 비율조차도 테스트하기 힘들다.
+
+<br />
+
+**프로그램은 테스트를 통과했다면 안전하다**
+
+프로그램은 실제로 험한 세상에서 돌아간다. 쥐가 통신 케이블을 갉아먹거나, 로그 파일이 디스크 파티션을 다 채워 버릴 수도 있다.
+
+<br />
+
+**결론**
+
+첫 번째 방어선은 가능한 오류를 모두 검사하는 것이고, 그다음은 그러고도 놓친 것을 잡아내기 위해 단정을 사용하는 것이다.
+
+<br />
+
+## Topic 26 : 리소스 사용의 균형
+
+> "우리는 코딩할 때 언제나 리소스를 관리한다. 그렇지만 많은 개발자가 일관된 방침을 가지고 있지 않다."
+
+<br />
+
+### 자신이 시작한 것은 자신이 끝내라
+
+- 리소스를 할당하는 함수나 객체가 리소스를 해제하는 책임 역시 져야 한다.
+- 이상적으로 말해서 리소스를 할당하는 루틴이 해제 역시 책임져야 한다는 것이다.
+- 잘 모르겠을 땐 언제나 스코프를 줄이는 편이 낫다. 지역적으로 행동하라.
+
+<br />
+
+## Topic 27 : 헤드라이트를 앞서가지 말라
+
+> "우리는 너무 먼 미래는 내다볼 수 없고, 정면에서 벗어난 곳일수록 더 어둡다."
+
+<br />
+
+### 작은 단계들을 밟아라. 언제나.
+
+언제나 신중하게 작은 단계들을 밟아라. 더 진행하기 전에 피드백을 확인하고 조정하라. 행동을 독립적으로 확증하거나 반증하는 것이라면 모두 피드백이다.
+
+<br />
+
+너무 큰 작업은 무엇일까? '예언'을 해야 하는 모든 작업이다. 불확실한 미래를 대비한 설계를 하느라 진을 빼는 대신 언제나 교체 가능한 코드를 작성하여 대비하면 된다. 코드를 더 적절한 무언가로 대체하기 쉽게 설계하라.
+
+<br />
+
+## 총평
+
+이번 장은 안전한 프로그래밍을 위한 방법론에 대해 다루고 있다. 프로그래밍을 할 때에는 항상 '이런 일은 일어나지 않을 거야'라는 확신에 대해서도 항상 의심하고 방어적으로 프로그래밍을 해야 한다는 점에는 동의한다. 다만 제목의 '편집증'에 가까울 정도로 몹시 방어적인 자세를 가지는 것이 어쩌면 진정한 전문가다우면서도, 너무 과하지 않나 하는 생각도 드는 것 같다.
+
+<br />
+
+Topic 23의 DBC는 계약에 의한 설계..라는 건데 이것도 아직 감이 잘 안 오는 것 같다. 다만 특정 영역에 대해서 최소 권한과 책임을 부여해 한정하는 것은 지금까지도 좋은 프로그래밍 방법이라고 회자되는 것 같다. 예시가 모두 클래스나 옛날 형식으로 되어 있어서 더 와닿지 않는 것도 있는 것 같다.
+
+<br />
+
+조금 더 공감이 됐던 부분은 '일찍 작동을 멈춰라'라는 것이다. 프로그램이 이상한 상태에 빠지면 더 이상 유효하지 않다고 판단하고 빨리 종료하는 것이 더 좋다는 것이다. 안전한 프로그래밍을 위해서는 필요한 방어책인 것 같다.
+
+<br />
+
+단정적 프로그래밍은... 무슨 말을 하는지는 정확히 이해할 수 없었다. 리소스 사용의 균형 부분도 프론트엔드 개발자로서는 리소스를 명령적으로 다루는 일이 그닥 없었다보니 공감이 되지 않았다.
+
+<br />
+
+전체적으로 옛날 프로그래밍이나, 더 low level의 개발에서 신경 써야 하는 것들에 대해 다룬 느낌이어서 내 상황에 맞지 않는 것들이 많아 아쉬움이 있던 장인 것 같다.