이펙티브 자바스크립트 (데이비드 허먼)

1장 자바스크립트에 익숙해지기

__아이템 1 어떤 자바스크립트를 사용하고 있는지 알아야 한다

• ​애플리케이션이 지원할 자바스크립트의 버전을 정하라
• 항상 스트릭트 모드 확인을 수행하는 최신 브라우저 환경에서 스트릭트 코드를 테스트하라

__아이템 2 자바스크립트의 부동 소수점 숫자 이해하기

• ​자바스크립트의 숫자는 double 정확도의 부동 소수점 숫자다
• 자바스크립트의 정수는 별개의 데이터형이 아니라 double의 부분집합이다
• 비트단위 연산자는 숫자를 32비트의 부호가 있는 integer처럼 처리한다
• 부동 연수점 산술 연산의 정확도의 한계가 있음을 주의해야 한다

__아이템 3 암묵적인 형변환을 주의하라

• ​데이터형 에러는 암묵적인 강제 형변환에 의해 은밀하게 감춰질 수 있다
• + 연산자는 인자의 데이터형에 따라 덧셈이나 문자형 병합으로 오버로딩된다
• 객체는 ValueOf를 통해 숫자형으로, toString을 통해 문자열로 강제 형변환된다
• ValueOf 메서드를 가지는 객체는 반드시 valueOf 에 의해 생성되는 숫자 값의 문자열 표현을 생성하는 toString메서드를 구현해야 한다
• undefined 값을 테스트할 때 트루시니스(truthiness)를 사용하기보다는 typeof를 사용하거나 undefined와 비교하는 것이 좋다

__아이템 4 객체 래퍼보다 원시 데이터형을 우선시하라

• ​객체와 함께, 자바스크립트는 다섯 가지의 원시 데이터형 값을 가진다. 불리언, 숫자, 문자열, null 그리고 undefined다
• 객체 래퍼는 그 자신의 원시 데이터 값과는 동작이 다르다. 동일한지 비교했을 때도 서로 다르다

__아이템 5 혼합된 데이터형을 ==로 비교하지 마라

• ​== 연산자는 인자들이 서로 다른 데이터형일 때, 일련의 혼동스러운 암묵적인 강제 형변환을 적용시킨다
• 비교가 어떠한 암묵적인 강제 형변환과도 연관이 없다는 사실을 코드를 읽는 사람에게 명확하게 전달하기 위해서 ===를 사용하라
• 비교할 값이 서로 다른 데이터형이라면 프로그램의 동작을 더 명백히 하기 위해 직접 명시적인 강제 형변환을 사용하라

__아이템 6 세미콜론 삽입의 한계에 대해서 알아두자

 

__아이템 7 문자열을 16비트 코드 단위의 시퀀스로 간주하라

• ​자바스크립트 문자열은 유니코드 코드 포인트가 아니라 16비트 코드 유닛으로 구성된다
• 자바스크립트에서 유니코드 코드 포인트 2의 16승 이상은 대리 쌍이라고 알려진 두 개의 코드 유닛으로 표현한다
• 대리 쌍은 문자열 요소의 개수를 반환하고, length, chatAt, charCodeAt 메서드와 "."같은 정규 표현식 패턴에 영향을 끼친다
• 코드 포인트를 다루는 문자열 조작을 하기 위해서는 서드파티 라이브러리를 사용하라 

2장 변수 스코프

__아이템 8 전역 객체의 사용을 최소화하라

• ​전역 변수를 선언하지 마라
• 가능하면 변수를 지역적으로 선언하라
• 전역 객체에 프로퍼티를 추가하지 마라
• 플랫폼의 기능 탐지를 위해 전역 객체를 사용하라

__아이템 9 항상 지역 변수를 선언하라

• ​새로운 지역 변수는 항상 var를 사용해서 선언하라
• 바인딩되지 않은 변수를 확인하는 데 도움을 주는 lint 도구의 사용을 고려해 보라

__아이템 10 with를 사용하지 마라

• ​with 선언문을 사용하지 마라

__아이템 11 클로저에 익숙해져라

• ​함수는 외부 스코프에 선언된 변수를 참조할 수 있다
• 클로저는 자신을 생성한 함수보다 더 오래 지속된다
• 클로저는 내부적으로 외부 변수에 대한 참조를 저장하고, 저장된 변수를 읽고 갱신할 수 있다

__아이템 12 변수 호이스팅에 대해 이해하라

• ​블록 내에서의 변수 선언은 암묵적으로 그 변수를 포함하는 함수의 맨 윗부분으로 호이스팅된다
• 변수의 재선언은 하나의 변수처럼 처리된다

__아이템 13 지역 변수 스코프를 만들기 위해 즉시 실행 함수 표현식을 사용하라

• ​클로저는 외부 변수의 값이 아닌 참조를 저장한다
• 지역 스코프를 만들기 위해 즉시 실행 함수 표현식을 사용하라
• IIFE(immediately invoked function expression)에서 블록으로 감쌌을 때 변화하는 상황에 주의하라

__아이템 14 기명 함수 표현식의 스코프에 주의하라

• ​ES5를 제대로 구현한 실행 환경에 배포한다면, 아무런 걱정을 할 필요가 없다

__아이템 15 블록-지역 함수 선언문의 스코프에 주의하라

• ​실행 환경에 따라 다르게 동작할 수 있는 여지가 있으므로, 함수 선언문은 이를 포함하는 함수나 프로그램의 가장 바깥에 두어라

__아이템 16 eval을 이용해 지역 변수를 생성하지 마라

__아이템 17 직접적인 eval보다 간접적인 eval을 사용하라

3장 함수 사용하기

__아이템 18 함수, 메서드, 생성자 호출의 차이를 이해하라

• ​메서드 호출은 메서드 프로퍼티를 찾을 객체, 즉 해당 호출을 받는 수신자 객체를 제공한다
• 함수 호출은 전역 객체(스트릭트 모드 함수에서는 undefined)를 수신자 객체로 규정한다. 메서드를 함수처럼 호출하는 문법은 별로 유용하지 않다

__아이템 19 고차 함수에 익숙해져라

• ​고차 함수는 다른 함수를 인자로 받거나 그 결과로 함수를 반환하는 함수다
• 이미 존재하는 라이브러리에 포함된 고차 함수의 사용에 익숙해져라
• 고차 함수로 대체할 수 있는 공통 코딩 패턴을 찾는 방법을 익혀라

__아이템 20 지정된 수신자 객체로 함수를 호출하기 위해 call 메서드를 사용하라

• ​수신자 객체로 함수를 호출하기 위해 call 메소드를 사용하라
• 주어진 객체에 존재하지 않을지도 모르는 메서드를 호출하기 위해 call 메서드를 사용하라
• 콜백을 위한 수신자 객체를 함께 받는 고차 함수를 정의하기 위해 call 매소드를 사용하라

__아이템 21 다른 개수의 인자로 함수를 호출하기 위해 apply를 사용하라

• ​계산된 배열 인자로 가변 인자 함수를 호출하기 위해 apply 메서드를 사용하라
• apply의 첫 번째 인자로 가변 인자 메서드를 위한 수신자 객체를 전달하라

__아이템 22 가변 인자 함수를 생성하기 위해 arguments를 사용하라

• ​가변 인자 함수를 구현하기 위해 암묵적인 arguments 객체를 사용하라
• 사용자가 apply 메소드를 사용할 필요가 없도록 고정 인자 버전의 가변 인자 함수를 추가로 제공하는 것을 고려하라

__아이템 23 절대 arguments 객체를 수정하지 마라

• ​arguments 객체를 절대로 수정하지 마라
• arguments 객체를 수정하기 전에 {}.slice.call(arguments)를 호출해 진짜 배열로 복사하라 ({} : 각괄호임)

__아이템 24 변수를 사용해 arguments의 참조를 저장하라

• ​arguments를 참조할 때 함수의 포함 관계에 주의하라
• 다른 함수 안의 감싸인 함수에서 arguments를 참조하려면, 명시적으로 스코프가 정해진 arguments의 참조를 바인딩하라

__아이템 25 고정된 수신자 객체로 메서드를 추출하기 위해 bind를 사용하라

• ​메서드 추출이 메서드의 수신자 객체를 해당 객체로 바인딩하지 않는다는 사실에 유의하라
• 객체의 메서드를 고차 함수로 전달할 때, 익명 함수를 사용해서 적절한 수신자 객체의 메서드로 호출할 수 있게 하라
• 적절한 수신자 객체로 바인딩되는 함수를 간단하게 만들기 위해 bind 메서드를 사용하라

__아이템 26 커링 함수에 bind를 사용하라

• ​함수를 그 인자의 부분집합으로 바인딩하는 기법은 논리학자 하스켈 커리(Haskel Curry)의 이름은 따 커링(curing)이라고 한다
• 함수를 커링하기 위해 bind를 사용하라. bind를 사용하면 필요한 인자의 고정된 부분집합을 가지는 위임 함수를 만들 수 있다
• 수신자 객체를 무시하는 함수를 커링할 때에는 수신자 객체 인자로 null이나 undefined를 전달하라

__아이템 27 코드를 캡슐화하기 위해 문자열보다 클로저를 사용하라

• ​eval로 실행되는 API에 전달한다면 문자열로 된 지역 변수를 절대 포함시키지 마라
• 문자열을 전달받아 eval하는 대신, 함수를 전달받아 호출하는 API를 사용하라

__아이템 28 함수의 toString 메서드에 의존하지 마라

• ​자바스크립트 엔진은 toString을 통해 함수 소스코드의 정확한 내용을 생성할 필요가 없다
• 함수 소스의 정확한 세부 사항에 절대로 의존하지 마라. 다른 엔진은 toString에 다른 결과를 만들어 낼 수 있기 때문이다
• toString의 결과는 클로저에 보관된 지역 변수의 값을 노출하지 않는다
• 일반적인 경우, 함수의 toString을 사용하지 마라

__아이템 29 비표준 스택 검사 프로퍼티를 사용하지 마라

• ​신뢰할 만한 이식성을 보장하지 않는 비표준 arguments.caller와 arguments.callee의 사용을 자제하라
• 스택의 전체 정보를 제대로 표현하지 않는 함수의 비표준 caller 프로퍼티를 사용하지 마라
  

4장 객체와 프로토타입

 

__아이템 30 prototype, getPrototypeOf, __proto__의 차이점을 이해하라

• ​C.prototype은 new C()로 생성된 객체의 프로토타입을 결정한다
• Object.getPrototypeOf(obj)는 객체의 프로토타입을 가져오기 위한 표준 ES5 함수이다
• obj.__proto__는 객체의 프로토타입을 가져오기 위한 비표준 메커니즘이다
• 클래스는 생성자 함수와 연관된 프로토타입으로 설계 패턴이다

 

__아이템 31 __proto__보다 Object.getPrototypeOf를 사용하라

• ​비표준 __proto__ 프로퍼티를 사용하기보다 표준을 준수하는 Object,getPrototypeOf를 사용하라
• __proto__를 지원하고 ES5를 지원하지 않는 실행 환경에 Object.getPrototypeOf를 구현하라

__아이템 32 __proto__를 절대 수정하지 마라

• ​객체의 __proto__ 프로퍼티를 절대 수정하지 마라
• 새로운 객체에 임의로 지정된 프로토타입을 제공하기 위해 Object.create를 사용하라

__아이템 33 생성자가 new와 관계 없이 동작하게 만들어라

• ​자기 자신을 new로 다시 호출하거나 Object.create를 사용해서 생성자가 호출자의 문법에 관계없이 동작할 수 있게하라
• 함수가 new로 호출되기를 기대한다면, 이에 대해 명백하게 문서화하라

__아이템 34 메서드를 프로토타입에 저장하라

• ​인스턴스 객체에 메서드를 저장하면 인스턴스 객체당 함수가 하나씩 복사되어, 여러 개가 복사된다
• 인스턴스 객체에 메서드를 저장하기보다 프로토타입에 메서드를 저장하라

__아이템 35 비공개 데이터를 저장하기 위해 클로저를 사용하라

• ​클로저 변수는 비공개이고, 지역적인 참조로만 접근할 수 있다
• 메서드 안에 강제로 정보를 숨기기 위해 비공개 데이터로써 지역 변수를 사용하라

__아이템 36 인스턴스의 상태는 인스턴스 객체에만 저장하라

• ​수정 가능한 데이터는 공유 시 문제의 소지가 있으며, 프로토타입은 모든 인스턴스간에 공유된다
• 각 인스턴스의 수정 가능한 상태 값은 인스턴스 객체에 저장하라

__아이템 37 this의 명시적인 바인딩에 대해 이해하라

• ​this의 스코프는 항상 가장 가까이서 둘러싼 함수에 의해 결정된다
• 내부 함수에서 this 바인딩을 사용할 수 있도록, 보통 self, me, that 같은 이름의 지역 변수를 사용하라

__아이템 38 서브 클래스 생성자에서 수퍼 클래스 생성자를 호출하라

• ​하위 클래스 생성자에서 상위 클래스 생성자를 명시적으로 호출하라. 이때 this를 명시적인 수신자 객체로 전달하라
• 상위 클래스 생성자를 호출하지 않기 위해 Object.create를 사용해 하위 클래스의 프로토타입 객체를 생성하라

__아이템 39 수퍼 클래스 프로퍼티 이름을 절대 재사용하지 마라

__아이템 40 표준 클래스를 상속하지 마라

• ​표준 클래스를 상속한다면 {{Class}}같은 특별한 내부 프로퍼티 때문에 오동작할 수 있다
• 표준 클래스를 상속하는 대신 프로퍼티로 위임하라

__아이템 41 프로토타입을 세부 구현 사항처럼 처리하라

__아이템 42 무모한 몽키 패칭을 하지 마라

• ​프로토타입은 객체로서 공유되기 때문에, 누구든지 프로토타입을 추가, 삭제하거나 수정할 수 있다. 이를 몽키 패칭(monkey-patching)이라고 부른다
• 무모한 몽키 패칭을 삼가라
• 라이브러리가 수행하는 모든 몽키 패칭에 대해 문서화하라
• 몽키 패칭을 선택적으로 가능하도록, 노출된 함수에서 변경을 실행하게 만드는 것을 고려하라
• 표준 API가 없는 경우에 폴리필(polyfill)을 제공하기 위해 몽키 패칭을 사용하라

 

5장 배열과 딕셔너리

__아이템 43 직접적인 객체의 인스턴스로 가벼운 딕셔너리를 만들어라

• ​객체 리터럴을 사용해 가벼운 딕셔너리를 만들어라

__아이템 44 프로토타입 오염을 막기 위해 null 프로토타입을 사용하라

• ​ES5에서는 Object.create(null)을 사용하여 프로토타입이 없고 오염에 덜 민감한 빈 객체를 생성하라
• 오래된 실행 환경에서는 {__proto__ : null}의 사용을 고려하라
• 하지만 __proto__가 비표준이고 이식성이 좋지 않으며 미래의 자바스크립트 환경에서 제거될 수 있다는 점에 주의하라

__아이템 45 프로토타입 오염을 막기 위해 hasOwnProperty를 사용하라 (예제를 참고할 필요가 있는 아이템!!)

• ​프로토타입의 오염을 막기 위해 hasOwnProperty를 사용하라
• hasOwnProperty 메서드의 오버라이딩을 막기 위해 어휘적인 스코프와 call 메서드를 사용하라
• 딕셔너리 연산들을 본문 내용 중에 설명한 has-메서드 같은 hasOwnProperty 테스트 상용문(boilerplate code)을 포함한 클래스로 구현하는 것을 고려하라
• "__proto__"가 키로 사용되는 것을 막기 위해 딕셔너리 클래스를 사용하라

__아이템 46 순서가 정해진 컬렉션에는 딕셔너리 대신 배열을 사용하라

• ​for...in 반복문이 객체의 프로퍼티를 열거할 때 순서에 의존하지 않도록 하라
• 딕셔너리 안의 데이터를 합한다면, 그 연산이 순서에 민감하지 않은지 확인하라
• 순서가 정해진 컬렉션을 위해서는 딕셔너리 객체 대신 배열을 사용하라

__아이템 47 Object.prototype에 열거 가능한 프로퍼티를 절대 추가하지 마라

__아이템 48 열거하는 동안 객체를 수정하지 마라

• ​for...in 반복문으로 객체의 프로퍼티를 열거하는 동안 객체를 수정하지 마라
• 반복문 내에서 내용이 변경될 수 있는 객체를 반복할 때는 for...in 대신 while이나 전통적인 for 반복문을 사용하라
• 데이터 구조가 변경될 수도 있는 열거에는, 딕셔너리 객체 대신에 배열 같은 순차적인 데이터 구조의 사용을 고려하라

__아이템 49 배열을 반복할 때 for...in 대신 for 반복문을 사용하라

• ​인덱스가 지정된 배열의 프로퍼티를 반복할 때는 항상 for...in 대신 for 반복문을 사용하라

__아이템 50 반복문 대신 반복 메서드를 사용하라

• ​코드를 더 가독성 높게 만들고 loop 제어 로직의 복제를 막기 위해서 for 반복문 대신에 Array.prototype.forEach와 Array.prototype.map과 같은 반복 메서드를 사용하라
• 표준 라이브러리가 제공하지 않는 공통적인 반복 패턴을 추상화하기 위해 사용자 정의 반복 함수를 사용하라
• 이른 종료가 필요한 경우에는 전통적인 반복문이 여전히 유용한데, 이를 위한 대안으로 some과 every 메서드를 사용할 수도 있다

__아이템 51 유사 배열 객체에 범용적인 배열 메서드를 재사용하라

• ​범용적인 Array 메서드들을 메서드 객체로 추출하고 call 메서드를 사용하여 유사 배열 객체에 재사용하라
• 어떤 객체든 인덱싱된 프로퍼티와 적절한 length 프로퍼티를 가진다면 범용적인 Array 메서드를 사용할 수 있다

__아이템 52 Array 생성자 대신 배열 리터럴을 사용하라

• ​Array 생성자는 첫 번째 인자가 숫자일 때 다르게 동작한다
• Array 생성자 대신에 배열 리터럴을 사용하라
  

6장 라이브러리와 API 설계

__아이템 53 일관된 컨벤션을 유지하라

__아이템 54 undefined를‘값 이 없는’것처럼 처리하라

• ​특정 값이 존재하지 않는다는 사실을 표현하는 경우를 제외하고는 undefined의 사용을 삼가하라
• 파라미터에 디폴트 값을 제공하기 위해 arguments.length를 확인하는 대신에 undefined를 테스트하라
• 트루니시스는 실제로 true나 false는 아니지만, 암묵적인 강제 형변환에 의해 true나 false처럼 처리되는 값을 말한다

__아이템 55 키워드 인자를 위해 옵션 객체를 받아들여라

• ​API를 가독성이 좋고 기억하기 좋게 만들기 위해 옵션 객체를 사용하라
• 옵션 객체로 전달되는 인자 모드는 반드시 부가적으로 처리되어야 한다
• extend 유틸리티 함수를 사용해 옵션 객체에서 값을 추출하는 로직을 추상화하라

__아이템 56 불필요한 상태 유지를 피하라

• ​가능하면 무상태 API를 유지하라

__아이템 57 유연한 인터페이스를 위해 구조화된 형식을 사용하라

• ​유연한 객체 인터페이스를 위해 구조적 타입 지정(덕 타입 지정, duck typing)을 사용하라
• 구조적 인터페이스가 더 우연하고 가볍다면 굳이 상속하지 마라

__아이템 58 배열과 유사 배열 객체를 구별하라

• ​다른 객체 타입으로 오버로딩할 때, 유사 배열 객체 대신에 진짜 배열을 받아들여라({}.slice.call(argumnet))
• API가 진짜 배열을 받아들이는지, 유사 배열 값을 받아들이는지 문서화하라

__아이템 59 과도한 강제 형변환을 피하라

• ​오버로딩과 강제 형변환을 섞어서 사용하지 마라
• 기대하지 않은 입력 값을 방어적으로 보호하라

__아이템 60 메서드 체이닝을 지원하라

7장 동시성

__아이템 61 이벤트 큐를 I/O에 블로킹시키지 마라

• ​비동기 API는 많은 비용이 드는 연산의 처리를 뒤로 미루기 위해 콜백을 받아서 메인 애플리케이션의 블로킹을 막는다
• 자바스크립트는 이벤트를 동시에 받아들이지만 이벤트 핸들러는 이벤트 큐를 사용해 순서대로 처리한다
• 애플리케이션의 이벤트 큐에서는 절대 블로킹 I/O를 사용하지 마라

__아이템 62 비동기 시퀀스를 위해 감싸지거나 이름이 지정된 콜백을 사용하라

• ​여러 개의 비동기 연산을 순서대로 수행하기 위해 감싸진 콜백이나 이름이 지정된 콜백 함수를 사용하라

__아이템 63 오류를 놓치지 않도록 조심하라

• ​오류 처리 코드를 복사하여 붙여 넣지 말고 공유된 오류 처리 함수를 작성하라
• 비동기 API를 다룰 때는 모든 오류 조건을 명시적으로 처리하는지 항상 경계하고 확인해야 한다

__아이템 64 비동기적인 반복문을 위해 재귀를 사용하라

• ​반복문은 비동기가 될 수 없다

__아이템 65 계산 중 이벤트 큐를 블로킹하지 마라

• ​메인 이벤트 큐에서 값비싼 알고리즘을 수행하지 마라
• 플랫폼에서 지원한다면, 복잡한 연산을 별도의 이벤트 큐에서 실행하는 데 워커 API를 사용할 수 있다
• 워커 API가 사용 불가능하거나 너무 비용이 많이 든다면, 계산을 이벤트 루프의 여러 턴으로 쪼개는 것을 고려하라

__아이템 66 동시성 연산을 수행하기 위해 카운터를 사용하라

• ​자바스크립트 애플리케이션에서 이벤트는 비결정론적으로, 즉 예측 불가능한 순서로 발생한다
• 동시 연산에서 데이터 경쟁을 피하기 위해서 카운터를 사용하라

__아이템 67 비동기 콜백을 절대 동기적으로 호출하지 마라

__아이템 68 더 깔끔한 비동기 로직을 위해 promise를 사용하라

• ​promise(deferred나 future로도 알려져 있다)는 최종적인 값, 즉 최종적으로 결과를 만들어 내는 동시적인 계산을 표현한다
• 서로 다른 여러 동시 연산들을 구성하기 위해 promise를 사용하라
• 데이터 경쟁을 피하기 위해 promise API를 사용하라
• 의도적인 경쟁 상태가 필요한 경우에는 select(또는 choose)를 사용하라

 

- 책 본문 중에서 -

[출처] 이펙티브 자바스크립트 (데이비드 허먼)|작성자 쪼쪼