Подходит ли Typescript для вашего проекта?

В последние годы Typescript переживает всплеск популярности. Действительно, это один из самых быстрорастущих популярных языков. Причина популярности TS заключается в том, что это строгая типизированная переформулировка javascript, одного из самых популярных в мире языков, глубоко укоренившегося в ядре Интернета. Javascript, как вы, возможно, уже знаете, использует простую систему динамической типизации, которая просто не идеальна для многих контекстов программирования. JS плюс строгая типизация — привлекательная комбинация для разработчиков, стремящихся создавать более надежные и масштабируемые веб-приложения.

При всех своих достоинствах машинописный текст имеет и свои недостатки. Выбрать его для своего проекта не всегда просто. Как и любой язык программирования или диалект, он лучше для одних случаев использования и хуже для других. Поэтому полезно взвесить достоинства TS, а не принимать как данность то, что это просто следующая эволюция JS. Некоторые из преимуществ, как оказалось, также могут быть недостатками в зависимости от варианта использования.

Ниже приведены некоторые мысли о Typescript после его интенсивного использования в течение последних нескольких лет. Программная инженерия — это и искусство, и наука. Таким образом, в то время как как работают языки — это основанный на фактах вопрос «все или ничего», где вы либо правы, либо не правы, есть также и более субъективные нюансы в отношении того, когда, где и почему использовать инструменты, где информированное мнение важнее. чем техническая необходимость имеет место.

Преимущества

Строгая типизация делает ваш код более умным

Начнем с очевидного. Typescript позволяет вам указывать java-подобные типы для переменных и объектов. (На самом деле TS использует систему типов Java.) Это позволяет вам делать это как во время объявления переменной, так и для определения формы данных именованных объектов через спецификацию интерфейсов. Итак, у меня может быть функция:

функция doSomething(параметр1: число, параметр2: строка){

// что-то

Где я указываю типы параметров функции в объявлении. Я также могу определить более структурированный тип, состоящий из примитивов типа, через интерфейс:

interface DataObject { prop1: string; реквизит2: число; }

И укажите это как тип параметра или переменной:

функция doSomething(param1: DataObject)…

Вскоре я перейду к конкретным причинам, по которым эта схема типизации хороша для JS, особенно в отношении подводных камней динамической и неявной системы типизации ванильного JS. На данный момент наиболее очевидная причина заключается в том, что это обеспечивает предсказуемость и регулярность передачи данных по приложению. Строгая типизация не только упорядочивает код и обеспечивает более надежную стандартизацию, но также сообщает разработчику, чего ожидать.

Typescript самодокументируется

Одним из преимуществ явной типизации является то, что она сообщает вам о ваших данных. Указав типы, TS избавляет от некоторых догадок и делает код более чистым. Чем больше я начал использовать TS, тем яснее я начал думать о данных, перемещающихся по приложению, и о том, что должно входить и выходить из различных функций просто потому, что я мог сказать, чего ожидать, читая код. Я мог сказать, просто взглянув на него, что для этой функции я должен передать строку и получить число. И это помогает при отладке, когда TS уведомляет вас о том, что вывод не соответствует ожидаемой схеме. Если результат должен иметь определенные обязательные свойства, но возвращается с их отсутствием, вы знаете, что что-то пошло не так. Внедряя явный режим типизации, TS поощряет вас вести самодокументирующуюся книгу всех типизированных элементов в вашем коде, которая обеспечивает удобную справку, когда вам нужно искать, какие данные требуются. К счастью, этот атрибут самодокументирования предоставляется бесплатно как побочный продукт простого написания кода на машинописном языке, как и предполагалось.

TS заставляет вас думать о ваших данных

Можно сказать, что небрежное печатание приводит к небрежному мышлению, что приводит к дряблому коду с ошибками. TS помогает усовершенствовать ваше мышление и ваш код, создавая явную модель ваших данных. С vanilla JS эта модель данных существует в лучшем случае только в головах разработчиков, а в худшем — только в теории где-то в эфире, потому что никто не остановился, чтобы фактически определить ее. Модели данных предназначены для других языков, JS заставляет вас поверить. Это нормально быть ленивым. TS заставляет вас выполнять больше работы, но стоит иметь явную модель ваших данных. Эта дополнительная работа поддается более дисциплинированной практике кодирования, следовательно, более качественным конечным продуктам.

Проверка типа машинописного текста во время компиляции

Один из самых печально известных недостатков vanilla JS заключается в том, что он выполняет проверку типов во время выполнения и имеет очень свободные и прощающие правила в отношении ошибок типов. Короче говоря, JS позволяет вам компилировать код, который имеет неразрывные ошибки типов, и даже выполняет динамическое приведение типов и обрабатывает случайное число как строку и так далее. TS, напротив, проверяет во время компиляции, а это означает, что ошибки, которые могут привести к проблемам в производстве, могут быть пресечены в зародыше. Что TS здесь делает, так это заставляет вас защищать ваш код в будущем. Хотя код действительно может скомпилироваться с этими ошибками типов и даже работать без сбоев — на данный момент — вполне может возникнуть какая-то непредвиденная ситуация в будущем, когда эта ошибка типа JS беззаботно пропускает код. Затем приходится рыться в кодовой базе, чтобы отследить источник проблемы, потому что за это время сложность кода выросла непропорционально. TS придерживается принципа «проваливай быстро, проваливай громко». Typescript поощряет более жесткий контроль над тем, что ваш код будет делать во время выполнения, сглаживая детали во время компиляции.

Этому довольно легко научиться, если вы уже знаете JS

С оговоркой, что его сложно освоить. Если вы знаете JS, вы много знаете о TS. В этом отношении для разработчика, знающего JS, это немного халява. TS по-прежнему JS под капотом. Когда дело доходит до комбинирования типов и создания более тонких вложенных интерфейсов, TS может стать немного неуклюжим.

Это настраивается

TS не заставляет вас использовать его за пределами той тонкой точки, которая отличает его от ванильного JS. Включение файла tsconfig в ваш проект определяет правила того, что будет делать TS. Конфигурационный файл позволяет вам отключить кое-что из того, что вам может не нравиться в TS, или позволяет вам быть приверженцем выявления конкретных проблем, которые вызывают у вас паранойю и непреклонны в отношении исключения из производственного кода. В частности, атрибут compilerOptions позволяет вам указать, что вы хотите, чтобы TS делал во время компиляции. Эта настраиваемость оставляет за разработчиком право решать, что он хочет расставить по приоритетам. Такая настраиваемость позволяет вам свести к минимуму разочарования от TS и максимизировать его преимущества для ваших конкретных потребностей проекта или личных вкусов.

Он обходит различные эзотерические подводные камни JS

У JS несколько позорная репутация небрежного, неряшливого и смутно продуманного языка. Со временем JS стал более стандартизированным и усовершенствованным, но в его концептуальной ДНК есть компоненты, в частности система типизации, которые ставят многих разработчиков в тупик. («null» — это объект? «NaN» — это число?). Практическим примером этих странностей является динамическое приведение типов в JS, которое требует неявного знания правил и синтаксиса, которые могут поставить под угрозу кодовую базу. Поэтому, если вы не помните об использовании строгого равенства ===, JS оценит `1' == 1 как истинное. Вы спросите себя: зачем мне это нужно? Вы также должны помнить, что выражение «1» + 1 будет рассматриваться как конкатенация строк и оцениваться как «11». Тем не менее, почему бы произвольно не рассматривать это как сложение и не оценивать до 2? Почему я должен помнить, что «+» здесь означает конкатенацию, а не сложение? JS использует «+» как в качестве оператора сложения, так и в качестве оператора конкатенации, но, поскольку вы не можете вычитать, умножать или делить строки, все другие арифметические операторы, используемые в приведенном выше случае, будут преобразовывать строку в число, например «1» - 1` дает 0. Таким образом, это приведение типа нарушает базовую математику, делая его в значительной степени бесполезным, если вы хотите динамически расставить приоритеты чисел над строками. ТС либо научит вас приемам, позволяющим избежать этих странностей, либо предупредит вас о них, когда вы это сделаете. Яблоки больше не будут сравнивать с апельсинами.

Как только вы привыкнете к этому, вы не увидите причин возвращаться к ванильному JS

Как только вы привыкнете к этому, TS просто станет более надежным и мощным, чем JS. Используя его, вы чувствуете себя более уверенно и безопасно в коде, который пишете. Опять же, потому что, по моему опыту, TS заставляет вас больше думать о своем коде. Это само по себе может быть основным аргументом в пользу этого. TS похож на более зрелую эволюцию JS. Как бы то ни было, у ТС все же есть свои недостатки.

Недостатки

Это может быть трата времени

Это не столько о самом языке, сколько о человеческой стороне развития. Для проектов, которые должны развиваться быстро или у которых есть разработчики, привыкшие к ванильному JS, может быть много времени простоя при использовании TS, времени, которое можно было бы потратить на настоящую разработку функций. Чем строже ваш tsconfig, тем больше вы столкнетесь с неприятностями. Драконовский tsconfig прервет компиляцию даже при самых незначительных ошибках TS. Это еще один способ сказать, что чем больше вы на самом деле используете TS, тем больше это вас разочаровывает. Вы должны остановиться и подумать о своих данных. Что само по себе является хорошей практикой, но если нужно действовать быстро, TS может занять много времени. Хотя эти зависания можно смягчить в зависимости от того, как настроен файл tsconfig, у достаточно большой команды обязательно возникнут разногласия по поводу того, что необходимо. Некоторые будут возмущаться данным параметром. В зависимости от того, как он настроен, машинописный текст может дать вам эзотерическую жалобу, которая не позволит вам скомпилировать ваш код. Набор правил TS может показаться властным и властным, не позволяя вам делать что-то так, как вы предпочитаете.

Это может быть неприятно, когда известно, что эта конкретная ошибка типа объективно несущественна, учитывая конкретные обстоятельства и контекст, в котором она возникает, но TS упорно отказывается компилироваться. Такие ограничения могут ограничивать автономию разработчиков. Это может уменьшить потенциальную человеческую ошибку, но также может уменьшить творческий потенциал и гибкость в решении проблем. tsconfig диктует, как должна быть написана кодовая база, в лучшую или худшую сторону. Конечно, это вопрос споров о том, хорошо ли то, что хорошо для кодовой базы — теоретически — также хорошо и для программистов — или для сроков на практике. У разных команд может быть разная переносимость боли и разные потребности. Исчисление компромиссов между более сложным кодом и дополнительным разочарованием иногда является балансирующим действием. По моему опыту, неизбежно будут жалобы и разногласия по поводу того, какие правила следует применять.

Злоупотребление <любым> как спасательным люком

Разработчики, которым нужно двигаться вперед, часто злоупотребляют типом TS <any>, который присваивает значение любому возможному типу. <any> выглядит как аварийный люк, когда вы не хотите думать о вводе данных. Злоупотребление <any> противоречит цели строгого режима типизации, но с этим можно столкнуться. Просто ожидайте, что вы начнете видеть <any> с некоторой частотой, пропорциональной тому, насколько строгость вашего tsconfig связывает руки разработчику, и степени, в которой разница между текущим временем и крайним сроком приближается к нулю. <any> обязательно появится.

У динамической печати есть время и место

Некоторым разработчикам нравится система типов JS, и они считают, что вместо того, чтобы вызывать неопределенность и изменчивость, она обеспечивает гибкость, особенно для кода, который запускается в браузере и работает с DOM. Изначально JS разрабатывался исключительно для работы в браузере и для того, чтобы сделать HTML более интерактивным и управляемым событиями. Это роль, для которой строгая типизация разумно считалась ненужной, возможно, потому, что предполагалось, что большая часть этого бизнеса будет обрабатываться на бэкэнде, а JS должен был заниматься манипулированием DOM. Первоначально JS предназначался для работы только с моделью DOM, которая как логическая модель, а не как язык программирования, не имеет формальной системы типов. По мере того, как функциональность браузера становилась все более сложной, а интерфейсные фреймворки — более изощренными, у JS внезапно появилось гораздо больше обязанностей, когда дело дошло до обработки данных.

Основная проблема с динамической типизацией заключается в том, что она предполагает неявное знание правил JS, знание, которое существует только в головах отдельных разработчиков и, следовательно, нельзя рассчитывать на его надежное и равномерное распределение по мере изменения людей, стоящих за проектом, и уровня знаний. колеблется, когда они приходят и уходят. В силу того факта, что такие знания не воплощены в самой кодовой базе, знание этих правил не может быть гарантировано с непротиворечивостью. Тем не менее, есть ситуации, особенно во внешнем интерфейсе, где безопасно или даже полезно разрешить преобразование чисел в строки и т. д., и кто-то предполагает такое поведение и планирует его. Гибкость имеет свои преимущества. Есть также ситуации, когда это не так, особенно на бэкэнде, поэтому Node без TS все чаще рассматривается как сомнительное упущение. Typescript существует, чтобы смягчить человеческие ошибки, связанные с потенциально компрометирующими решениями.

Динамическая неявная типизация также экономит труд. Он снимает трудоемкие накладные расходы на работу с типами, неявно оставляя это на усмотрение движка. Проекты меньшего масштаба или с менее чувствительными требованиями к данным могут не гарантировать использование TS.

Несмотря на возможность настройки, вы все равно будете возиться с этим

TS — это одновременно синтаксическое расширение JS и специальный набор правил. Динамическая типизация JS позволяет вам решить, когда число должно сравниваться как равное числу (используя тройной оператор строгого равенства со знаком равенства === или произвольно сравнивая строки и числа на равенство ==. Если вы хотите, можно написать JS с защитой от типов, хотя для этого потребуется много условного шаблонного кода для сравнения типов значений с использованием оператора typeof и т. д. Некоторые проекты могут вызывать определенные разделы кода, которые нуждаются в таком типе безопасности, в то время как другие могут быть менее строгими (конечно, можно комбинировать файлы TS и JS в одном проекте, поскольку TS транспилируется в JS.) Дело в том, что использование TS требует обязательств. если вы обнаружите, что отключили многие правила TS. Если вам что-то не нравится в этом, вы можете просто отключить его. Однако, если вы обнаружите, что делаете это слишком много, это просто аргумент в пользу того, чтобы не использовать машинописный текст. Если ваш файл tsconfig представляет собой просто exc используйте, чтобы избежать того, что вас раздражает в TS, тогда, возможно, пришло время переоценить, какую роль он играет в вашем стеке.

Заключительные комментарии

Это подводит меня к моему последнему замечанию о машинописном тексте. Кажется, среди разработчиков существует тенденция считать строгую типизацию стандартом объективности информатики. Без строгой типизации код становится свободным и «субъективным». Если у вас есть строгие, явные типы, ваш код будет более «осязаемым» и определенным и, следовательно, в некотором смысле более законным. Идеал здесь — выложить все карты на стол, чтобы не было неявного знания или явного невежества, которые можно было бы не заметить.

Это восходит к дискуссии об искусстве и науке. Можно сказать, что информатика для физики — это то же самое, что инженерия программного обеспечения для машиностроения: железобетонные законы первой ограничивают возможности второй в абсолютном выражении, но пока вы работаете в рамках этих ограничений, существует практически бесконечное множество способов. подойти к проблеме. Не может быть единственного способа реализовать оптимальное решение, потому что пространство возможных реализаций очень велико. Соответственно, вам потребуется неопределенное количество времени для сравнения неопределенного количества возможных реализаций.

Лучшие практики — это не непреложные законы, а эвристика, полученная из бесчисленных часов опыта, которая продвигает шаблоны кода, которые приближаются к тем областям «пространства проектирования», где обычно можно найти хорошие решения. Тем не менее, лучшей практикой является то, что лучше всего подходит для конкретного проекта и команды и ее конкретных потребностей и требований, а не то, что объективно и идеально. Чтобы изменение популярности машинописного текста было не просто тенденцией, оно должно быть оправдано.

Все, что можно сделать с помощью TS, можно сделать с помощью JS. Тот факт, что TS настраивается, является доказательством того, что он приносит мнения, пусть и хорошо информированные, а не факты о том, что лучше. Не обязательно правда, что то, что он предлагает и рекомендует, во всех случаях лучше, чем старый добрый JS. Так что не чувствуйте себя обязанным тратить время и добавлять к своему разочарованию только потому, что TS гладкий и блестящий, если проект не требует этого.