Skip to content

Commit

Permalink
[박상범] 4장: 실용주의 편집증 (#37)
Browse files Browse the repository at this point in the history
* 상범 4장

* 수정

* 정리
  • Loading branch information
sangbooom authored Aug 20, 2024
1 parent 62abac6 commit 209e64f
Showing 1 changed file with 77 additions and 0 deletions.
77 changes: 77 additions & 0 deletions 4장/박상범.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,77 @@
## 4장 실용주의 편집증
4장을 읽기전에 내가 생각한 실용주의는 문제 해결과 소프트웨어 개발에 있어 현실적이고 효과적인 접근 방식(끊임없는 학습, 책임감, 도구 잘 다루기 등)을 의미하는 것으로 생각했고 그런 실용주의 의미와 어울리지 않는 편집증이 합쳐진 챕터라서 어떤 의미를 전달하려고 하는 것인가가 궁금했다.

> 읽고 난 후에는 실용주의 편집증을 완벽한 소프트웨어를 만들 수 있다는 망상을 버려라 로 이해했다.
> 4장에서 전달하고자 하는 의미는 자기 자신을 100% 믿지 말고 방어적인 코드를 작성하는 습관을 기르자. 불완전한 시스템, 불가능한 요구사항 속에서 안전하게 살아보자. 인듯하다
### Topic 23. 계약에 의한 설계
계약은 정직한 거래를 보장하는 최선의 해법 중 하나
- 자신과 상대편의 권리 및 책임 정의

그럼 소프트웨어 모듈이 서로 소통을 위한 계약을 맺는 것은 무엇일까?
- DBC (Design By Contract):
- 소프트웨어 모듈의 권리와 책임 문서화 + 합의
- 책임: 자신이 하는 일이라고 주장하는 것만 하는 프로그램
- 루틴(메소드) 책임의 조건
- 선행 조건: 호출 쪽 입력 책임
- 후행 조건: 자기가 할 것이라 보장하는 것
- 클래스(상태) 불변식: 호출자로 제어권이 반환 되는 데이터의 불변식은 참
- 정리: 호출자가 루틴의 모든 선행조건을 충족한다면 해당 루틴은 종료 시 모든 후행 조건과 불변식이 참이 되는 것을 보장
- Tip 37. 계약으로 설계하라
- 그럼 DBC는 어떻게 구현?
- 작성 가이드
- 유효 입력 범위
- 경계 조건
- 루틴이 뭘 전달한다고 약속하는지
- 무엇을 약속하지 않는지 → 해당 부분도 명시해보자
- 단정문(assert)으로 계약 검사를 다할 수 있는가 → false
- 상속, 오버라이드로 인한 구멍

DBC와 일찍 멈추기(ealry stop, ealry return)는 잘어울림

의미론적 불변식?
- 어겨서는 안되는 고정된 규칙 (일시적 정책 영향 X)
- 이를 문서화

> [계약에 의한 설계(Design by Contract)로 견고한 서비스 만들기](https://armadillo-dev.github.io/design/programming/desing-by-contract/)에 간단한 예시와 함께 이 장을 요약해주는 느낌이라 공유합니다.
### Topic 24. 죽은 프로그램은 거짓말을 하지 않는다
‘있을 수 없는 일’이 발생했을 때 더 망치기 전에 빨리 종료하는게 낫다. 오류 메시지좀 읽어라

일반적으로 죽은 프로그램이 끼치는 피해가 이상한 상태의 프로그램이 끼치는 피해보다 훨씬 적은 법이다
> react errorBoundary와 suspense를 선언적으로 사용하여 전역적, 컴포넌트 단위로 잘 감싸준다면.. 책에서 나오는 슈퍼바이저가 관리하는 효과를 내면서 죽은 컴포넌트에서 나쁘지 않은 UX를 제공할 수 있지 않을까?
> 그리고 예외처리할 때 특별한 이유 없으면 위로 올리지 말자요.. 책에서 나온대로 사고가 난 지점에서 일찍 멈추는게 유리하니까..
### Topic 25. 단정적 프로그래밍

`그런 일은 절대 일어날 리 없어` 그만
- 그런 일이 일어날 리 없다 생각들면 그런 일에 대한 확인 코드 추가해라

tip 39. 단정문(assert)으로 불가능한 상황을 예방하라

단정문이 상태를 바꿀 수 있으면 안된다. 사이드이펙트 유발하면 안됨

진짜 정상 플로우로 흘러갈 수 있다면 해당 예외 처리는 단정(assert) X

### Topic 26. 리소스 사용의 균형
리소스 할당 해제 관련해서 예제..
> 저자가 무엇을 의도한 것인지는 알겠는데 유저를 업데이트하는 함수가 파일 오픈에 관여하는게 과연 맞을까에 대해서는 다시 한 번 생각해볼 필요가 있을 듯함
c++나 러스트 같은 언어의 일반적인 스코프 규칙에서는 함수나 블록 종료, 예외 등으로 변수가 스코프를 벗어나면 변수의 메모리가 해제된다.
> 자바도 try-with-resources 라는걸 지원해주는걸로 앎. try에서 자원 객체 전달해주고 블록 끝나면 자동으로 자원 반납해줌. AutoClosable 인터페이스 구현한 구현체에서만 사용가능 했던걸로 앎.
`실용주의 프로그래머는 자신을 포함해서 아무도 믿지 않는다.`
> 띵언
### Topic 27. 헤드라이트를 앞서가지 말라
불확실한 미래에 대비한 설계를 하느라 진을 빼는 대신 언제나 교체 가능한 코드를 작성하여 대비하면 된다.
=> 예언하지 말라

헤드라이트 거리에 한계가 있는 것 처럼 우리도 한 두 단계 앞 정도의 미래만 내다볼 수 있다.

미래의 유지보수를 고려해서 설계해야 하지만 볼 수 있는 미래까지만 고려해야 하고, 더 많이 예측하려 할 수록 틀릴 가능성이 높아진다.

> 그러니 좋은 대책은 교체하기 쉽게 만드는 것, 근데 적당히 교체 가능한 코드 작성하는 것도 쉽지 않음..

0 comments on commit 209e64f

Please sign in to comment.