From ef8d0bb0c0f7f15758cde125efce7e6bb8b382d1 Mon Sep 17 00:00:00 2001 From: Orchemi Date: Tue, 13 Aug 2024 22:18:36 +0900 Subject: [PATCH] =?UTF-8?q?Docs:=20=EB=B3=80=EC=88=98=EB=AF=B8=204?= =?UTF-8?q?=EC=9E=A5?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../\353\263\200\354\210\230\353\257\270.md" | 37 +++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 "4\354\236\245/\353\263\200\354\210\230\353\257\270.md" diff --git "a/4\354\236\245/\353\263\200\354\210\230\353\257\270.md" "b/4\354\236\245/\353\263\200\354\210\230\353\257\270.md" new file mode 100644 index 0000000..be26b73 --- /dev/null +++ "b/4\354\236\245/\353\263\200\354\210\230\353\257\270.md" @@ -0,0 +1,37 @@ +### 계약에 의한 설계 + +- DBC는 단순하지만 강력한 기법으로, 프로그램의 정확성을 보장하기 위해 소프트웨어 모듈의 권리와 책임을 문서화하고 합의하는 데에 초점을 맞춘다. + > 사실 잘 이해못했어요.. +- ‘게으름뱅이lazy’ 코드를 강조하고 싶다. 시작하기 전에 자신이 수용할 것은 엄격하게 확인하고, 내어 줄 것에 대해서는 최소한도를 약속하는 것이다. + +- 코드를 작성하기 전에 유효한 입력 범위가 무엇인지, 경계 조건이 무엇인지, 루틴이 뭘 전달한다고 약속하는지, 혹은 더 중요하게는 무엇을 약속하지 않는지 등을 나열하는 것만으로도 더 나은 소프트웨어를 작성하는 데에 엄청난 도움이 된다. +- 단정문이나 DBC 방식을 사용하여 선행 조건과 후행 조건, 불변식을 검증하면 더 일찍 멈추고, 문제에 대한 보다 정확한 정보를 알려줄 수 있을 것이다 + +> 읽으면서 앞으로 인지하면서 개발을 해봐야지.. 하고 생각했습니다 + +### 죽은 프로그램은 거짓말을 하지 않는다. + +- 실용주의 프로그래머는 만약 오류가 발생했다면 정말로 뭔가 나쁜 일이 생긴 것이라고 자신에게 이야기한다. 일단 그놈의 오류 메시지 좀 읽어라. + 가능한 한 빨리 문제를 발견하면 좀 더 일찍 시스템을 멈출 수 있으니 더 낫다. + +> 맞아요 😂 하지만 콘솔에 뜨는 에러를 봐도 내일의 저한테 자꾸 미루게 되네요 + +### 단정적 프로그래밍 + +- 단정문으로 불가능한 상황을 예방하라 +- ‘하지만 물론 그런 일은 절대 일어나지 않을 거야.’라는 생각이 든다면 그런 일을 확인하는 코드를 추가하라. 가장 간단하게 추가하는 방법은 단정문assertion을 사용하는 것이다. +- 프로그램을 출시할 때 단정 기능을 꺼 버리는 것은 줄타기 곡예를 하면서 연습으로 한 번 건너 봤다고 그물 없이 건너는 것과 비슷하다. 극적인 가치야 있겠지만 생명 보험을 들기는 어렵다. 성능 문제가 있다 하더라도 정말 문제가 되는 단정문만 끄도록 하자. + +> 단정문때문에 페이지가 터지지않는다면 쓰는게 이상적인것 같아요, 그런데 자바스크립트를 사용하는데도 권장하는 방식인가요? 쓰는걸 잘 못본것 같아요 + +### 리소스 사용의 균형 + +- 지역적으로 행동하라. 잘 모르겠을 땐 언제나 스코프를 줄이는 편이 낫다. +- 리소스를 할당한 순서의 역순으로 해제하라. 이렇게 해야 한 리소스가 다른 리소스를 참조하는 경우에도 참조를 망가트리지 않는다. +- 코드의 여러 곳에서 동일한 구성의 리소스들을 할당하는 경우에는 언제나 + 같은 순서로 할당해야 교착deadlock 가능성을 줄일 수 있다. + +### 헤드라이트를 앞서가지 말라 + +- 언제나 신중하게 작은 단계들을 밟아라. 더 진행하기 전에 피드백을 확인하고 조정하라. 피드백의 빈도를 여러분의 제한 속도라고 생각하라. ‘너무 큰’단계나 작업은 하지 않게 될 것이다. +- 불확실한 미래에 대비한 설계를 하느라 진을 빼는 대신 언제나 교체 가능한 코드를 작성하여 대비하면 된다. 여러분의 코드를 더 적절한 무언가로 대체하기 쉽게 설계하라. 코드를 교체할 수 있도록 하면 응집도나 결합도, DRY에도 도움이 되고, 전반적으로 더 나은 설계가 탄생할 것이다.