From a171a4844565a6ec315f2a8b756282a8539de310 Mon Sep 17 00:00:00 2001 From: hyesungoh Date: Sun, 4 Aug 2024 01:06:00 +0900 Subject: [PATCH] =?UTF-8?q?4=EC=9E=A5=20=EC=98=A4=ED=98=9C=EC=84=B1?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../\354\230\244\355\230\234\354\204\261.md" | 89 +++++++++++++++++++ 1 file changed, 89 insertions(+) create mode 100644 "4\354\236\245/\354\230\244\355\230\234\354\204\261.md" diff --git "a/4\354\236\245/\354\230\244\355\230\234\354\204\261.md" "b/4\354\236\245/\354\230\244\355\230\234\354\204\261.md" new file mode 100644 index 0000000..86312bc --- /dev/null +++ "b/4\354\236\245/\354\230\244\355\230\234\354\204\261.md" @@ -0,0 +1,89 @@ +# 실용주의 편집증 +* 완벽한 소프트웨어는 만들 수 없다 + + 지금까지 없었고, 처음이 너라고 생각이 들지도 않음 ㅋ + +* 실용주의 프로그래머는 자기 자신 역시 믿지 않음 + + 그렇기에 방어적으로 코드를 작성 + +## 계약에 의한 설계 + +* 사람의 문제를 해결하기 위한 방법이 소프트웨어에도 적용할 수 있는데 + + 그 중 하나가 계약이다 + +* 정확한 프로그램은 스스로 자신이 하는 일이라고 주장하는 것보다 많거나 적지도 않게 딱 그만큼만 하는 프로그램 + + 이 주장을 문서화하고 검증하는 것이 계약에 의한 설계의 핵심 + +* 제대로 된 데이터를 전달하는 것은 호출하는 쪽의 책임이다 + +* 무슨 일이 벌어지든지 간에 계약에 부응하지 못하는 게 버그가 되어버리는 실수는 저지르지 마라 + + 에러 핸들링 + +* 게으른 코드 + + 시작하기 전에 자신이 수용할 것에 대해서는 염격하게 하고 + + 내어줄 것에 대해서는 최소한도를 약속하자 + +* 전처리기 + + 찾아내지 못했을 문제를 발견하기 위해 + > zod, 테스트 코드가 생각남 + +## 죽은 프로그램은 거짓말을 하지 않는다 + +* 일반적으로 죽은 프로그램이 입히는 피해는 절름발이 프로그램이 끼치는 것보다 덜한 법이다 + +> 제가 입사하기 전에... 저희 회사는 ... +> axios 인터셉터에서 에러가 에러를 던지지 않도록 설정되어 있었어요 +> +> 그래서 .. query의 onError 같은 동작이 작동하지 않던 .. 그런 .. 상태였는데요 +> '에러 마주보기' 라는 이름의 프로젝트로 전면 수정했던 경험이 있습니다.. +> 여러분들의 회사는 어떻게 에러를 마주하고 있는지 궁금하네요 +> +> 그리고 에러와 예외를 구분하는지? + +## 단정적 프로그래밍 + +* "하지만 물론 그건 절대 일어나지 않을 거야"라는 생각이 든다면, 그걸 확인하는 코드를 추가하라 + + 단정은 결코 일어나면 안되는 것들을 검사한다 + +* 디버깅 행위가 디버깅되는 시스템의 행동을 바꿔버리는 '하이젠버그'적인 문제 + + 하이젠베르크를 영어식으로 발음할 때에 착안 + +> 테스트의 숙련도가 높지 않으면, 테스트를 위해 구현체를 바꾸는 경험이 종종 생기는 거 같은데 +> 이는 좋은 변화일지? 아니면 하이젠버그적인 문제일지? +> > 물론 뭘 바꾸냐에 따라 다르지만... +> next 컴파일러 옵션에서 data-testid 핸들링 예시: https://github.com/depromeet/na-lab-client/blob/13c0a9e89079bfa0fd8f4d2089db0d9819a299b1/next.config.js#L21-L29 + +* 연습문제 + + 한 달이 28일보다 적은 것 + + 내각의 합이 180도가 아닌 삼각형 + + 60초가 아닌 1분 + +> 결국 불가능하다 생각해도, 불가능하지 않은 거란 뜻인가? + +## 언제 예외를 사용할까 + +* 가능한 에러를 체크하는 것이 좋겠지만 + + 실제로 이렇게 하다보면 코드가 꽤 지저분해진다 + + 프로그램의 정상적 로직이 에러 처리에 완전히 묻혀 잘 보이지 않게 될 수 있다 + + 모든 에러 처리가 한 장소로 옮겨지면 정상적인 흐름이 명확히 보인다 + +> 선언적이라는 키워드 그리고 리액트가 지향하는 방법이라 생각이 듦 +> Suspense, ErrorBoundary + +* 예외와 에러는 경우에 따라 다르다 + + 꼭 있어야 하는 경우 -> 예외 + + 없어도 이상하지 않다 -> 에러 + +* 예외는 예외적인 문제에 사용하라 + + 그렇지 않다면 가독성, 관리성, 결합도가 문제가 될 수 있음 + +## 리소스 사용의 균형 + +* 시작한 것은 끝내라 + > 열었으면 닫아라 + > 책임을 다해라? + +* 실용주의 프로그래머는 자신을 포함해 아무도 믿지 않음 + + 정말로 리소스가 적절하게 해제되었는지 점검하는 코드를 늘 작성하는 것이 좋다고 생각 + +> 현대의 후롱트엔드 개발자가 리소스를 닫을 일은 무엇이 있을까요 +> 이벤트 리스너 삭제하기? timeout, interval 해제하기? 소켓 닫기? \ No newline at end of file