Эта статья является продолжением статьи Ошибки «налога на TypeScript.

Плохие причины отказаться от TypeScript

Тестирование важнее типов

Эти два «тестирования» и «типа» не находятся в прямой конкуренции.

TypeScript не заменяет тестирование. На практике TypeScript часто упрощает написание тестов, например, если у вас уже есть тип данных, возвращаемых компоненту из API, вы уже третье направление в написании теста, зная, что Упорядочить часть будет (в шаблоне Arrange-Act-Assert).

Но это теория. На практике, когда разработчики упоминают этот аргумент, они понимают, что они не исключают друг друга. Они означают, что — в конкретном контексте — существует давление (высшее руководство, сроки, заинтересованные стороны), которое означает, что мы должны пожертвовать некоторыми показателями качества в пользу других.

Не могу с этим поспорить — я был там. Поэтому я обращусь к Программисту-Прагматику внутри вас.

В подобных ситуациях и проектах TypeScript очень важен. Потому что на практике, когда это давление возрастает, первая мера качества, которая попадает в список невыполненных работ, — это «тесты». Это становится техническим долгом, который никогда не решается, потому что — в организации такого типа — давление никогда не прекращается.

Типы сложнее игнорировать, чем тесты. С TypeScript типы у вас на виду, вам действительно нужно предпринять активное действие (например, пометить аргумент как любой ), чтобы игнорировать типы, в то время как вы можете пассивно игнорировать тесты, избегая чувства технической вины. или ответственности.

Даже если вы начнете использовать любой везде, вы, по крайней мере, получите простые типы и некоторые из предполагаемых типов. И это отличное место для начала, учитывая, что альтернатива — отсутствие тестов и типов.

Дополнительное время для написания и поддержки типов

Хотя TypeScript действительно увеличивает время, эту стоимость следует рассматривать с разных точек зрения:

Типы добавленных значений

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

Тесты также отнимают время на написание и сопровождение

Было бы неточно подразумевать, что только типы имеют временные затраты. Тесты также требуют значительного дополнительного времени для поддержки и написания, даже больше, чем типы, по моему опыту. Если вы работаете в организации с приличным тестовым покрытием, вы, должно быть, сталкивались с ситуацией, когда вы писали функцию за считанные минуты, а потом часами писали или обновляли тест.

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

Шаблоны в TypeScript быстро появляются

Хотя TypeScript обширен, на практике шаблоны начинают быстро появляться для большинства ваших случаев использования, когда вы создаете конкретное приложение. Допустим, мы создаем приложение React, и вы не знаете TypeScript, вы быстро научитесь определять свойства для компонента (и я считаю, что их объективно легче запомнить, чем синтаксис propTypes), вы обнаружите, что вы всегда можно определить тип для ответа API, а затем использовать его через уровень/библиотеку API в коде, который уже предоставляет типы. Как новичок, вам, возможно, придется немного потрудиться, чтобы понять использование шаблонов в useState, но вывод типов сэкономит вам большую часть времени, а затем, как только вы сделаете это один раз, вы будете повторять.

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

Другие причины

Некоторые «плохие» причины проявляются в общих выводах без особых доказательств. Попробуйте подвергнуть их сомнению и посмотреть, насколько они сильны: если кто-то утверждает, что «у нас редко бывают ошибки типов», поищите в своей истории коммитов слова «с ошибками», «не определено». », «null» или «.legnth», вы, скорее всего, найдете несколько примеров — лучшее тестовое покрытие отловило бы их, но поскольку мы, очевидно, не Если бы у вас не было такого покрытия, не стоило бы изучить способы избежать подобных проблем. Если кто-то утверждает, что «вывода кода в IDE достаточно», то покажите им разницу в использовании компонента React, написанного на Typescript, по сравнению с компонентом, использующим propTypes, и если последующее утверждение состоит в том, что «мы должны улучшить документацию», то действительно ли это стоит меньше поддерживать документацию, чем поддерживать типы?

Неплохие причины для отказа от TypeScript

Избегайте шумихи

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

Тем не менее, дорога ажиотажа имеет много остановок перед TypeScript: использование сложной библиотеки управления состоянием без причины, стремление к сквозным автоматическим тестам для всего (и бесконечная борьба с ненадежностью и растущими затратами), монорепозитории ради этого, водопад, представленный как agile (scrumfall), TDD сам по себе был большим ажиотажем, а BDD все еще им пользуется, и дорога ведет к микросервисам, микрофронтендам, kubernetes и многому другому. Все это стоит гораздо дороже, чем выбор языка.

Итак, разговоры о TypeScript в вашей организации вызваны ажиотажем или настоящим стремлением к лучшему качеству?

Вопрос, на мой взгляд, имеет философское значение (и может указывать на более глубокую культурную проблему в организации), но он имеет очень мало практического значения в конкретном разговоре о TypeScript.

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

В случае с TypeScript вы могли начать с любого конца: определить проблему и подумать, что TypeScript решит ее, или посмотреть на решение и задаться вопросом, какую пользу оно вам принесет (после шумихи). Я не думаю, что какой-либо из этих подходов неверен, если вы проведете исследование и проанализируете, что означает — для вашего конкретного контекста — переход на TypeScript. Чрезмерный акцент на подходе отвлекает внимание от анализа рентабельности инвестиций TypeScript, который должен быть основным вопросом.

Решение перейти на TypeScript далеко идущее

Это полуправда.

Это перспективно, но не с технической точки зрения. Воздействие на людей велико: влияние на их уверенность, психология боязни перемен, необходимость вкладывать средства в переобучение и наставничество.

Переход на TypeScript имеет много далеко идущих последствий, но технические не обязательно являются самыми важными. Причина в том, что стоимость отказа от TypeScript — если это не сработает — незначительна. TypeScript — это надмножество JavaScript, и буквально одной командой можно вернуться в бестиповую страну JavaScript. Сравните это с переходом с Redux на другую библиотеку управления состоянием, и вы поймете, что с точки зрения кода TypeScript — далеко не самое далеко идущее решение в вашем техническом стеке.

Адаптация затруднена

С точки зрения программирования, самым сложным для меня было присоединиться к компании, где основным технологическим стеком был Vue с TypeScript. Я тоже не знал, и это было тяжело.

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

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

Это также касается наличия четкого набора ожиданий относительно того, что вам нужно делать и когда вам нужно это делать.

Для этой роли Vue и TypeScript ожидалось, что я изучу их на работе. Мне было предоставлено время и поддержка для изучения обеих технологий. Если бы от меня ожидали, что я буду на 100% продуктивным с первой недели, то я бы потерпел неудачу. И это была бы их вина.

Это относится как к TypeScript, так и к любой другой технологии. Когда мне впервые пришлось работать с кодовой базой, используя redux, я боролся (и до сих пор борюсь) с redux-saga, react-query. Любая самоуверенная библиотека или новая технология требует обучения, и для эффективной работы требуется время. Я не думаю, что адаптация TypeScript особенно сложнее, чем эти другие технологии, если (и это большое «если») у всех есть поддержка и время для изучения.

Синтаксический шум

У меня опыт работы с C#/Java, и моя ментальная модель выражения типа заключалась в том, чтобы сначала объявить тип, а затем имя переменной String name;. Что-то такое простое, как изменение этого порядка, чтобы сказать let name: String; в TypeScript, было очень трудно принять. Я был удивлен тем, как относительно небольшая деталь настолько укоренилась в моей голове, что в течение первых нескольких недель, когда я смотрел на код TypeScript, все, что я видел, был визуальный шум.

Это относится к следующему пункту о кривой обучения. Но tldr; заключается в том, что вы привыкнете к дополнительному шуму. Но если вы, как и я, раньше только использовали другие строго типизированные C-подобные языки, то потратьте некоторое время на чтение Руководства по TypeScript для Java/C#, и это значительно облегчит вам путь к принятию TypeScript. Полегче.

Веские причины отказаться от TypeScript

Кривая обучения

Я признаю, что TypeScript требует значительного обучения.

Я уже говорил, что на практике подмножество TypeScript, которое вы будете использовать в проекте, имеет тенденцию повторяться и следовать определенным шаблонам, поэтому немного осознанного копирования/вставки может помочь вам с TypeScript на начальном этапе.

Но вы неизбежно столкнетесь с тем, что захотите должным образом изучить TypeScript.

Для меня это похоже на то, когда JavaScript и SPA становились популярными. У меня был опыт работы с C#, и в течение многих лет я полагал, что могу кодировать JavaScript только потому, что он немного похож на C#. Я использовал шаблоны и знания из C# и постоянно жаловался на JavaScript. Затем я прочитал JavaScript: хорошие стороны и понял, что пишу код на JavaScript, толком не зная JavaScript.

То же самое относится и к TypeScript. Мой ага-момент наступил, когда я прочитал Effective TypeScript. На самом деле, мой ага момент был, когда я только что закончил третью главу книги. Это щелкнуло для меня, и с этого момента с TypeScript все было гладко.

Дело в том, что я должен был остановиться и изучить его. Через некоторое время уже недостаточно взмахнуть. И если ваша организация или обстоятельства и давление на проект не позволяют надлежащему обучению, то кривая обучения, безусловно, является хорошей причиной для отказа от TypeScript.

Отсутствие плана перехода на TypeScript

«Сейчас мы все переводим на TypeScript» — это не план действий. Суть разговора о рентабельности инвестиций заключается в том, что контекст имеет значение. Этот контекст распространяется на отдельные проекты, а не только на отдельные организации.

В организации среднего размера у вас обычно может быть множество проектов:

  • Общественные проекты
  • Внутренние проекты
  • Внутренние библиотеки пользовательского интерфейса
  • Общие служебные библиотеки
  • Внутренние инструменты
  • Проекты Greenfield, Brownfield и Proof of Concepts

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

В план также должны быть включены люди:как преодолеть разрыв в знаниях между теми, кто знает TypeScript, и теми, кто не знает.

Цифровой разрыв

Без плана перехода на TypeScript вы можете получить двухуровневую организацию: некоторые — «граждане первого класса», которые знают TypeScript и могут создавать все новые блестящие вещи, а другие остаются позади.

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

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

Эта поддержка в контексте TypeScript выглядит так:

  • Дайте время, ресурсы и пространство для обучения: в моем случае это означало, что компания получила копию книги, но это мог быть доступ к учебному сайту или просто время для экспериментов — люди учатся по-разному, поэтому адаптируйтесь к этому.
  • Создайте канал/группу для TypeScript: Помимо основ, иногда трудно понять, как выразить идею в TypeScript или даже как задать вопрос в Google. Часто эффективнее спросить коллег, а простой указатель может сэкономить вам часы.
  • Обзоры кода: хорошие обзоры кода были ключом к изучению TypeScript. Возьмите в привычку отмечать людей, которые знают об этом немного больше, это поможет вам обоим стать лучше.
  • Парное программирование: даже если вы не являетесь поклонником парного программирования, стоит поработать в паре с другими разработчиками, особенно в начале.
  • Чемпион TS: В моем случае это был один коллега по работе — Хуан Карлос Ароча — который взял на себя ответственность отстаивать TypeScript и помогать другим принять его, а затем принять. Его роль была неформальной, но он часто просматривал PR, хватался за импровизированные звонки, чтобы объяснить точку зрения, писал посты и заметки о своих новых знаниях, и он делал все это с сочувствием и терпением. В моей команде это оказало наибольшее влияние на эффективный переход на TypeScript. Это не всегда возможно, и это большая просьба от всех. Но если у вас есть Хуан, дайте ему время и пространство, чтобы заниматься своими делами, и это окупится.

Далее я расскажу о том, что означает внедрение TypeScript на практике. Часто это не решение по принципу «все или ничего». Существует типичная модель зрелости, которую я попытаюсь определить и проанализировать; начиная с нестрогого режима, использования any, утверждений и приведений, ужесточения и уточнения типов, распознавания и документирования шаблонов и передовой практики, написания тестов на TypeScript (или нет) и т. д.