오늘도 끄적끄적

v1에는 재사용 가능한 코드가 있음에도 불구하고 미묘(?)한 차이 때문에 계속 각국의 타이어를 장착한 자동차 클래스를 만들어야하는 단점이 있었다.
이는 자동차를 만들 때 이미 타이어를 만드는 방법이 결정되어 있기 때문에 발생하는 문제이다.
(**자동차(전체)**가 **타이어(부분)**에 의존하고 있는 코드)
즉, 자동차를 만들 때 타이어를 만드는 방법을 결정하면 되는 사항이다.
(**의존하는 부분(타이어)**을 **전체(자동차)**에 주입시키는 패턴)

1
2
3
4

// Tire.java
public interface Tire {
    void wheel();
}

1
2
3
4
5
6

// KoreanTire.java
public class KoreanTire implements Tire {
    public void wheel() {
        System.out.println("구르다");
    }
}

1
2
3
4
5
6

// AmericanTrie.java
public class AmericanTire implements Tire {
    public void wheel() {
        System.out.println("wheel");
    }
}

v2에는 자동차를 생산할 때 어떤 타이어를 만들지 정할 수 있고 새로운 타이어로 교체도 가능했다.
하지만 올바른 값이 들어왔는지 유효성 검사할 방법이 없다.
사실 변경할 수는 있지만 안전하지 않고 그닥 권장하는 방법이 아니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// Car.java
public class Car {
    private Tire tire;
    Car(Tire tire) {
        this.tire = tire;
    }
    // setter로 유효성 검사를 위해선 어쩔 수 없이(?) tire를 얻기 위해선 getter를 써야함.
    public Tire getTire() {
        return tire;
    }
    // setter로 다음과 같이 유효성 검사가 가능해짐.
    public void setTire(Tire tire) {
        
        if(tire == null) throw new NullPointerException();
        this.tire = tire;
   
    }
}

1
2
3
4
5
6
7
8
9
10
11

// Driver.java
public class Driver {
    public static void main(String[] args) {
        KoreanTire koreanTire = new KoreanTire();
        AmericanTire americanTire = new AmericanTire();
        Car car = new Car(koreanTire);
        car.getTire().wheel(); // 구르다
        car.setTire(americanTire);
        car.getTire().wheel(); // wheel
    }
}

setter를 사용해 좀 더 안전하게(?) 타이어를 교체할 수 있게 되었다.
대부분 getter/setter를 사용하는 이유는 아마 다음과 같을 것이다.

이 글은 의존성 주입을 전혀 적용하지 않은, 의존성 주입이 뭔지 모르는 상태로 짠 코드이다.
우선 문제점을 먼저 파악해봐야 뭐가 되지 않을까 싶어서 막코딩을 해봤다고 가정해보자.
우선 미국산 타이어가 장착된 자동차, 한국산 타이어가 장착된 자동차를 만들어야한다고 생각해보자.
그럼 우선 미국산, 한국산 타이어 클래스 두 개가 필요할 것이다.

1
2
3
4
5
6

// KoreanTire.java
public class KoreanTire {
    public void wheel() {
        System.out.println("구르다");
    }
}

1
2
3
4
5
6

// AmericanTire.java
public class AmericanTire {
    public void wheel() {
        System.out.println("wheel");
    }
}

그리고 각각 미국산 타이어를 장착한 자동차, 한국산 타이어를 장착한 자동차 클래스 두 개를 만들면 끝난다.

봄의 향그러운 느낌을 한껏 품은 비트다.
들으면 잠이 쏟아질 것 같지만 1시간을 넘게 들어도 잠이 안 올 때는 잘 안 온다.

이 글은 자바와 자바스크립트를 혼동하는 사람, 차이점이 궁금한 사람 등을 위하여 쓴 글입니다.
또한 자바스크립트는 다른 언어에 비해 어떤 단점이 있으며 그 단점들을 어떻게 극복해야할지에 대해 다뤄봤습니다.

하고 싶은 말 세 줄 요약.

1. 자바스크립트 !== 자바(자바 != 자바스크립트), 자바와 자바스크립트는 같지 않다.
   두 언어 간에는 접점이 크지 않고, 자바스크립트는 자바의 인기에 편승할 목적(마케팅 목적)으로 이름을 지은 것 뿐입니다.
2. 자바 커뮤니티 가서 자바스크립트 질문하거나 자바스크립트 커뮤니티 가서 자바 질문을 하는 건 자제해주세요.
   하지 말라는 건 아닌데 질문자 분께서 원하시는 답(틀린 답을 얻을 수도 있고), 양질의 답을 얻을 가능성, 그리고 빠른 응답을 받기가 힘드실 수 있습니다.
3. 제발 자바 스크립트(Java Script)라고 적어서 혼란을 초래하지 말아주세요.
   제발 제발 부탁드립니다. 가끔 보면 화(…)가 날 때도 있습니다.
   위와 같이 쓰시는 분들 때문에 이런 혼란이 더 초래되는 것 같습니다.
   새로 배우시는 분들께 잘못된 인식을 심어주는 것도 굉장히 위험하다고 보니 제발 부탁드리겠습니다.

목차

이 포스트는 제가 다년간 자바스크립트를 설렁 설렁 공부하다 작년 1년동안 빡시게 공부해온 경험을 토대로 작성한 글입니다.
따라서 이 글을 읽으시는 분들께서는 본인과 맞지 않는 부분도 존재할 수 있으니 그 점은 참고하고 적절한 필터링을 하시면 되겠습니다.

목차

• 들어가기에 앞서
  • 역사를 먼저 알아보자
  • 자바스크립트는 자바가 아니다
  • HTML, CSS의 연장선 상으로 자바스크립트를 바라보지 말자
  • JS를 브라우저와 떼놓고 생각하자
  • JS는 더이상 Toy Language(장난감 가지고 놀듯 쉽고 깊이 없이 배워도 되는 언어)가 아니다.
• 어떻게 공부해야할까?
  • 1. 잘 만들어졌다고 알려진 언어들을 먼저 공부하자
    • 1-1. 그게 싫다면 쉽게 쉽게 쓰여진 책을 먼저 읽자
  • 2. 소문난 책들을 위주로 읽자, 단 jQuery 빼고
    • 2-1. MDN, Stackoverflow와 친해지자
    • 2-2. ES5를 끝내고 ES2015+를 할 필요가 없다
  • 3. NPM과 Babel을 배우자
  • 4. ES2015+가 익숙해졌다면 Typescript를 공부해보자
• 번외편
  • 1. 코드 검사 도구를 사용하자.
  • 2. Task Runner를 배우자
  • 3. Module Bundler를 배우자
  • 4. TDD를 공부하자
• 마치며

들어가기에 앞서

자알쓰란?

자바스크립트 알고 쓰자. (잘 쓰자는 의미도 담겨있다.)
자바스크립트라는 언어 자체는 내 기준에서는 설계 상 미스가 참 많다.
함수 단위의 스코프, 호이스팅, 동적 타입 등등
자바와 같은 깐깐(?)한 언어를 배우고 바라본 자스는 허점 투성이처럼 보였다.
애초에 자바스크립트는 어떠한 프로그램을 만들기 위해서 탄생했다기 보다는
웹 페이지에 입력값에 대한 유효성 검사(데이터가 공란인지 아닌지 등등)와 같은
페이지의 동적 제어가 주된 목적 + 짧은 개발 기간(넷 스케이프 사의 새로운 브라우저에 탑재 예정) 때문에
설계 상에 미스가 있을 수 밖에 없다고 나는 생각된다.
일종의 안전 장치가 없어서 개발자가 일일이 구현해주고, 신경써야 하는 느낌이었다.
그렇다고 해서 자바스크립트를 극혐하거나 그런 것은 아니고 매우 사랑한다.
또한 그 허점을 아는 사람은 허점을 보완해서 요리조리 피해서 잘 쓰겠지만…
잘 모르는 부분들은 잘못 써도 동작이 잘 되기 마련이다.
이는 지금 당장에는 큰 문제가 안 될지 모르겠지만, 추후에 대규모 웹 어플리케이션을 만들거나
직면할 문제로부터 미리 해방시키기 위해 처음부터 좋은 습관을 들여가는 것이 좋다고 생각한다.
그 열 세 번째 시리즈는 클로저를 주제로 진행하겠다.

들어가기 전에

프로그래밍 언어에는 지역 변수란 게 존재한다.
이 지역변수는 변수의 스코프에 의존적이다.
여타 프로그맹 언어에서 변수의 스코프는 {} 블록 단위지만,
자바스크립트의 변수의 스코프는 함수 단위이다. (물론 ES6의 const와 let의 스코프는 블록 단위)

자알쓰란?

자바스크립트 알고 쓰자. (잘 쓰자는 의미도 담겨있다.)
자바스크립트라는 언어 자체는 내 기준에서는 설계 상 미스가 참 많다.
함수 단위의 스코프, 호이스팅, 동적 타입 등등
자바와 같은 깐깐(?)한 언어를 배우고 바라본 자스는 허점 투성이처럼 보였다.
애초에 자바스크립트는 어떠한 프로그램을 만들기 위해서 탄생했다기 보다는
웹 페이지에 입력값에 대한 유효성 검사(데이터가 공란인지 아닌지 등등)와 같은
페이지의 동적 제어가 주된 목적 + 짧은 개발 기간(넷 스케이프 사의 새로운 브라우저에 탑재 예정) 때문에
설계 상에 미스가 있을 수 밖에 없다고 나는 생각된다.
일종의 안전 장치가 없어서 개발자가 일일이 구현해주고, 신경써야 하는 느낌이었다.
그렇다고 해서 자바스크립트를 극혐하거나 그런 것은 아니고 매우 사랑한다.
또한 그 허점을 아는 사람은 허점을 보완해서 요리조리 피해서 잘 쓰겠지만…
잘 모르는 부분들은 잘못 써도 동작이 잘 되기 마련이다.
이는 지금 당장에는 큰 문제가 안 될지 모르겠지만, 추후에 대규모 웹 어플리케이션을 만들거나
직면할 문제로부터 미리 해방시키기 위해 처음부터 좋은 습관을 들여가는 것이 좋다고 생각한다.
이번에는 쉬어가는 타임으로 번외편 격인 JIT 컴파일에 대해 간단히 다뤄보았다.

자바스크립트는 인터스크립트 언어이다?

책을 보면 위와 같이 말하는 경우가 존재한다.
인터스크립트가 뭔데?에서 부터 막힌다면 아래 내용을 봐보자.

기본적으로 컴퓨터는 기계어(2진수(0과 1)로 이루어진 코드) 밖에 해석하지 못한다.
바보 녀석 ㅎㅎ
왜 10진수가 아닌 2진수를 사용하게 됐는지 궁금한 사람은 컴퓨터에서 2진수, 8진수, 16진수를 쓰게 된 이유를 참고하자.

따라서 우리는 우리가 짠 코드를 기계어로 바꾸는 행위를 해야한다.

우리의 뇌는 이렇게 좋지도 않고, 효율성 측면에서 이러한 행위를 도와주는 도구가 세 가지가 있다.

여러 책을 보고 혼자서 내린 결론이기 때문에 틀릴 가능성이 있으니 지적해주면 감사하겠습니다 ^^

최초의 컴퓨터는 10진수를 사용했다.

나는 처음부터 2진수를 사용한 줄 알았는데 최초의 컴퓨터인 에니악은 10진수를 사용했다고 한다.
아마도 우리의 손가락이 10개이고 평상시에 연산을 할 때도 10진수를 주로 사용하기 때문에 익숙해서 10진수를 사용했던 게 아닐까?

그럼 왜 컴퓨터는 2진수를 사용하게 됐을까?