p.50~62 함수 호출 - 메소드 호출 패턴, 함수 호출 패턴, 생성자 호출 패턴, apply 호출 패턴. this가 각각 어떻게 바인딩 되느냐. 함수 호출 패턴의 경우에 전역 객체에 this가 바인딩 되는 것은 설계상의 오류, 원래 상위 this에 바인딩이 되어야 한다. 객체에서 내부 함수를 사용하는 경우에는 ES6 이전에는 var that = this; 와 같이 사용했다. arguments, 유사 배열 객체. 예외 - throw, try/catch
~p.50 읽어보고 싶어서 중고로 구해서 읽어봤다. ES6 이전의 내용을 다루다보니 그래 2023년에는 이런것도 생겼다고! 하면서 보게 된다. 블록 주석은 정규 표현식과 겹칠 수 있어서 사용을 권하지 않는다. 자바스크립트 내의 모든 문자는 16비트 유니코드. Object.prototype.hasOwnProperty로 객체 본인의 프라퍼티를 구분할 수 있다.
p.146~156 JAVA 코드여도 재밌게 잘 읽혀서 좋다. 메서드의 주요 속성을 파악하여 jqwik 테스트에 포함시킨다. 간단한 코드를 작성해서 다양한 속성값들을 무작위로 선택하여 테스트 할 수 있는 장점.
p.136~146 예외가 발생했을 때, 클라이언트가 다루는 방법을 모른다면 예외를 던진다. 예외보다는 클라이언트에 부드러운 값(런타임에 터지지 않는)을 전달할 수도 있다. 유효성 검사는 자동 테스트, 사전 조건은 비즈니스 로직을 다루는 테스트에 의해 수행. 속성 기반 테스트, jqwik과 같은 프레임워크 좋아보인다!
p.127~136 계약 변경이 일어나면, 의존성을 살펴봄으로써 영향을 파악할 수 있다. 사전 조건과 사후 조건이 강화되냐, 약화되냐에 따라 계약이 깨진다. 리스코프 치환 법칙, LSP 강한 사전 조건과 약한 사전 조건, 트레이드오프가 있다. 입력 유효성 검사와 계약. 중복은 없애는 게 좋다.
(책이 없어서 리액트 공식문서 읽기) 똑같은 로직을 여러 컴포넌트에서 사용해야 할 때 커스텀 훅을 사용한다. use prefix 컨벤션이 있고, 다른 hook을 사용하거나, 앞으로 hook을 사용할 예정인 함수에 붙인다. 중요한 것은 state를 공유하는 것이 아니라, 로직을 공유하는 것이다. 훅은 컴포넌트가 리렌더링 될 때마다 재실행된다. useMount, useEffectOnce와 같은 커스텀 라이프사이클 훅은 리액트 패러다임에 맞지 않는다.
p.116~127 계약에 의한 설계. 사전 조건(메서드가 받아들인 입력값 검증), 사후 조건(메서드가 다른 메서드에 약속한 것을 반환하도록 보장) 단언 키워드, assert. 강한 조건과 약한 조건. 불변식, 생명주기 전체에서 유지되어야 하는 것.
p.100~115 100%의 테스트 커버리지가 시스템을 제대로 테스트했다는 것은 아니지만, 커버리지가 매우 낮다는 것은 시스템이 제대로 테스트되지 않았다는 것이다. 어떤 커버리지 기준을 사용할 것인지 결정. 돌연변이 테스트는 일부러 버그를 주입에서 테스트가 깨지는지 확인한다. 비용은 비싸지만 유익하다.
