나는 과거에 타자를 치는 것은 시간을 낭비하는 것이라고 생각했다.지금 나는 생각을 바꾸었다.

8913 단어 webdevjavascript
나에 대해: 지금까지 나는 이미 전문적인 웹 개발자가 된 지 10년이 넘었다.저는 현재 Better Coding Academy의 수석 인터넷 개발 강사입니다. 제 업무의 일부로서 저는 저희 유튜브 채널에 동영상을 발표했습니다.
(멋진 웹 개발 콘텐츠 구독!)
6개월 전에 Dev에 다음 게시물을 게시했습니다.
나를 기쁘게 한 것은 평론 부분이 타자 언어의 시간 경제에 관한 우호적이고 열정적인 토론으로 바뀌었다는 것이다.
벌써 6개월째야.나는 이미 생산 환경에서 10000여 줄의 TypeScript 코드를 썼는데, 지금 내가 이 글을 쓰는 것은 내가 원시 댓글에서 표현한 생각에 대한 보충이다.
저는 현재 다양한 생산 환경을 위해 40000여 줄 흐름 코드와 10000여 줄 TypeScript 코드를 작성했습니다.나는 결코 완벽한 개발자가 아니다. 비록 내가 이미 10년 동안 (생존 위기에서 울고) 인코딩을 했지만, 나는 나의 지능이 충분히 유연해서 새로운 증거를 받을 때 생각을 바꿀 수 있다고 믿고 싶다.

그래, 그럼 너의 관점은 도대체 무슨 변화가 생겼니?


나는 원작에서 네 가지 요점을 제시했다.
  • 전문가는 진정한 전문가가 아니다.
  • 에 입력한 JS는 매우 길어서 읽기 어렵다.
  • JS 유형은 여전히...입력하지 않았습니다.
  • 비유형 JS가 뭐가 안 좋아요?
  • 나는 더 이상 상기 네 가지에 동의하지 않는다. 나는 아래에서 모든 것에 대한 나의 이해를 공유할 것이다.

    프로는 진정한 프로가 아니다.


    이 글을 쓸 때, 나는 많은 타자 전도자들이 당국(즉 대기업)에 호소할 것이라고 생각한다. 왜냐하면 믿을 만한 이유가 있기 때문에, 네가 왜 타자를 사용해야 하는지.
    이에 대해 나는 지난 글에서 다음과 같이 썼다.

    However, if you honestly think about it, this argument falls apart reductio ad absurdum:

    Big companies use TypeScript, therefore I should use TypeScript.

    Big companies also use legacy systems, therefore I should use legacy systems.


    비록 나는 이 말을 거두지 않았지만, 나는 Vanilla JavaScript가 아닌 TypeScript를 사용할 때 진정한 장점이 있다는 것을 점차 알게 되었다.설명 좀 할게요.

    입력한 JS는 매우 길어서 읽기 어렵다.


    나는 나의 원시 문장에서 다음과 같은 예시를 사용했다.이것은 코드의 유형이 아닌 버전입니다.
    import React from 'react';
    import ApolloClient from 'apollo-client';
    
    let apolloContext;
    
    export function getApolloContext() {
      if (!apolloContext) {
        apolloContext = React.createContext({});
      }
      return apolloContext;
    }
    
    export function resetApolloContext() {
      apolloContext = React.createContext({});
    }
    
    TypeScript의 동일 버전입니다.
    import React from 'react';
    import ApolloClient from 'apollo-client';
    
    export interface ApolloContextValue {
      client?: ApolloClient<object>;
      renderPromises?: Record<any, any>;
    }
    
    let apolloContext: React.Context<ApolloContextValue>;
    
    export function getApolloContext() {
      if (!apolloContext) {
        apolloContext = React.createContext<ApolloContextValue>({});
      }
      return apolloContext;
    }
    
    export function resetApolloContext() {
      apolloContext = React.createContext<ApolloContextValue>({});
    }
    
    이 준칙에 관해서 나는 다음과 같이 말했다.

    I genuinely don't find them more readable in most cases.


    그러나 나는 이 방면에서 생각을 바꾸었다.몇 달 동안 매일 문법을 본 후에 나는 이미 매우 익숙해졌다.그 밖에 나는 이런 문법이 그 유형에 대응하는 문법에 비해 제공하는 장점을 감상하는 것을 배웠다.

    입력한 JS는 그대로...입력하지 않았습니다.


    because TypeScript compiles down into JavaScript, regardless of how carefully designed your types are, there always is the chance that a different value type sneaks into a JavaScript variable. It's unavoidable - JavaScript is still untyped.


    이 방면에서 나도 생각을 바꾸었다.물론 어떤 종류의 의외의 값도 당신이 원하지 않는 곳으로 잠입할 수 있습니다.그러나 이것은 정적 유형 검사가 완전히 불필요한 것을 의미하지는 않는다.
    이것은 마치 내가 자신을 다치게 할 가능성이 매우 작기 때문에 이것은 내가 영원히 어떤 형식의 역도 훈련을 하거나 이를 위해 단련해서는 안 된다는 것을 의미한다.
    자신을 이상하게 만드는 허위를 바로잡지만, 나는 계속할 것이다.

    비유형 JS가 뭐가 안 좋아요?


    If there is hard statistical data that using untyped JavaScript vs. TypeScript means that productivity decreases by any significant amount (if at all), then I wouldn't mind the verbosity of TypeScript.


    ...이것이 바로 내가 아직 이 데이터를 보지 못한 곳이다.
    물론 이것은 매우 큰 요구이다. 나는 이런 증거가 (영원히) 기존의 것이 되기를 원하지 않는다.

    그러나 이러한 통계 데이터가 있든 없든 나는 여전히 비형식 자바스크립트가 괜찮다고 믿는다.사실 지금부터 저는 대부분의 생산 프로젝트에서 Vanilla JavaScript를 계속 사용할 수 있습니다. 이유는 다음과 같습니다.

    잠깐만, 그럼 너는 더 이상 TypeScript를 사용하지 않겠니?


    아니.나는 몇 달 동안 사용자 정의 형식 성명을 작성하는 것부터 연합 형식을 사용하는 것, 그리고 플러그인 범주를 사용하는 것까지 본질적인 문제에 깊이 들어갔다.이것은 절대로 가벼운 용법이 아니다.
    그러나 나는 미래의 생산 프로젝트에서 Vanilla JavaScript를 계속 사용하기로 결정했다.
    TypeScript를 사용할 때 몇 가지 문제를 발견했습니다. 현재 상황을 고려할 때 저는 여전히 이런 문제들이 참기 어렵다고 생각합니다.

    TypeScript 에 좋은 문서 기록이 없습니다.


    나는 이 일에 있어서 틀렸다는 것이 절대로 증명되기를 바란다.
    물론 숫자 변수나 단순 함수를 입력할 때 많은 문서가 있지만, 예를 들어 한 고급 함수가 다른 함수를 만들었는데, 이 함수는 어떤 방식으로 그 대상에 전달되는 것을 조종하는 것은 어떻습니까?나는 범용 같은 것을 사용해서 이런 함수를 입력할 수 있다고 확신하지만, 나는 공식적인 TypeScript 문서를 통해 어떻게 입력하는지 이해할 수 없다.
    나는 자주 어떤 유형의 타자 문제에 부딪힌다.내 코드, 구성으로 인한 것일 수도 있고, TypeScript의 버그일 수도 있습니다.예를 들어React의 유사한 문제는 몇 분 안에 온라인 검색을 통해 쉽게 해결할 수 있다. 나는 모든 문제에 한 시간 이상을 소비하는 것을 발견했다. 이것은 나의 다음 점을 완벽하게 인도했다.

    나는 여전히 더 빨리 코드를 작성해야 한다.


    TypeScript를 채택한 이후로, 나는 나의 기능 생성 속도가 대폭 떨어지는 것을 알아차렸다.이것은 매우 일리가 있다. 나는 같은 기능을 완성하기 위해 더 많은 코드를 작성하고 있다.
    프로젝트의 마지막 기한에 있어서 나는 종종 회전할 여지가 거의 없다.
    통상적으로 나의 가장 중요한 임무는 기능이 좋은 테스트를 거치도록 확보하고 가능한 한 빨리 생산을 위해 준비를 하는 것이다. 이것은 나에게 있어서 각종 유형의 테스트를 사용하여 코드에 대한 자신감을 높이는 것을 의미한다.
    불행하게도, 이것은 나의 가장 중요한 임무가 종종 문서, 정적 유형의 코드를 가지고 있는 것이 아니라는 것을 의미한다.
    이것은 내가 직면한 맑은 현실이다.만약 당신이 이러한 마지막 기한의 제한을 받지 않는다면, (혹시 당신은 회사에서?: P에서 일할지도 모른다.) TypeScript는 당신에게 잘 어울릴 것이다.하지만 여기 계신 다른 분들께는 TypeScript가 더 많은 시간이 필요하다는 것을 알려드리고 싶습니다.그럴 거야.그러나 이것은 네가 추가 시간을 결정할 수 있느냐 없느냐에 달려 있다.

    읽어주셔서 감사합니다!


    제 글을 읽는 데 시간을 써주신 분들께 감사드립니다!나는 정말 나의 내용이 통찰력이 있기를 바란다.
    저는 유튜브에 동영상을 올리고 React, Node 등 각종 기술 유행어의 강좌를 소개했습니다.js, TypeScript, GraphQL, 마이크로서비스, Docker 등)
    예전과 같이, 나는 사랑과 겸손이 가득한 곳에서 왔다. 만약 당신이 평론에 날카롭지 않은 토론이나 비판을 남긴다면, 나는 감격을 금할 수 없을 것이다.나는 이 방면의 정보를 더 많이 이해하고 나의 관점을 형성하고 싶다.
    즐거운 인코딩!

    좋은 웹페이지 즐겨찾기