기사 디렉토리
TypeScript의 등장 배경
자바스크립트의 문제점
새로운 기술의 출현은 원천 기술의 특정 문제점을 해결하는 것 입니다.
JavaScript는 좋은 프로그래밍 언어입니까?
모든 사람이 같은 의견을 가질 수는 없지만 많은 관점에서 JavaScript는 매우 좋은 프로그래밍 언어입니다 .
더욱이 이 언어는 오랫동안 대체되지 않고 더 많은 분야에서 널리 사용될 것이라고 말할 수 있습니다.
유명한 애트우드의 법칙 :
Stack Overflow의 창립자 중 한 명인 Jeff Atwood는 2007년 유명한 Atwood의 법칙을 제안했습니다.
JavaScript로 구현할 수 있는 모든 응용 프로그램은 결국 JavaScript로 구현됩니다.
사실, 우리는 이 문장이 단계별로 성취되는 것을 보았습니다 .
우리는 웹 개발을 위해 항상 JavaScript를 사용해 왔습니다.
모바일 개발의 경우 ReactNative, Weex 및 Uniapp과 같은 프레임워크의 도움으로 크로스 플랫폼 개발을 달성할 수 있으며 크로스 플랫폼 기술도 JavaScript를 사용합니다.
작은 프로그램의 개발도 JavaScript와 떼려야 뗄 수 없는 관계입니다.
Electron의 도움으로 데스크탑 애플리케이션을 개발할 수 있습니다.
서버 측 개발은 Node 환경의 도움으로 JavaScript를 사용하여 수행할 수 있습니다.
그리고 최근 프론트엔드 분야의 비약적인 발전과 함께 자바스크립트는 빠르게 대중화되어 대다수 개발자들에게 사랑받고 있으며, 자바스크립트 자체의 힘으로 자바스크립트를 사용하여 .
좋은 자바스크립트에는 단점이 없나요?
사실 자바스크립트 언어 자체에는 다양한 역사적 요인으로 인해 많은 단점이 있습니다.
예를 들어, ES5 및 범위에 대한 var 키워드의 이전 사용;
예를 들어, 원래 JavaScript에 의해 설계된 배열 유형은 연속적인 메모리 공간이 아닙니다.
예를 들어, 오늘날까지 JavaScript는 유형 감지 메커니즘을 추가하지 않았습니다.
자바스크립트가 서서히 좋아지고 있다
JavaScript가 저수준 디자인과 응용 프로그램 수준 모두에서 천천히 점점 더 좋아지고 있다는 것은 부인할 수 없습니다.
ES6, 7, 8 등의 도입으로 언어가 매번 더 현대적이고 안전하며 편리해졌습니다.
그러나 오늘날 JavaScript 는 여전히 유형 검사에 진전이 없다는 것을 알고 있습니다 (유형 검사가 왜 그렇게 중요한지, 나중에 이야기하겠습니다).
문제 유형
우선, 프로그래밍 개발에 대한 합의가 있다는 것을 알아야 합니다. 오류가 빨리 나타날수록 더 좋습니다.
코드를 작성할 때 오류를 찾을 수 있으면 코드를 컴파일할 때 오류를 찾지 마십시오(IDE의 장점은 코드 작성 프로세스 중에 오류를 찾는 데 도움이 된다는 것입니다).
코드 컴파일 중에 오류를 찾을 수 있다면 코드가 실행될 때 오류를 찾지 마십시오(유형 검사가 이를 매우 잘 수행하는 데 도움이 될 수 있음).
개발 중에 버그를 찾을 수 있으면 테스트 중에 버그를 찾지 말고 테스트 중에 버그를 찾을 수 있으면 출시 후 버그를 찾지 마십시오.
이제 우리가 탐구하고자 하는 것은 코드 컴파일 중에 코드에서 오류를 찾는 방법입니다 .
자바스크립트가 할 수 있나요? 아니요, 자주 발생할 수 있는 다음 코드 문제를 살펴보겠습니다.
// 当前foo函数, 在被其他地方调用时, 没有对参数做任何的校验
// 1> 没有对类型进行校验(字符串或数字都可以传入)
// 2> 没有对是否传入参数进行校验
function foo(message) {
if (message) {
console.log(message.length);
}
}
foo("Hello World");
foo("你好啊TS");
foo() // 错误的调用代码会报错(IDE不会报错), 报错后续代码不会执行
다음은 우리가 흔히 저지르는 실수입니다 .
이 오류의 가장 큰 이유는 JavaScript 가 우리가 전달하는 매개변수에 제한을 두지 않고 이 오류는 런타임 중에만 발견될 수 있기 때문입니다.
그리고 이 오류가 발생하면 후속 코드 실행의 지속에 영향을 미칩니다. 즉, 작은 오류로 인해 전체 프로젝트가 심하게 충돌합니다 .
당신은 생각할 수도 있습니다 : 내가 어떻게 그런 낮은 수준의 실수를 할 수 있었습니까?
위와 같은 간단한 데모를 작성할 때 이와 같은 실수는 피하기 쉽고, 실수할 때 확인하기 쉽습니다.
하지만 대규모 프로젝트를 개발할 때는 어떻습니까? 당신은 그런 문제가 없을 것이라고 보장할 수 있습니까? 그리고 다른 사람의 클래스 라이브러리를 호출하는 경우 다른 사람이 전달하도록 허용한 매개변수의 종류를 어떻게 알 수 있습니까? 다시 말해서, 다른 사람들이 사용할 수 있도록 함수를 캡슐화하면 함수가 전달해야 하는 매개변수를 다른 사람들이 어떻게 알 수 있을까요?
그러나 JavaScript에 많은 제한을 추가할 수 있다면 개발에서 이러한 문제를 피할 수 있습니다 .
예를 들어, 방금 전달한 함수의 메시지는 전달해야 하는 유형인데 호출자가 전달하지 않으면 컴파일 중에 오류가 보고 됩니다.
예를 들어 문자열 유형이어야 하며 다른 유형이 전달되면 오류가 직접 보고됩니다.
그러면 런타임에 발견되고 수정되기를 기다리는 대신 컴파일하는 동안 많은 오류가 발견된다는 것을 알 수 있습니다.
우리는 이미 타입 검사의 부재로 인해 발생하는 몇 가지 문제를 간략히 깨달았습니다 .
프론트엔드 개발자는 일반적으로 변수나 매개변수의 유형에 신경 쓰지 않습니다. 유형을 결정해야 하는 경우 종종 다양한 판단을 사용하여 확인해야 합니다.
다른 방향에서 프런트 엔드로 이동하는 사람들은 형식 제약 조건이 없기 때문에 코드가 충분히 안전하지 않고 강력하지 않다고 항상 걱정할 것입니다.
따라서 우리는 JavaScript가 대규모 프로젝트를 개발하는 데 적합하지 않다고 종종 말합니다. 왜냐하면 프로젝트가 거대해지면 이 느슨한 형식 제약 조건은 많은 보안 위험을 가져오고 이를 개발하는 여러 사람 사이에 좋은 형식 계약 이 없기 때문입니다 .
예를 들어 핵심 클래스 라이브러리를 구현할 때 형식 제약 조건이 없는 경우 코드의 견고성을 보장하기 위해 다른 사람이 전달한 매개 변수에 대해 다양한 검증을 수행해야 합니다.
예를 들어, 우리가 다른 사람의 함수를 호출할 때 상대방은 함수에 대해 언급하지 않습니다. 우리는 이 함수가 전달해야 하는 매개변수와 반환 값의 유형을 이해하기 위해 내부 논리만 볼 수 있습니다.
JavaScript 유형 제약 조건의 단점을 보완하고 유형 제약 조건을 늘리기 위해 많은 회사에서 자체 솔루션을 출시했습니다 .
2014년에 Facebook은 JavaScript 유형 검사를 위한 흐름을 출시했습니다.
같은 해에 Microsoft는 TypeScript 1.0도 출시했습니다.
둘 다 JavaScript에 대한 유형 검사를 제공하기 위해 작동합니다.
이제 TypeScript가 완전히 승리했다는 데는 의심의 여지가 없습니다 .
Vue2.x에서 흐름은 유형 검사에 사용됩니다.
Vue3.x는 전반적으로 TypeScript로 전환되었으며 98.3%는 TypeScript를 사용하여 리팩토링되었습니다.
Angular는 초기 단계에서 프로젝트 리팩토링에 TypeScript를 사용했으며 개발에는 TypeScript를 사용해야 합니다.
그리고 심지어 Facebook 자체 제품 중 일부는 TypeScript를 사용하고 있습니다.
TypeScript를 학습하면 코드에 유형 제약 조건을 추가할 수 있을 뿐만 아니라 유형 사고를 가진 프론트 엔드 프로그래머를 양성할 수 있습니다 .