@@ -19,8 +19,8 @@ message.toLowerCase();
19
19
message ();
20
20
```
21
21
22
- 위 코드를 분석해보면, 우선 첫번째 실행 코드 줄에서는 ` toLowerCase ` 라는 프로퍼티에 접근한 뒤 이를 호출합니다.
23
- 두번째 줄에서는 ` message ` 를 직접 호출하려 하고 있습니다.
22
+ 위 코드를 분석해보면, 우선 첫 번째 실행 코드 줄에서는 ` toLowerCase ` 라는 프로퍼티에 접근한 뒤 이를 호출합니다.
23
+ 두 번째 줄에서는 ` message ` 를 직접 호출하려 하고 있습니다.
24
24
25
25
하지만 ` message ` 의 값이 무엇인지 모른다면 - 일반적으로 그렇습니다 - 위 코드의 실행 결과가 무엇인지 확실히 말할 수 없습니다.
26
26
각 연산의 동작은 최초에 어떤 값을 가졌는지에 따라 완전히 달라집니다.
@@ -40,7 +40,7 @@ const message = "Hello World!";
40
40
41
41
익히 짐작하셨겠지만 여기서 ` message.toLowerCase() ` 를 실행하면, 우리는 동일한 문자열이 소문자로만 이루어져 있는 값을 얻을 것입니다.
42
42
43
- 그렇다면 앞서 본 코드의 두번째 라인은 어떨까요?
43
+ 그렇다면 앞서 본 코드의 두 번째 라인은 어떨까요?
44
44
JavaScript가 익숙하시다면, 예외와 함께 실행이 되지 않을 것을 아실 겁니다.
45
45
46
46
``` txt
@@ -49,7 +49,7 @@ TypeError: message is not a function
49
49
50
50
이와 같은 실수를 미리 방지할 수 있다면 참 좋을 것 같습니다.
51
51
52
- JavaScript 런타임은 코드가 실행될 때 자신이 무엇을 해야할 지 결정하기 위하여 값의 _ 타입_ , 즉 해당 값이 어떤 동작과 능력을 가지고 있는지를 확인합니다.
52
+ JavaScript 런타임은 코드가 실행될 때 자신이 무엇을 해야 할지 결정하기 위하여 값의 _ 타입_ , 즉 해당 값이 어떤 동작과 능력을 가지고 있는지를 확인합니다.
53
53
이것이 바로 ` TypeError ` 가 암시하는 바입니다. 위 예시에서는 문자열인 ` "Hello World" ` 가 함수로서 호출될 수 없다고 말하고 있는 것이죠.
54
54
55
55
일부 값들, 이를테면 ` string ` 과 ` number ` 과 같은 원시 타입의 값의 경우 ` typeof ` 연산자를 사용하면 각 값들의 타입을 실행 시점에 알 수 있습니다.
@@ -62,7 +62,7 @@ function fn(x) {
62
62
}
63
63
```
64
64
65
- 위 코드를 보면, 인자로 전달된 객체가 호출 가능한 프로터티인 ` flip ` 을 가져야만 위 함수가 잘 작동할 것이라는 것을 우리는 코드를 읽음으로써 _ 알 수 있습니다._ 하지만 JavaScript는 우리가 알고 있는 이러한 정보를 코드가 실행되는 동안 알지 못합니다.
65
+ 위 코드를 보면, 인자로 전달된 객체가 호출 가능한 프로퍼티인 ` flip ` 을 가져야만 위 함수가 잘 작동할 것이라는 것을 우리는 코드를 읽음으로써 _ 알 수 있습니다._ 하지만 JavaScript는 우리가 알고 있는 이러한 정보를 코드가 실행되는 동안 알지 못합니다.
66
66
순수 JavaScript에서 ` fn ` 가 특정 값과 어떤 동작을 수행하는지 알 수 있는 유일한 방법은 호출하고 무슨 일이 벌어지는지 보는 것입니다.
67
67
이와 같은 동작은 코드 실행 전에 예측을 어렵게 만듭니다. 다시 말해 코드가 어떤 동작 결과를 보일지 코드를 작성하는 동안에는 알기 어렵습니다.
68
68
@@ -73,13 +73,13 @@ JavaScript는 오직 _동적_ 타입만을 제공하며, 코드를 실행해야
73
73
74
74
## 정적 타입 검사
75
75
76
- 앞서 살펴본, ` string ` 을 함수로서 호출하고자 했을 때 얻은 ` TypeError ` 의 이야기로 돌아가봅시다 .
76
+ 앞서 살펴본, ` string ` 을 함수로서 호출하고자 했을 때 얻은 ` TypeError ` 의 이야기로 돌아가 봅시다 .
77
77
_ 대부분의 사람들은_ 코드를 실행했을 때 오류를 보고 싶지 않습니다. 그것은 버그로 여겨집니다!
78
78
그리고 새로운 코드를 작성할 때 우리는 새로운 버그를 만들어내지 않도록 최선을 다합니다.
79
79
80
80
여기서 만약 약간의 코드를 추가하고 파일을 저장한 뒤, 코드를 다시 실행했을 때 바로 오류가 확인된다면, 문제를 신속하게 격리시킬 수 있을 것입니다. 하지만 항상 그렇게 되는 것은 아닙니다.
81
81
기능을 충분히 테스트하지 않아서, 잠재적인 오류를 미처 발견하지 못할 수도 있습니다!
82
- 또는 운좋게 오류를 발견했더라도, 결국 상당한 규모의 리팩토링을 거치고 새 코드를 추가하면서 의도치 않게 코드를 깊게 파헤치게 될 수도 있습니다.
82
+ 또는 운 좋게 오류를 발견했더라도, 결국 상당한 규모의 리팩토링을 거치고 새 코드를 추가하면서 의도치 않게 코드를 깊게 파헤치게 될 수도 있습니다.
83
83
84
84
이상적으로는, 코드를 실행하기 _ 전에_ 이러한 버그를 미리 발견할 수 있는 도구가 있다면 좋을 것입니다.
85
85
TypeScript와 같은 정적 타입 검사기의 역할이 바로 그것입니다.
@@ -227,7 +227,7 @@ tsc hello.ts
227
227
228
228
잠깐, 정확히 _ 무엇_이 "짜잔"하고 나왔다는 것이죠?
229
229
` tsc ` 를 실행했지만 아무 일도 일어나지 않았습니다!
230
- 뭐, 타입 오류가 없었으니, 아무 것도 보고될 것이 없고 그래서 콘솔에도 아무런 출력이 나타나지 않았습니다.
230
+ 뭐, 타입 오류가 없었으니, 아무것도 보고될 것이 없고 그래서 콘솔에도 아무런 출력이 나타나지 않았습니다.
231
231
232
232
하지만 다시 확인해보면, 우리는 그 대신 _ 파일_ 출력을 얻었습니다.
233
233
현재 디렉토리를 보면, ` hello.ts ` 파일 옆에 ` hello.js ` 파일이 있는 것을 볼 수 있습니다.
@@ -241,7 +241,7 @@ console.log("Hello world!");
241
241
242
242
위 경우, TypeScript가 변형해야 할 내용은 극히 적었고, 따라서 우리가 처음에 작성한 것과 동일한 결과물이 나왔습니다.
243
243
컴파일러는 사람이 작성한 듯이 깔끔하고 읽을 수 있는 코드를 만들어내고자 시도합니다.
244
- 물론 그것이 항상 쉬운 것은 아니지만, TypeScript는 일관성있게 들여쓰기를 수행하고, 여러 줄에 걸쳐 코드가 작성되는 것을 감안하고, 코드 주변에 작성된 주석도 잘 배치해둡니다.
244
+ 물론 그것이 항상 쉬운 것은 아니지만, TypeScript는 일관성 있게 들여 쓰기를 수행하고, 여러 줄에 걸쳐 코드가 작성되는 것을 감안하고, 코드 주변에 작성된 주석도 잘 배치해둡니다.
245
245
246
246
만약 타입 검사 오류가 _ 주어지면_ 어떨까요?
247
247
` hello.ts ` 를 다시 작성해보겠습니다.
@@ -268,7 +268,7 @@ TypeScript는 `greet` 함수에 인자를 전달하는 것을 깜빡했다고
268
268
269
269
### 오류 발생시키기
270
270
271
- 앞서 살펴 본 예시에서 눈치 채셨는지 모르겠지만, ` hello.js ` 파일의 내용이 또 한번 수정되었습니다.
271
+ 앞서 살펴 본 예시에서 눈치 채셨는지 모르겠지만, ` hello.js ` 파일의 내용이 또 한 번 수정되었습니다.
272
272
파일을 열어보면, 입력으로 사용된 코드 파일과 실질적으로 동일하다는 것을 알 수 있습니다.
273
273
우리 코드를 보고 ` tsc ` 가 오류를 발생시켰다는 점을 감안하면 다소 놀랍게 느껴질 수도 있지만, 이는 TypeScript의 핵심 가치 중 하나에 기반한 동작입니다. 그것은 바로, 대부분의 경우 * 당신이* TypeScript보다 더 잘 알고 있을 것이라는 생각입니다.
274
274
@@ -388,7 +388,7 @@ greet("Maddison", new Date());
388
388
왜 이러한 일이 생겼을까요?
389
389
390
390
템플릿 문자열은 ECMAScript 2015(a.k.a. ECMAScript 6, ES2015, ES6, 등. _ 더 묻지 마세요_ )라고 불리는 버전의 ECMAScript에서 등장한 기능입니다.
391
- TypeScript는 새 버전의 ECMAScript의 코드를 ECMAScript 3 또는 ECMAScript 5와 같은 보다 예전 버전의 것들로 다시 작성해줍니다 .
391
+ TypeScript는 새 버전의 ECMAScript의 코드를 ECMAScript 3 또는 ECMAScript 5와 같은 보다 예전 버전의 것들로 다시 작성해 줍니다 .
392
392
새로운 또는 "상위" 버전의 ECMAScript를 예전의 또는 "하위" 버전의 것으로 바꾸는 과정을 _ 다운레벨링_이라 부르기도 합니다.
393
393
394
394
TypeScript는 ES3라는 아주 구버전의 ECMAScript를 타겟으로 동작하는 것이 기본 동작입니다.
0 commit comments