'모던자바스크립트 Deep Dive' 를 읽으며 (5장~8장)

5장. 표현식과 문

🧐

'값'은 '표현식'이 평가되어 생성된 결과를 말한다.

 

var sum = 10 + 20

• 이 간단한 '문'은 '10' 과 '20' 이라는 숫자 '리터럴' 의 합이 '평가'되어 생성된 숫자 '값' 이 할당되는 '할당문'이다. 
• 값으로 평가될 수 없는 변수선언문과 같은 것들은 표현식인 문이 아니다.
• 간단한 문이라도 기본을 놓치지 말고 깊이있게 이해하려고 노력하자.

 

✅

문과 표현식을 구별하고 해석할 수 있다면 자바스크립트 엔진의 입장에서 코드를 읽을 수 있고
실행 결과를 예측하는 데 도움이 된다.
이는 버그를 줄이고 코드의 품질을 높여줄 것이다.

• 네!

 

🧐

자바스크립트 엔진이 소스코드를 해석할 때 문의 끝이라고 예측되는 지점에 세미콜론을 자동으로 붙여주는
세미콜론 자동 삽입 기능(ASI)이 암묵적으로 수행되기 때문에 생략가능하다.

• 책에서 나오는 사례를 보면, 자체 종결성 즉 세미콜론을 붙이지 않은채로 개발자가 자동 삽입 기능의 동작을 제대로 예측하지 못해 오류가 나는 사례를 알려주는데, 나였어도 오류를 냈을 법 한 사례였다.
• 얼마전에 회사 동료가 'js는 세미콜론 어짜피 붙여주는데 왜 붙여요!' 라고 조금 강하게 말하며 누군가의 코드를 리뷰하는걸 본 적이 있는데, 리뷰받는 사람도 '아! 그냥 붙일때도 있고 아닐때도 있고 그래요!' 하고 세미콜론을 지우는 걸 봤다.
  나는 주로 세미콜론을 붙이는 편인데, 그때는 딱히 동의도 반대도 하지 않는 내용이라 흘려서 들었었다. 하지만 또 비슷한 리뷰 기회가 오면 이런 케이스도 있다는걸 둘 다에게 말해줘야 할 것 같다.
• ESLint 와 같은 정적 분석 도구에서도 세미콜론 사용을 기본으로 설정하고 있고, TC39에서도 권장하는 내용이라 반드시 붙여야한다는 주장이 다수를 차지하는 것 같다. 

 

---

 

6장. 데이터 타입

 

✅

자바스크립트는 7개의 데이터 타입을 제공한다.
확보해야 할 메모리 공간의 크키도 다르고 메모리에 저장되는 2진수도 다르며
읽어 들여 해석하는 방식도 다르다.

 

 

✅

C나 자바의 경우 정수와 실수를 구분해서 다양한 숫자 타입을 제공한다. 
하지만 자바스크립트는 독특하게 하나의 숫자 타입만 존재한다.
자바스크립트의 숫자 타입은 정수만을 위한 타입이 없고 모든 수를 실수로 처리한다.

console.log(1===1.0); //true

 

 

✅

템플릿 리터럴은 ES6 부터 도입되었다.
백틱으로 감싸며 표현식을 삽입할 수 있고 이스케이프 시퀀스가 없이도 줄바꿈이 허용된다.

 

 

🧐

undefined 는 개발자가 의도적으로 할당하기 위한 값이 아니라
자바스크립트 엔진이 변수를 초기화 할 때 사용하는 값이다.
의도적으로 할당한다면 본래 취지와 어긋날뿐더러 혼란을 줄 수 있으므로
undefined를 할당하는 것이 아니라 null을 할당하는 것을 권장한다.
(의도적 부재, 참조 명시적 제거)

• undefined 를 할당의 목적으로 쓰는 코드는 아직까지 본 적이 없어서 다행이라는(?) 생각이 들었다.

 

✅

자바스크립트의 데이터 타입은 크게 원시 타입과 객체 타입으로 분류한다.
근본적으로 다르다는 의미이다.
11장에서 자세히 다룰 예정이고
자바스크립트를 이루는 거의 모든 것이 객체라는 사실만 기억하자. 

 

 

🧐

자바스크립트의 변수는 선언이 아닌 할당에 의해 타입이 결정된다. 
그리고 재할당에 의해 변수의 타입은 언제든지 동적으로 변할 수 있다. 
이러한 특징을 동적타이핑이라고 하며 동적타입언어라고 한다.
변수는 타입을 가지지 않는다. 하지만 값은 타입을 갖는다.

• 3년전에 자바만 하다가 자바스크립트를 접했을 때 제일 충격적이었던 사실이 이 부분이었던 것 같다. 각 언어의 특성을 잘 이해하자.

 

🧐

모든 소프트웨어 아키텍처에는 트레이드오프가 존재하며,
모든 애플리케이션에 적합한 탄환은 없듯이 동적타입 언어 또한 구조적인 단점이 있다.
동적타입언어는 유연성은 높지만 신뢰성은 떨어진다.

• 트레이드오프란 두 개의 정책이나 목표 중 하나를 달성하려고 하면 다른 목표의 달성이 늦어지거나 희생되는 모순적 관계를 의미한다고 한다. 요즘 안정성이냐 유연성이냐를 고민하던 내게 이런 단어는 또 엄청 와닿지. 이에 대한 사람들의 의견을 찾아봐야겠다

 

🧐

코드는 오해하지 않도록 작성해야한다.
오해는 커뮤니케이션을 어렵게 하는 대표적인 원인으로 생산성을 떨어뜨리는 것은 물론 팀의 사기까지 저하시킨다.
코드는 동작하는 것만이 존재 목적은 아니다.
코드는 개발자를 위한 문서이기도 하다.

• 사실 이 부분이 내가 프로그래밍을 하면서 제일 딜레마에 빠지게하는 포인트인 것 같다. 일반적으로 언어 커뮤니케이션도 항상 똑같이 말하기 보다는 듣는 사람의 생각이나 위치나 특성에 맞춰 효과적인 방법을 선택해 활용하는게 효과적인 것 처럼, 프로그래밍도 같은 코드라도 보는 사람의 스타일이나 생각이나 사고방식에 따라 다르지 않을까 싶어 항상 고민이다.
• 그 고민을 통해 탄생한게 '컨벤션'이라는 개념이겠지? 아마 우리 회사에 코딩컨벤션이 없어서 이런 고민을 하는 것 같다. 이 고민은 답이 없으니 일단 적어두고 넘어가자.

 

 

---

 

 

 

7장. 연산자

🧐

동등 비교 (==) 연산자는 좌항과 우항의 피연산자를 비교할 때
먼저 암묵적 타입 변환을 통해 타입을 일치시킨 후 같은 값인지 비교한다. 
따라서 동등 비교 연산자는 좌항과 우항의 피연산자가 타입은 다르더라도
암묵적 타입 변환 후에 같은 값일 수 있다면 true 를 반환한다.

5 == 5; // true
5 == '5'; // true
5 === '5'; // false

동등 비교 연산자는 예측하기 어려운 결과를 만들어 내기 때문에 사용하지 않는 편이 좋다.

• 요즘 코드리뷰나 QA를 하다보면 타입변환을 제대로 하지 않고 === 로 위 예제처럼 사용하다가 false 처리로 흘러버리는 코드를 보곤한다. 차라리 == 를 쓰는게 오류를 덜 나게 하는 방법이 아닌가 싶기도 했었는데, 책의 설명을 보니 확실히 안티패턴은 맞다. 명확한 타입변환을 권하는게 낫겠다.

 

✅

동등 비교 연산자 (==)와 일치 비교 연산자 (===)는 +0과 -0을 동일하다고 평가한다. 
또한 NaN 은 자신과 일치하지 않는  유일한 값이기도 하다.
ES6에서 도입된 Object.is 메서드는 정확한 비교 결과를 예측하게 해준다.

-0 === +0; // true
Object.is(-0,+0); //false

NaN === NaN; // false
Object.is(NaN, NaN); //true

 

 

🧐

삼항 조건 연산자는 값으로 평가되어야 하는 경우에 유리하다.
하지만 조건에 따라 수행해야 할 문이 하나가 여러 개라면 if...else 문의 가독성이 더 좋다.

• 이 내용도 리뷰중에도 나왔던 내용이라 한번 더 기록한다. 삼항 연산자로 3~4개의 조건을 판단해서 값을 결정하는 코드를 본 적이 있는데 너무 혼란스러웠다...!
• 사실 삼항연산자 뿐만 아니라 else 로 쭉 붙은 조건 판단도 항상 가독성문제로 논쟁이 되는 것 같으니 한번쯤 최선의 방법이 뭔지 고민해볼 필요가 있겠다.

 

✅

typeof 연산자가 반환하는 문자열은 7개의 데이터 타입과 정확히 일치하지는 않는다.

 

 

🧐

ES7 에서 도입된 지수 연산자는
좌항의 피연산자를 밑으로, 우항의 피연산자를 지수로 거듭 제곱하여 숫자 값을 반환한다.
지수 연산자는 이항 연산자 중에서 우선순위가 가장 높다.

2 ** 2; //4
2 ** 0; //1
2 * 5 ** 2; //25

• 아니 이렇게 좋은 연산자가 있었다니! 나만 몰랐나? 꼭 알아두고 써먹어야겠다.

 

 

 

 

 

'모던자바스크립트 Deep Dive' 책을 읽으며 책의 내용과 개인적인 생각을 함께 작성한 포스팅입니다.