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장: 실용주의 편집증 #26

Merged
merged 1 commit into from
Aug 15, 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
89 changes: 89 additions & 0 deletions 4장/오혜성.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,89 @@
# 실용주의 편집증
* 완벽한 소프트웨어는 만들 수 없다
+ 지금까지 없었고, 처음이 너라고 생각이 들지도 않음 ㅋ

* 실용주의 프로그래머는 자기 자신 역시 믿지 않음
+ 그렇기에 방어적으로 코드를 작성

## 계약에 의한 설계

* 사람의 문제를 해결하기 위한 방법이 소프트웨어에도 적용할 수 있는데
+ 그 중 하나가 계약이다

* 정확한 프로그램은 스스로 자신이 하는 일이라고 주장하는 것보다 많거나 적지도 않게 딱 그만큼만 하는 프로그램
+ 이 주장을 문서화하고 검증하는 것이 계약에 의한 설계의 핵심

* 제대로 된 데이터를 전달하는 것은 호출하는 쪽의 책임이다

* 무슨 일이 벌어지든지 간에 계약에 부응하지 못하는 게 버그가 되어버리는 실수는 저지르지 마라
+ 에러 핸들링

* 게으른 코드
+ 시작하기 전에 자신이 수용할 것에 대해서는 염격하게 하고
+ 내어줄 것에 대해서는 최소한도를 약속하자

* 전처리기
+ 찾아내지 못했을 문제를 발견하기 위해
> zod, 테스트 코드가 생각남
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

zod 어느정도로 사용하고 계신지 궁금해요 💭

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

저는 주로 타입을 확신 할 수 없을 때 사용해요!

ex) form, api response

가장 활발히 사용하고 있는 부분은 api response의 타입을 검증해서 .. 만약 클라이언트에서 선언한 타입과 다를 시 로깅을 남기도록 .. 하고 있심니다


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

* 일반적으로 죽은 프로그램이 입히는 피해는 절름발이 프로그램이 끼치는 것보다 덜한 법이다

> 제가 입사하기 전에... 저희 회사는 ...
> axios 인터셉터에서 에러가 에러를 던지지 않도록 설정되어 있었어요
>
> 그래서 .. query의 onError 같은 동작이 작동하지 않던 .. 그런 .. 상태였는데요
> '에러 마주보기' 라는 이름의 프로젝트로 전면 수정했던 경험이 있습니다..
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

멋지네요 👍🏻

> 여러분들의 회사는 어떻게 에러를 마주하고 있는지 궁금하네요
>
> 그리고 에러와 예외를 구분하는지?

## 단정적 프로그래밍

* "하지만 물론 그건 절대 일어나지 않을 거야"라는 생각이 든다면, 그걸 확인하는 코드를 추가하라
+ 단정은 결코 일어나면 안되는 것들을 검사한다

* 디버깅 행위가 디버깅되는 시스템의 행동을 바꿔버리는 '하이젠버그'적인 문제
+ 하이젠베르크를 영어식으로 발음할 때에 착안

> 테스트의 숙련도가 높지 않으면, 테스트를 위해 구현체를 바꾸는 경험이 종종 생기는 거 같은데
> 이는 좋은 변화일지? 아니면 하이젠버그적인 문제일지?
> > 물론 뭘 바꾸냐에 따라 다르지만...
> next 컴파일러 옵션에서 data-testid 핸들링 예시: https://github.com/depromeet/na-lab-client/blob/13c0a9e89079bfa0fd8f4d2089db0d9819a299b1/next.config.js#L21-L29
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

단축평가로 맛깔나게 처리하셨군요 👍🏻


* 연습문제
+ 한 달이 28일보다 적은 것
+ 내각의 합이 180도가 아닌 삼각형
+ 60초가 아닌 1분

> 결국 불가능하다 생각해도, 불가능하지 않은 거란 뜻인가?

## 언제 예외를 사용할까

* 가능한 에러를 체크하는 것이 좋겠지만
+ 실제로 이렇게 하다보면 코드가 꽤 지저분해진다
+ 프로그램의 정상적 로직이 에러 처리에 완전히 묻혀 잘 보이지 않게 될 수 있다
+ 모든 에러 처리가 한 장소로 옮겨지면 정상적인 흐름이 명확히 보인다

> 선언적이라는 키워드 그리고 리액트가 지향하는 방법이라 생각이 듦
> Suspense, ErrorBoundary
Comment on lines +69 to +70
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

선언적 프로그래밍에 엄청난 도움을 주는 녀석들이지만.. 아직도 라이브러리에 의존적이라는게 아쉬울 뿐입니다..


* 예외와 에러는 경우에 따라 다르다
+ 꼭 있어야 하는 경우 -> 예외
+ 없어도 이상하지 않다 -> 에러

* 예외는 예외적인 문제에 사용하라
+ 그렇지 않다면 가독성, 관리성, 결합도가 문제가 될 수 있음

## 리소스 사용의 균형

* 시작한 것은 끝내라
> 열었으면 닫아라
> 책임을 다해라?

* 실용주의 프로그래머는 자신을 포함해 아무도 믿지 않음
+ 정말로 리소스가 적절하게 해제되었는지 점검하는 코드를 늘 작성하는 것이 좋다고 생각

> 현대의 후롱트엔드 개발자가 리소스를 닫을 일은 무엇이 있을까요
> 이벤트 리스너 삭제하기? timeout, interval 해제하기? 소켓 닫기?
Loading