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

 

 

1장. 프로그래밍

 

🧐

대부분의 문제(요구사항)은 복잡하며 명확하지 않을 수도 있다.
따라서 문제(요구사항)을 명확히 이해하는 것이 우선되어야 하며 복잡함을 단순하게 분해하고 자료를 정리하고 구분해야 하며 순서에 맞게 행위를 배열해야 한다.

• 프로그래밍에 대한 내용이긴 했지만, 그 외에도 업무적인 해결 능력이나 프로젝트 진행중 문제 해결능력에 대해서도 기억하고있으면 좋을 만한 내용이라는 생각이 들었다.
• 개발과 업무, 프로젝트 관리 등 요구사항이나 문제는 항상 복잡하고 명확하지 않을 수 있으며, 그 불명확함을 단순하게하고 배열하는게 문제해결 능력이라는 사실을 기억하자.

 

🧐

프로그래밍 학습은 일반적으로 문법을 배우는 것부터 시작하는 외국어 학습과 유사하다.
문법을 잘 안다고 해서 외국어를 잘한다고 말할 수는 없다.
외국어를 잘하려면 외국어 화자의 말이나 문장을 정확히 이해한 후, 문맥에 따른 적절한 어휘 선택,
그리고 순차적으로 결론을 향해 나아가는 문장 구성이 필요하다.

• 외국어를 잘하는 사람들을 보면 독학파가 있고, 조기유학파가 있듯이 개발도 비슷할거란 생각이 이 구절을 보면서 갑자기 들었다. 학습에서 얻을 수 있는 배움과 실무에서 배울 수 있는 배움을 병행해서 잘 구성하는 사람이 되야할 것 같다. 

 

---

 

2장. 자바스크립트란?

 

🧐

자바스크립트는 명령형, 함수형, 프로토타입 기반 객체지향 프로그래밍을 지원하는
멀티 패러다임 프로그래밍 언어다.

• 진짜 항상 봐온 당연한 말인데 왜 더 와닿는지 모르겠다. 요즘 순수자바스크립트로 작업하면서 명령형으로 짜야하는 기능과 함수형으로 짜야하는 기능과 프로토타입 기반으로 짜야하는 기능의 특성이 있을 것 같아 잘 이용해보려던 시기여서 그랬던 것 같다.
• 말그대로 멀티 패러다임 언어인만큼 하나에 치우치지말고 각 특성을 잘 알고 이용하는게 좋겠다.

 

 

🧐

비록 다른 객체지향 언어와의 차이점에 대한 논쟁이 있긴 하지만
자바스크립트는 클래스 기반 객체지향 언어보다 효율적이면서 강력한 프로토타입 기반의 객체지향 언어이다.

• 나는 자바로 프로그래밍을 시작했으니 클래스 기반 객체지향 언어에 아주 익숙한 사고방식을 가지고 있었고 자바로 개발할때는 그 특성을 제대로 활용하는 프레임워크나 방법론에 대해 많은 연구를 했던 것 같다.
• 하지만 자바스크립트로 개발하면서는 프로토타입 기반 객체지향언어만의 특성을 제대로 파악하고 잘 활용하려고 노력하지 않았던 것 같아서 반성했다.

 

---

 

 

3장. 자바스크립트 개발 환경과 실행 방법

 

🧐

브라우저와 Node.js 는 자바스크립트 엔진을 내장하고 있다.

• 왜 이것도 당연한 말인데 이렇게 와닿는지... 저자가 아무래도 설명을 너무 잘 하는 것 같다.

 

🧐

node.js 는 브라우저 외부에서 자바스크립트 실행 환경을 제공하는 것이 주된 목적이다.
브라우저 외부 환경에서는 HTML 요소를 파싱해서 객체화한 DOM을 직접 다룰 필요가 없어
node.js 는 DOM API 를 제공하지 않는다.

• 지금 업무에서 설치형 앱을 위해 사용중인 electron 도 모두 js 언어로 되어있지만 브라우저기반으로 실행되는 renderer 쪽은 dom api 를 제공하고, main 쪽은 node.js 로 실행되어 dom api 를 제공하지 않는 것도 위 구절에 맞는 사례라고 생각했다. 

 

---

 

4장. 변수

 

🧐

메모리 주소를 통해 값에 직접 접근하는 것은 치명적 오류를 발생시킬 가능성이 높은 매우 위험한 일이다.
만약 실수로 운영체제가 사용하고 있는 값을 변경하면 시스템을 멈추게하는 치명적인 오류가 발생할 수도 있다.
따라서 자바스크립트는 개발자의 직접적인 메모리 제어를 허용하지 않는다.

값이 저장될 메모리 주소는 코드가 실행될 때 메모리의 상황에 따라 임의로 결정된다.
따라서 동일한 컴퓨터에서 동일한 코드를 실행해도 코드가 실행될 때마다 값이 저장될 메모리 주소는 변경되므로 직접 접근하려는 시도는 올바른 방법이 아니다.

• 얼마전에 동료 개발자가 '자스에서도 메모리 주소를 통해 값을 알고 비교할 수 있었으면 좋겠다' 라는 말을 했는데 바로 이런 구절이 나와서 신기하고 공유해주고 싶었다..

 

🧐

식별자는 값이 아니라 메모리 주소를 기억하고 있다.

• 당연한 말이지만 다시한번 인지하기 위해 기록.

 

 

🧐

더 이상 사용되지 않는 메모리란 어떤 식별자도 참조하지 않는 메모리 공간을 의미하며,
자바스크립트는 가비지 콜렉터를 통해 더 이상 사용되지 않는 메모리를 해제하여 메모리 누수를 방지한다.

• 이 말에서 '어떤 식별자도 참조하지 않는 메모리 공간' 이라는 표현에서 이런 저런 생각을 했다. 현재 개발중인 소스를 보면 단순히 참조관계만 걸어놓거나 바인딩처리하고 실제로는 쓰지 않는 수많은 변수들이 존재하는데, 그것들은 gc 의 대상이 되지 않는다는걸 의미하겠지...?
• 자바를 쓸때는 당연히 습관처럼 null 로 비워주곤 했는데 js 를 쓸때는 알아서 잘 메모리 관리가 된다고 생각하고 신경쓰지 못했던 것 같다.
• js 에서의 gc에 대해서는 나중에 좀 더 딥하게 연구해봐야겠다. 

 

 

🧐

일반적으로 변수나 함수의 이름에는 카멜 케이스를 사용하고
생성자 함수, 클래스의 이름에는 파스칼 케이스를 사용한다.

• 얼마전에 회사에서 내가 만든 기능의 리뷰를 팀원들에게 받기위해 전체적인 소스 브리핑을 한 적이 있다. 그때 동료 개발자가 '왜인지는 모르겠는데 유난히 이해가 너무 잘되네요' 라고 했다. 나는 분명 이전에도 비슷한 설계와 구조를 가지고 기능을 만들었었고 똑같이 설명을 한 적이 있는데도 말이다.
• 이 구절을 읽고 생각해보니 내가 이번에 새롭게 시도한 변수와 함수의 명명규칙때문이 아닌가 싶다. (우리는 아직 함수명 변수명에 대한 컨벤션은 없는 상태라 자유롭게 정할 수 있다.) 이번에 시도한 내용은 아래와 같다.
  • 생성자 함수나 클래스의 이름에는 파스칼 케이스
  • 함수 스코프 내에 있는 변수는 카멜케이스
  • 클래스의 멤버변수이면서 this로 바인딩된 함수가 참조할 수 있는 변수에는 스네이크 케이스
• 혹시 위의 내용처럼 새롭게 적용한 변수명 규칙때문에 가독성이 좋아서 이해가 잘 된게 아니었을지 이 구절을 읽고 나서 동료에게 다시 물어보니 생각해보니 맞는 것 같다는 피드백이 왔다. 어디에 있는 변수인지 어느 범위까지 허용된 변수인지 등에 대한 구분이 변수명으로 바로 인식되니 보는 사람으로 하여금 좀 더 전체적인 구조를 인지하기가 쉬운 코드가 된 것 같다.
• 언젠가 코딩컨벤션을 다시 만드는 날이 온다면 이 내용을 제안해보는게 좋겠다.

 

 

 

 

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