Skip to content

Commit

Permalink
4장 (#39)
Browse files Browse the repository at this point in the history
  • Loading branch information
Seojunhwan authored Aug 19, 2024
1 parent 631ae46 commit e4c7e12
Showing 1 changed file with 92 additions and 0 deletions.
92 changes: 92 additions & 0 deletions 4장/서준환.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,92 @@
# 실용주의 편집증

> ash island의 paranoid를 들으며 , , ,
> gpt왈
>
>편집증(偏執症)은 정신 건강 분야에서 사용되는 용어로, 비합리적이고 근거 없는 의심과 불신을 특징으로 하는 정신 상태를 말합니다. 프로그래밍 맥락에서 '실용주의 편집증'이라는 표현은 코드의 안정성과 신뢰성을 높이기 위해 건전한 의심과 주의를 기울이는 태도를 의미합니다.
>
>프로그래머로서 편집증적 접근은 다음과 같은 의미를 가질 수 있습니다:
>
>1. 코드 검증: 자신의 코드를 항상 의심하고 철저히 테스트합니다.
>2. 보안 의식: 잠재적인 보안 위협을 항상 염두에 둡니다.
>3. 오류 예방: 발생 가능한 모든 오류 상황을 고려하고 대비합니다.
>4. 지속적인 개선: 코드의 품질을 끊임없이 향상시키려고 노력합니다.
>
>이러한 '실용주의 편집증'은 소프트웨어의 품질을 높이는 데 도움이 될 수 있습니다.
우선 단정짓고 가시죠. "우리는 완벽한 소프트웨어를 만들 수 없다."

실용주의 프로그래머는 자기 자신도 믿지 않는다.


왜 why? 우리는 완벽한 소프트웨어를 만들 수 없으니까.

<br/>

DBC 이건 어렵네요.

코드를 작성하기 전에 유효한 입력 범위가 무엇인지, 경계 조건인지, 루틴이 뭘 전달한다고 약속하는지, 혹은 더 중요하게는 무엇을 약속하지 않는지 등을 나열하는 것만으로도 도움이 된다.

> 똥코드 작성하기 전에 미리 생각하고 작성하자.
## 죽은 프로그램은 거짓말을 하지 않는다

모든 오류는 정보를 준다.

"오류가 발생할 리 없다"는 생각은 갖다 버리자.

제발 오류 메시지를 잘 읽어보자.

> 생각해보면 라이브러리단에서도 에러 처리할 때 메시지가 명확한 라이브러리가 있는 반면 그렇지 않은 라이브러리들도 있었던 것 같아요.
>
> 만드시는 라이브러리가 있다면 오류 처리는 어떻게 해주고 계시나요? 저는 `suspensive` 이 라이브러리의 오류 처리 참고해서 처리 하는 중입니다.
### 잡은 후 그냥 놓아주는 것은 물고기뿐

함수 내부에선 에러를 catch 하고 다시 throw 하지 않는다.

첫번째 이유는 애플리케이션 코드가 오류 처리 코드 사이에 묻히지 않아 가독성을 높혀준다.

두번째 이유는 해당 함수 내부에서 일어나는 모든 예외를 처리해 주어야 하고, 추가된다면 해당 throw에서도 추가해줘야 한다.

> 보통 어떻게 처리하세요?
### 망치지 말고 빨리 멈춰라

읽어보니 이 부분은 적당히 가능한 부분에서는 쓸모가 있어보이더라구요!

죽은 프로그램이 끼치는 피해는 이상한 상태의 프로그램이 끼치는 피해보다 훨씬 적다는 듣다보면 맞는 느낌이 드네요.

## 단정적 프로그래밍

"그런 일을 절대 일어날 리 없어" 라는 플래그를 심지 말자.

사실 그런 일이 안 일어났으면 좋겠다는 마음 또는 생각이 아닐까 싶다.

assert는 자바스크립트 브라우저에는 없어서 (web-worker는 있어요) 만들어 사용해야 한다. (토스꺼 보고 뭐,, 스윽)

### 단정과 부작용

하이젠버그적인 문제 메모..

> 개발자 만났을 때 아이스브레이킹 주제 , ,
## 리소스 사용의 균형

아아,, 리소스 해제는 자주 까먹는 부분인데,, clearInterval, unobserve와 같은 거 잘 써야겠네요,,

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

알쓸신잡 +1

짧게 짧게 피드백을 받고, 그걸 통해 앞을 내다보자.

이를테면 테스트 코드, 유저 테스트 등 여러 방법이 있지 않을까?

> 기획이 그렇게 오면 싸워야하나
우리는 미래의 유지 보수를 고려해서 설계해야하지만, 우리가 볼 수 있는 미래까지만 고려해야한다.

> 어느정도 반성을 하게끔 만드는 문장입니다 , , 늘 미래를 바라봤었는데 잘못된 방향이었을 수도 있다는 생각이 드네요.

0 comments on commit e4c7e12

Please sign in to comment.