Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[변수미] 4장: 실용주의 편집증 #43

Merged
merged 1 commit into from
Aug 20, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
37 changes: 37 additions & 0 deletions 4장/변수미.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,37 @@
### 계약에 의한 설계

- DBC는 단순하지만 강력한 기법으로, 프로그램의 정확성을 보장하기 위해 소프트웨어 모듈의 권리와 책임을 문서화하고 합의하는 데에 초점을 맞춘다.
> 사실 잘 이해못했어요..
- ‘게으름뱅이lazy’ 코드를 강조하고 싶다. 시작하기 전에 자신이 수용할 것은 엄격하게 확인하고, 내어 줄 것에 대해서는 최소한도를 약속하는 것이다.

- 코드를 작성하기 전에 유효한 입력 범위가 무엇인지, 경계 조건이 무엇인지, 루틴이 뭘 전달한다고 약속하는지, 혹은 더 중요하게는 무엇을 약속하지 않는지 등을 나열하는 것만으로도 더 나은 소프트웨어를 작성하는 데에 엄청난 도움이 된다.
- 단정문이나 DBC 방식을 사용하여 선행 조건과 후행 조건, 불변식을 검증하면 더 일찍 멈추고, 문제에 대한 보다 정확한 정보를 알려줄 수 있을 것이다

> 읽으면서 앞으로 인지하면서 개발을 해봐야지.. 하고 생각했습니다

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

- 실용주의 프로그래머는 만약 오류가 발생했다면 정말로 뭔가 나쁜 일이 생긴 것이라고 자신에게 이야기한다. 일단 그놈의 오류 메시지 좀 읽어라.
가능한 한 빨리 문제를 발견하면 좀 더 일찍 시스템을 멈출 수 있으니 더 낫다.

> 맞아요 😂 하지만 콘솔에 뜨는 에러를 봐도 내일의 저한테 자꾸 미루게 되네요

### 단정적 프로그래밍

- 단정문으로 불가능한 상황을 예방하라
- ‘하지만 물론 그런 일은 절대 일어나지 않을 거야.’라는 생각이 든다면 그런 일을 확인하는 코드를 추가하라. 가장 간단하게 추가하는 방법은 단정문assertion을 사용하는 것이다.
- 프로그램을 출시할 때 단정 기능을 꺼 버리는 것은 줄타기 곡예를 하면서 연습으로 한 번 건너 봤다고 그물 없이 건너는 것과 비슷하다. 극적인 가치야 있겠지만 생명 보험을 들기는 어렵다. 성능 문제가 있다 하더라도 정말 문제가 되는 단정문만 끄도록 하자.

> 단정문때문에 페이지가 터지지않는다면 쓰는게 이상적인것 같아요, 그런데 자바스크립트를 사용하는데도 권장하는 방식인가요? 쓰는걸 잘 못본것 같아요

### 리소스 사용의 균형

- 지역적으로 행동하라. 잘 모르겠을 땐 언제나 스코프를 줄이는 편이 낫다.
- 리소스를 할당한 순서의 역순으로 해제하라. 이렇게 해야 한 리소스가 다른 리소스를 참조하는 경우에도 참조를 망가트리지 않는다.
- 코드의 여러 곳에서 동일한 구성의 리소스들을 할당하는 경우에는 언제나
같은 순서로 할당해야 교착deadlock 가능성을 줄일 수 있다.

### 헤드라이트를 앞서가지 말라

- 언제나 신중하게 작은 단계들을 밟아라. 더 진행하기 전에 피드백을 확인하고 조정하라. 피드백의 빈도를 여러분의 제한 속도라고 생각하라. ‘너무 큰’단계나 작업은 하지 않게 될 것이다.
- 불확실한 미래에 대비한 설계를 하느라 진을 빼는 대신 언제나 교체 가능한 코드를 작성하여 대비하면 된다. 여러분의 코드를 더 적절한 무언가로 대체하기 쉽게 설계하라. 코드를 교체할 수 있도록 하면 응집도나 결합도, DRY에도 도움이 되고, 전반적으로 더 나은 설계가 탄생할 것이다.
Loading