From 8c43e82bc29cf7f7bc08a1bb1d95cee6bb449333 Mon Sep 17 00:00:00 2001 From: SangBeom Park Date: Sun, 11 Aug 2024 00:32:13 +0900 Subject: [PATCH 1/3] =?UTF-8?q?=EC=83=81=EB=B2=94=204=EC=9E=A5?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../\353\260\225\354\203\201\353\262\224.md" | 72 +++++++++++++++++++ 1 file changed, 72 insertions(+) create mode 100644 "4\354\236\245/\353\260\225\354\203\201\353\262\224.md" diff --git "a/4\354\236\245/\353\260\225\354\203\201\353\262\224.md" "b/4\354\236\245/\353\260\225\354\203\201\353\262\224.md" new file mode 100644 index 0000000..b2409c7 --- /dev/null +++ "b/4\354\236\245/\353\260\225\354\203\201\353\262\224.md" @@ -0,0 +1,72 @@ +## 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. 헤드라이트를 앞서가지 말라 +불확실한 미래에 대비한 설계를 하느라 진을 빼는 대신 언제나 교체 가능한 코드를 작성하여 대비하면 된다. +=> 예언하지 말라 +> [토스 모닥불 EP1. 가독성 좋은 코드란 무엇일까?](https://www.youtube.com/watch?v=1Vn8et-MdaI&t=951s) 에서도 진유림님이 하시는 말에 공감. 코드를 작성할 때 최대한 직교성을 띄고, 재사용 가능한 컴포넌트를 짜려고 노력하는 편.. +> 정리 타이밍은? 중간중간 유심히 타이밍 잘 보고 하기. 차라리 설계를 적당히 하고 개발하면서 짬짬히 리팩토링하는게 나음.. 요구사항은 바뀔 수 있고 바꾸기 쉬운 코드로 작성하는게 좋지 않을까 +> 쓰다보니까 이 장과 크게 관련없는 말을 한거 같은데.. 암튼 불확실한 미래에 대비한 설계 하느라 시간 쏟지말자 From e91208e728b3f81f142bda159ba730f6d82826ed Mon Sep 17 00:00:00 2001 From: SangBeom Park Date: Sun, 11 Aug 2024 10:40:45 +0900 Subject: [PATCH 2/3] =?UTF-8?q?=EC=88=98=EC=A0=95?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../\353\260\225\354\203\201\353\262\224.md" | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git "a/4\354\236\245/\353\260\225\354\203\201\353\262\224.md" "b/4\354\236\245/\353\260\225\354\203\201\353\262\224.md" index b2409c7..1f961c2 100644 --- "a/4\354\236\245/\353\260\225\354\203\201\353\262\224.md" +++ "b/4\354\236\245/\353\260\225\354\203\201\353\262\224.md" @@ -1,7 +1,7 @@ ## 4장 실용주의 편집증 -4장을 읽기전에 내가 생각한 실용주의는 문제 해결과 소프트웨어 개발에 있어 현실적이고 효과적인 접근 방식(끊임없는 학습, 책임감, 도구 잘 다루기 등)을 의미하는 것으로 생각했는데.. 그런 실용주의 의미와 어울리지 않는 편집증이 합쳐진 챕터라서 어떤 의미를 전달하려고 하는 것인가가 궁금했다. +4장을 읽기전에 내가 생각한 실용주의는 문제 해결과 소프트웨어 개발에 있어 현실적이고 효과적인 접근 방식(끊임없는 학습, 책임감, 도구 잘 다루기 등)을 의미하는 것으로 생각했고 그런 실용주의 의미와 어울리지 않는 편집증이 합쳐진 챕터라서 어떤 의미를 전달하려고 하는 것인가가 궁금했다. -> 읽어보니 왜 굳이 편집증이라는 단어를 사용했지..? 개인적으로 와닿지는 않았음 +> 읽고 난 후에는 실용주의 편집증을 완벽한 소프트웨어를 만들 수 있다는 망상을 버려라 로 이해했다. > 4장에서 전달하고자 하는 의미는 자기 자신을 100% 믿지 말고 방어적인 코드를 작성하는 습관을 기르자. 불완전한 시스템, 불가능한 요구사항 속에서 안전하게 살아보자. 인듯하다 @@ -41,6 +41,7 @@ DBC와 일찍 멈추기(ealry stop, ealry return)는 잘어울림 일반적으로 죽은 프로그램이 끼치는 피해가 이상한 상태의 프로그램이 끼치는 피해보다 훨씬 적은 법이다 > react errorBoundary와 suspense를 선언적으로 사용하여 전역적, 컴포넌트 단위로 잘 감싸준다면.. 책에서 나오는 슈퍼바이저가 관리하는 효과를 내면서 죽은 컴포넌트에서 나쁘지 않은 UX를 제공할 수 있지 않을까? + > 그리고 예외처리할 때 특별한 이유 없으면 위로 올리지 말자요.. 책에서 나온대로 사고가 난 지점에서 일찍 멈추는게 유리하니까.. ### Topic 25. 단정적 프로그래밍 @@ -67,6 +68,14 @@ c++나 러스트 같은 언어의 일반적인 스코프 규칙에서는 함수 ### Topic 27. 헤드라이트를 앞서가지 말라 불확실한 미래에 대비한 설계를 하느라 진을 빼는 대신 언제나 교체 가능한 코드를 작성하여 대비하면 된다. => 예언하지 말라 -> [토스 모닥불 EP1. 가독성 좋은 코드란 무엇일까?](https://www.youtube.com/watch?v=1Vn8et-MdaI&t=951s) 에서도 진유림님이 하시는 말에 공감. 코드를 작성할 때 최대한 직교성을 띄고, 재사용 가능한 컴포넌트를 짜려고 노력하는 편.. -> 정리 타이밍은? 중간중간 유심히 타이밍 잘 보고 하기. 차라리 설계를 적당히 하고 개발하면서 짬짬히 리팩토링하는게 나음.. 요구사항은 바뀔 수 있고 바꾸기 쉬운 코드로 작성하는게 좋지 않을까 -> 쓰다보니까 이 장과 크게 관련없는 말을 한거 같은데.. 암튼 불확실한 미래에 대비한 설계 하느라 시간 쏟지말자 + +헤드라이트 거리에 한계가 있는 것 처럼 우리도 한 두 단계 앞 정도의 미래만 내다볼 수 있다. + +미래의 유지보수를 고려해서 설계해야 하지만 볼 수 있는 미래까지만 고려해야 하고, 더 많이 예측하려 할 수록 틀릴 가능성이 높아진다. + +> 그러니 좋은 대책은 교체하기 쉽게 만드는 것, 근데 적당히 교체 가능한 코드 작성하는 것도 쉽지 않음.. + +> [토스 모닥불 EP1. 가독성 좋은 코드란 무엇일까?](https://www.youtube.com/watch?v=1Vn8et-MdaI&t=951s) 에서 진유림님은 코드를 작성할 때 재사용 가능한 컴포넌트를 짜려고 노력하는 편이라고 함. 여러분들은? + +> 정리 타이밍은? 중간중간 유심히 타이밍 잘 보고 하기.. 설계를 적당히 하고 유연하게 개발하면서 짬짬히 리팩토링하는게 낫다고 생각..(이건 그냥 제 개발스타일.. 왜냐면 요구사항은 쉽게 바뀌니까..) + From b1e0e8b957522c12312d13fc13c2abab74aadcf9 Mon Sep 17 00:00:00 2001 From: SangBeom Park Date: Sun, 11 Aug 2024 10:42:22 +0900 Subject: [PATCH 3/3] =?UTF-8?q?=EC=A0=95=EB=A6=AC?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- "4\354\236\245/\353\260\225\354\203\201\353\262\224.md" | 4 ---- 1 file changed, 4 deletions(-) diff --git "a/4\354\236\245/\353\260\225\354\203\201\353\262\224.md" "b/4\354\236\245/\353\260\225\354\203\201\353\262\224.md" index 1f961c2..4342bee 100644 --- "a/4\354\236\245/\353\260\225\354\203\201\353\262\224.md" +++ "b/4\354\236\245/\353\260\225\354\203\201\353\262\224.md" @@ -75,7 +75,3 @@ c++나 러스트 같은 언어의 일반적인 스코프 규칙에서는 함수 > 그러니 좋은 대책은 교체하기 쉽게 만드는 것, 근데 적당히 교체 가능한 코드 작성하는 것도 쉽지 않음.. -> [토스 모닥불 EP1. 가독성 좋은 코드란 무엇일까?](https://www.youtube.com/watch?v=1Vn8et-MdaI&t=951s) 에서 진유림님은 코드를 작성할 때 재사용 가능한 컴포넌트를 짜려고 노력하는 편이라고 함. 여러분들은? - -> 정리 타이밍은? 중간중간 유심히 타이밍 잘 보고 하기.. 설계를 적당히 하고 유연하게 개발하면서 짬짬히 리팩토링하는게 낫다고 생각..(이건 그냥 제 개발스타일.. 왜냐면 요구사항은 쉽게 바뀌니까..) -