diff --git "a/4\354\236\245/\354\204\234\354\244\200\355\231\230.md" "b/4\354\236\245/\354\204\234\354\244\200\355\231\230.md" new file mode 100644 index 0000000..33cfd9f --- /dev/null +++ "b/4\354\236\245/\354\204\234\354\244\200\355\231\230.md" @@ -0,0 +1,92 @@ +# 실용주의 편집증 + +> ash island의 paranoid를 들으며 , , , + +> gpt왈 +> +>편집증(偏執症)은 정신 건강 분야에서 사용되는 용어로, 비합리적이고 근거 없는 의심과 불신을 특징으로 하는 정신 상태를 말합니다. 프로그래밍 맥락에서 '실용주의 편집증'이라는 표현은 코드의 안정성과 신뢰성을 높이기 위해 건전한 의심과 주의를 기울이는 태도를 의미합니다. +> +>프로그래머로서 편집증적 접근은 다음과 같은 의미를 가질 수 있습니다: +> +>1. 코드 검증: 자신의 코드를 항상 의심하고 철저히 테스트합니다. +>2. 보안 의식: 잠재적인 보안 위협을 항상 염두에 둡니다. +>3. 오류 예방: 발생 가능한 모든 오류 상황을 고려하고 대비합니다. +>4. 지속적인 개선: 코드의 품질을 끊임없이 향상시키려고 노력합니다. +> +>이러한 '실용주의 편집증'은 소프트웨어의 품질을 높이는 데 도움이 될 수 있습니다. + +우선 단정짓고 가시죠. "우리는 완벽한 소프트웨어를 만들 수 없다." + +실용주의 프로그래머는 자기 자신도 믿지 않는다. + + +왜 why? 우리는 완벽한 소프트웨어를 만들 수 없으니까. + +
+ +DBC 이건 어렵네요. + +코드를 작성하기 전에 유효한 입력 범위가 무엇인지, 경계 조건인지, 루틴이 뭘 전달한다고 약속하는지, 혹은 더 중요하게는 무엇을 약속하지 않는지 등을 나열하는 것만으로도 도움이 된다. + +> 똥코드 작성하기 전에 미리 생각하고 작성하자. + +## 죽은 프로그램은 거짓말을 하지 않는다 + +모든 오류는 정보를 준다. + +"오류가 발생할 리 없다"는 생각은 갖다 버리자. + +제발 오류 메시지를 잘 읽어보자. + +> 생각해보면 라이브러리단에서도 에러 처리할 때 메시지가 명확한 라이브러리가 있는 반면 그렇지 않은 라이브러리들도 있었던 것 같아요. +> +> 만드시는 라이브러리가 있다면 오류 처리는 어떻게 해주고 계시나요? 저는 `suspensive` 이 라이브러리의 오류 처리 참고해서 처리 하는 중입니다. + +### 잡은 후 그냥 놓아주는 것은 물고기뿐 + +함수 내부에선 에러를 catch 하고 다시 throw 하지 않는다. + +첫번째 이유는 애플리케이션 코드가 오류 처리 코드 사이에 묻히지 않아 가독성을 높혀준다. + +두번째 이유는 해당 함수 내부에서 일어나는 모든 예외를 처리해 주어야 하고, 추가된다면 해당 throw에서도 추가해줘야 한다. + +> 보통 어떻게 처리하세요? + +### 망치지 말고 빨리 멈춰라 + +읽어보니 이 부분은 적당히 가능한 부분에서는 쓸모가 있어보이더라구요! + +죽은 프로그램이 끼치는 피해는 이상한 상태의 프로그램이 끼치는 피해보다 훨씬 적다는 듣다보면 맞는 느낌이 드네요. + +## 단정적 프로그래밍 + +"그런 일을 절대 일어날 리 없어" 라는 플래그를 심지 말자. + +사실 그런 일이 안 일어났으면 좋겠다는 마음 또는 생각이 아닐까 싶다. + +assert는 자바스크립트 브라우저에는 없어서 (web-worker는 있어요) 만들어 사용해야 한다. (토스꺼 보고 뭐,, 스윽) + +### 단정과 부작용 + +하이젠버그적인 문제 메모.. + +> 개발자 만났을 때 아이스브레이킹 주제 , , + +## 리소스 사용의 균형 + +아아,, 리소스 해제는 자주 까먹는 부분인데,, clearInterval, unobserve와 같은 거 잘 써야겠네요,, + +## 헤드라이트를 앞서가지 말라 + +알쓸신잡 +1 + +짧게 짧게 피드백을 받고, 그걸 통해 앞을 내다보자. + +이를테면 테스트 코드, 유저 테스트 등 여러 방법이 있지 않을까? + +> 기획이 그렇게 오면 싸워야하나 + +우리는 미래의 유지 보수를 고려해서 설계해야하지만, 우리가 볼 수 있는 미래까지만 고려해야한다. + +> 어느정도 반성을 하게끔 만드는 문장입니다 , , 늘 미래를 바라봤었는데 잘못된 방향이었을 수도 있다는 생각이 드네요. +