JavaScript에 대해 당신이 모를 수도 있는 6가지 사실

작가: Lewis Cianci✏️

그럼 당신은 JavaScript 개발자이신가요? 반갑습니다. 이 코드가 무엇을 반환한다고 생각하시나요? 그리고 네, 이것은 까다로운 질문입니다:

function returnSomething()
{
  return
    {
      name: 'JavaScript Expert'
      contactMethod: 'Shine batsign at sky'
    }
}

C#, Java 등 거의 모든 언어에서는 JavaScript Expert를 사용하여 개체를 가져옵니다. JavaScript에서도 동일한 결과를 얻을 수 있다고 생각하시면 이해가 되실 것입니다.

하지만 유머러스하게 이 내용을 개발 콘솔에 표시한 다음 기능을 실행해 보세요. 거의 믿을 수 없을 정도로 정의되지 않은 결과가 반환됩니다.

일이 계획대로 되지 않을 때

소프트웨어 개발자로 일한다는 것은 앱이 잘 작동하든 제대로 작동하지 않든 앱 작동 방식에 대한 책임이 있다는 것을 의미합니다. 그 주요 제약은 사용하기로 결정한 도구입니다. 자신이 사용하는 것이 무엇인지 이해했다면 소프트웨어를 설계하는 방법에 있어서 좋은 선택을 하게 될 것입니다.

JavaScript는 많은 신규 소프트웨어 개발자가 선택하는 언어라는 점에서 독특합니다. 모바일 앱을 작성하고 싶으신가요? 그냥 React Native와 JavaScript를 사용하세요. 데스크톱 앱? 네이티브와 자바스크립트에 반응하세요. 어딘가에서 실행할 수 있는 클라우드 기능? Node.js, 그리고 짐작하셨겠지만 JavaScript입니다.

그러나 JavaScript가 존재한 기간으로 인해 상당한 문제와 문제점이 있습니다. 이들 중 일부는 약간 재미있는 것부터 내 코드가 작동하지 않는 것까지, 왜 심각한지 모르는 것까지 다양합니다.

또한 Internet Explorer 6이 전성기였던 시대에 살았다고 해도 웹이 너무 많이 손상되므로 이러한 디자인 결정 중 일부를 수정하기에는 너무 늦었을 것입니다. 그렇다면 오늘 시도해 볼까요? ??

그럼 JavaScript는 어떻게 우리가 예상하는 방식으로 작동하지 않나요? 살펴보겠습니다.

자동 세미콜론 주입(ASI)

처음에 나열된 예는 JavaScript 해석기에서 허용되지만 예상한 결과를 산출하지 않습니다. 그 이유는 자동 세미콜론 주입 때문입니다.

C#과 같은 일부 언어에서는 각 줄을 세미콜론으로 끝내는 것에 대해 독단적입니다. JavaScript에서는 줄의 끝을 표시하기 위해 세미콜론도 사용하지만 세미콜론은 실제로는 선택 사항입니다. 선택 사항이라는 것은 JavaScript가 세미콜론이 있어야 하는지 여부를 결정하기 위해 일련의 복잡한 규칙을 적용한다는 것을 의미합니다.

처음의 예에서 여는 괄호는 반환과 같은 줄에 나타나지 않기 때문에 ASI는 우리를 위해 거기에 하나를 팝합니다. 따라서 JavaScript에 관한 한 우리 코드는 실제로 다음과 같습니다.

function returnSomething()
{
  return ; // <-- semicolon inserted by ASI, remainder of function not evaluated.
    {
      name: 'JavaScript Expert'
      contactMethod: 'Shine batsign at sky'
    }
}

이를 방지하는 방법은 여는 괄호를 리턴과 같은 줄에 두는 것입니다. 그리고 세미콜론은 JavaScript에서 기술적으로 선택 사항이지만 장기적으로 해당 개념으로 작업하는 것은 해를 끼칠 것입니다.

인터뷰를 할 때 JS를 작성해야 하는데 "하지만 선택 사항이다"라는 근거를 바탕으로 세미콜론 없이 작성한다면 종이를 뒤섞고 낄낄거리는 일이 많이 있을 것입니다. 그냥 하지 마세요.

비순차적 키가 있는 배열

간단한 배열이 있다고 가정해 보겠습니다.

function returnSomething()
{
  return
    {
      name: 'JavaScript Expert'
      contactMethod: 'Shine batsign at sky'
    }
}

우리는 배열을 사용하여 팝, 푸시, 추가 등 원하는 모든 작업을 수행할 수 있다는 것을 알고 있습니다. 그러나 우리는 다른 언어와 마찬가지로 JavaScript를 사용하여 인덱스를 통해 배열 요소에 액세스할 수 있다는 것도 알고 있습니다.

그러나 JavaScript의 특이한 점은 배열이 아직 해당 인덱스에 도달하지 않은 경우에도 배열 인덱스별로 요소를 설정할 수 있다는 것입니다.

function returnSomething()
{
  return ; // <-- semicolon inserted by ASI, remainder of function not evaluated.
    {
      name: 'JavaScript Expert'
      contactMethod: 'Shine batsign at sky'
    }
}

좋은 질문이 있습니다. 세 가지 요소만 설정했을 때 배열의 길이는 얼마입니까? 어쩌면 직관적이지 않을 수도 있지만 101입니다. 한편으로는 배열 항목 2~99가 정의되지 않은 것이 합리적이지만, 다른 한편으로는 100이 아닌 3개의 객체만 설정했습니다.

왜 중요합니까?
아마도 당신의 눈이 머리 밖으로 굴러가면서 “좋아 루이스, 수동으로 항목을 배열에 할당하고 바퀴가 빠지는 것을 지켜보고 있습니다. 그것은 JavaScript가 아니라 당신을 이상하게 만듭니다.”

그 입장은 이해하겠습니다. 하지만 중첩된 for 루프에서 무언가를 하고 있는데 잘못된 반복자를 선택하거나 엉터리 계산을 한다고 잠시 상상해 보세요.

어느 순간 '나는 왜 예상한 결과, 예상한 결과, 정의되지 않은, 예상한 결과가 나오는 걸까'라는 생각은 광기로 변하고, 곧 눈물을 흘리게 될 것입니다! 당신이 하려는 일을 수용할 수 있을 만큼 어레이가 마술처럼 성장했다는 사실은 거의 알지 못했습니다.

유일한 문제는 당신이 잘못된 일을 하려고 했다는 것입니다.

C#과 같은 다른 언어와 비교하자면(특별한 이유 없이) 배열의 길이는 고정되어 있습니다. 배열을 생성할 때 길이를 정의해야 합니다. List와 같은 다른 동적 컬렉션 개체의 경우에도 정의되지 않은 인덱스에 할당할 수 없습니다. 따라서 중첩 루프가 이전에 할당되지 않은 인덱스에 쓰려고 하면 프로그램에서 오류가 발생합니다.

예외는 좋지 않지만 아마도 옳은 일일 것입니다. 내 말은, 스위스 치즈 배열을 만들겠다는 뜻이 아니었나요? 그렇게 하려는 사람이 있나요? 바라건대 그렇지 않습니다.  

개발자가 스위스 출신이라면 스위스 치즈 어레이뿐이다. 그렇지 않으면 반짝이는 나쁜 프로그래밍일 뿐입니다.

프리미티브에 속성 추가는 무시됩니다.

우리는 JavaScript에서 프로토타입에 새로운 기능을 할당할 수 있다는 것을 알고 있습니다. 따라서 문자열이나 배열에 ✨특별한 능력✨을 부여할 수 있습니다. 물론 그렇게 하는 것은 문자열 프로토타입이 다른 문자열 프로토타입과 다르게 동작하게 되어 이미 많은 개발자에게 말할 수 없는 가슴 아픈 일을 안겨주기 때문에 끔찍한 습관입니다.

예를 들어 다음과 같이 할 수 있습니다.

function returnSomething()
{
  return
    {
      name: 'JavaScript Expert'
      contactMethod: 'Shine batsign at sky'
    }
}

그런 다음 문자열 개체를 만들 수 있습니다.

function returnSomething()
{
  return ; // <-- semicolon inserted by ASI, remainder of function not evaluated.
    {
      name: 'JavaScript Expert'
      contactMethod: 'Shine batsign at sky'
    }
}

그러면 false가 반환됩니다.

문자열이 작동하는 방식에 대한 공장 정의 구현에 함수를 무작위로 넣을 수 있다는 점이 귀엽습니다.

물론, 그 좋은 사람들은 모두 허리를 부러뜨리고 TC39 사양에서 JavaScript를 정의하는 데 수만 시간을 소비했습니다. 하지만 그렇다고 해서 적절하다고 생각되는 대로 임의의 기능을 실행하는 것을 단념하지 마십시오.

우리가 특정 유형의 고통이 마음에 들지 않으면 원하는 대로 복잡한 개체에 새로운 기능을 무작위로 할당하여 코드가 매우 특별한 형태의 넌센스가 되도록 할 수도 있습니다. 이 코드는 오직 자신과 신만이 이해할 수 있습니다. :

이와 같이 객체를 구성하는 것은 당연히 끔찍한 생각이지만, 우리가 이러한 배신을 저지르기 때문에 JavaScript는 우리의 요청을 의무화합니다. 우리의 testObject는 우리가 던진 새로운 함수를 취합니다.

그러나 놀랍게도 객체 원시형에서는 선의가 소진됩니다.

인터프리터는 문자열 프리미티브에 함수를 할당하려는 우리의 시도를 인정합니다. 심지어 우리에게 그 기능을 다시 반영합니다. 그러나 호출을 시도하면 TypeError가 발생합니다. testString.onlyFalse는 함수가 아닙니다. 이를 수행할 수 없는 경우 일반적으로 함수 호출이 아닌 할당 시 발생할 것으로 예상합니다.

왜 중요합니까?
좋든 나쁘든 JavaScript는 매우 유연하고 동적인 언어입니다. 이러한 유연성 덕분에 다른 언어에서는 불가능한 기능을 구성할 수 있습니다. 뭔가가 작동하지 않으면 예외가 발생해야 합니다. JavaScript가 이 어색한 명령을 받고 "어, 알았어"라고 말한 다음 이를 잊어버리면 이러한 근본적인 기대가 바뀌게 됩니다.

유형 강제

다른 강력한 유형의 언어에서는 저장하기 전에 저장하는 데이터의 유형을 정의해야 합니다. JavaScript에는 이와 같은 종류의 제한이 없으며 객체가 정의된 유형에서 멀리 떨어져서 함께 잘 작동하도록 노력합니다.

한편으로는 변수를 해당 유형으로 앞뒤로 캐스팅하지 않아도 됩니다. 그래서 편리합니다:
부울의 경우에도 마찬가지입니다.

이 접근 방식은 우리가 "추가"라고 알려진 금기 의식에 참여하기를 원할 때까지 완전히 건전하고 타당합니다. "1"과 1을 더하려고 하면 어떻게 될까요? 유형 강제는 어떤 방식으로 진행되나요?

파티에 부끄러움을 가져오면 광기의 즐거움이 배가됩니다.

아 — 부울이 어떻게든 내부 숫자이기 때문인가요?
아니요. 부울입니다. JavaScript는 이유 때문에 사각형의 성가신 가장자리를 깎아내어 둥근 구멍에 맞춥니다.

왜 중요합니까?
숫자를 더하는 것과 같은 기본적인 작업을 수행할 때 결과가 다양해지면 이상한 버그가 발생할 수 있습니다. 유형을 서로 바꾸면 의도한 결과가 나오지 않을 수 있으므로 비교할 때 삼중 등호(===)를 고수하는 것이 좋습니다.

함수 호이스팅

오늘날 우리가 사용하는 언어에서 중요한 측면은 '함수 호이스팅'이라는 것입니다. 기본적으로 이는 파일의 원하는 위치에 함수를 작성할 수 있고 함수가 선언되기 전에 호출할 수 있음을 의미합니다.

function returnSomething()
{
  return
    {
      name: 'JavaScript Expert'
      contactMethod: 'Shine batsign at sky'
    }
}

작동시키기 위해 코드 순서를 수동으로 변경할 필요가 없기 때문에 편리합니다.

하지만 함수를 설명하는 방법은 여러 가지가 있습니다. 이 예에서는 이를 위해 함수 선언을 사용했습니다. 함수 표현식을 사용할 수도 있습니다:

function returnSomething()
{
  return ; // <-- semicolon inserted by ASI, remainder of function not evaluated.
    {
      name: 'JavaScript Expert'
      contactMethod: 'Shine batsign at sky'
    }
}

왜 중요합니까?
두 경우 모두 함수 선언에 큰 차이는 없지만, 잘못된 함수를 선택하면 함수를 선언한 후 호출하지 않는 이상 함수를 호출할 수 없게 됩니다.

Null은 객체입니다.

다른 언어에서는 개체 속성을 할당하거나 null일 수 있습니다. null은 속성이 할당되지 않았음을 나타냅니다. 우리 머릿속에서 동일시하는 것은 간단합니다. 거기에 객체가 있거나 null이 있습니다. 원한다면 속성을 다시 null로 할당할 수도 있습니다.

JavaScript는 null과 정의되지 않음을 포함하여 이러한 환경을 복잡하게 만듭니다. 하지만 다 똑같죠? 손에 공이 있거나 없거나 둘 중 하나입니다.

놀랍지도 않게 모두 똑같지는 않습니다. JavaScript에서 null은 의도적으로 값이 없음을 나타내는 반면, 정의되지 않음은 묵시적으로 값이 없음을 나타냅니다. 그러니까 고의적이든 명시적이든, 하늘에 쓴 것이든 가치 없음 = 가치 없음이라는 사실이겠죠?

다시 말하지만, 불행하게도 방정식은 그렇지 않습니다.

그럼 undefine의 종류는 뭔가요?

그렇습니다. null 유형은 무엇인가요?

? 그것은 객체입니다. 따라서 JavaScript에서는 복합 객체와 null의 유형이 동일합니다. 둘 다 객체입니다.

왜 중요합니까?
JavaScript에는 강력한 유형 검사 시스템이 내장되어 있지 않으며 선택할 수 있는 기본 유형은 소수뿐입니다. 따라서 변수의 내용을 이해하기 위해 typeof를 사용하는 것은 까다로울 수 있습니다. 변수에 유효한 개체가 있으면 개체를 얻습니다. 그러나 null인 경우에도 여전히 객체를 얻습니다. null 참조가 객체라고 생각하는 것은 직관에 어긋납니다.

결론

오늘날 언어로서 JavaScript의 엄청난 인기에 대해서는 의심의 여지가 없습니다. 시간이 흐르고 npm과 같은 다른 생태계가 계속해서 엄청난 수의 패키지를 호스팅함에 따라 JavaScript의 인기는 계속해서 높아질 것입니다.

하지만 할 일은 끝났습니다. null이 객체이거나 JavaScript가 적절하다고 판단되는 위치에 세미콜론을 표시한다는 것이 아무리 이상하더라도 이러한 시스템은 결코 더 이상 사용되지 않거나 변경되거나 제거되지 않을 것입니다. 일화로 말하자면, 자동 세미콜론 주입이 밤새 꺼지면 CrowdStrike 업데이트보다 더 큰 글로벌 중단이 발생할 수 있습니다.

물론 이들 중 하나를 변경하면 웹에 큰 혼란을 가져올 수 있습니다. 실제로 원래 문제로 돌아가서 해결하는 것보다 개발자에게 이러한 특정 언어의 단점을 인식하도록 하는 것이 실제로 더 안전하고 아마도 더 실용적일 것입니다.

그래서 좋은 선택을 하시고 세미콜론을 사용하는 것을 잊지 마세요!

---

LogRocket: 컨텍스트를 이해하여 JavaScript 오류를 더 쉽게 디버깅합니다.

코드 디버깅은 항상 지루한 작업입니다. 하지만 오류를 더 많이 이해할수록 오류를 수정하는 것이 더 쉬워집니다.

LogRocket을 사용하면 이러한 오류를 새롭고 독특한 방식으로 이해할 수 있습니다. 당사의 프런트엔드 모니터링 솔루션은 JavaScript 프런트엔드에 대한 사용자 참여를 추적하여 오류를 초래한 사용자의 행동을 정확하게 확인할 수 있는 기능을 제공합니다.

LogRocket은 콘솔 로그, 페이지 로드 시간, 스택 추적, 헤더 본문이 포함된 느린 네트워크 요청/응답, 브라우저 메타데이터 및 사용자 정의 로그를 기록합니다. JavaScript 코드의 영향을 이해하는 것은 결코 쉬운 일이 아닙니다!

무료로 사용해 보세요.

위 내용은 JavaScript에 대해 당신이 모를 수도 있는 6가지 사실의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!