TypeScript! Машинопись! TypeScript!

Много было сказано о TypeScript, причудливом надмножестве JavaScript с открытым исходным кодом, впервые выпущенном Microsoft в 2012 году и теперь являющемся одним из самых плодовитых и самых быстрорастущих языков на GitHub. Если вы не уверены, что TypeScript выявляет ошибки, улучшает ясность кода и ускоряет разработку, то этот пост может вас не убедить. Но если вам интересно, как относительно незнакомая команда инженеров превратила существующую кодовую базу (и саму себя) из ничего в славу TypeScript, это для вас!

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

До планирования

Прежде чем приступить к потенциальным изменениям, важно понять преимущества и недостатки, чтобы вы могли оправдать переход для себя и своих коллег. Будет ли это изменение ценным для команды? Почему из всех альтернатив? Стоят ли его преимущества риска и времени?

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

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

Чемпионы

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

Региональные эксперты

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

Я выступал для нас в качестве отраслевого эксперта, потому что я уже был хорошо знаком с TypeScript - я вносил свой вклад в сам язык; Я помогал поддерживать частично устаревший TSLint; а потом я выступал на TSConf 2019. Вероятно, это больше, чем вам действительно нужно. Скорее всего, будет достаточно любого, у кого есть опыт использования TypeScript и хорошее понимание интеграции системы сборки TypeScript, использования компилятора и особенностей проверки типов.

Чирлидеры

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

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

RFC: переход на TypeScript

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

Прежде чем мы решили сделать рывок, я (эксперт в данной области) создал первоначальный «RFC» (запрос комментариев), в котором кратко описал, что такое новая технология, почему мы хотим ее и как мы будем переходить на нее. У нас уже была устоявшаяся практика отправки RFC перед внесением серьезных изменений, чтобы каждый имел возможность внести свой вклад - или, по крайней мере, не удивляться объединению запросов на вытягивание.

В нашем конкретном RFC предлагается следующее:

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

Первоначальный RFC сильно отличался от плана атаки, который мы выбрали для нашей основной кодовой базы. Он содержал оптимистические оценки времени преобразования, использование --checkJs для проверки типов файлов JavaScript, рекомендацию отдавать предпочтение // @ts-ignore, а не истинному исправлению сложных ошибок. И другой набор начальных флагов компилятора.

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

Тем не менее, преобразование гаммы было успешным и было положительно воспринято несколькими инженерами, которые работали над ним. Мы получили особенно высокие оценки за стандартизацию объявлений типов для компонентов, используемых в наших проектах. Даже инженеры, работающие с простыми файлами JavaScript, получили пользу от VS Code’s JavaScript IntelliSense. Все на борт TypeScript!

Обмен знаниями

Мы запустили нашу внутреннюю пропагандистскую машину TypeScript с двух обеденных презентаций:

  1. Статический анализ в JavaScript: общее введение в инструменты, которые анализируют код без его запуска, в основном сосредоточены на Prettier и ESLint.
  2. ✨TypeScript! ✨: полное введение в TypeScript, начиная с основ системы типов и заканчивая размеченными союзами.

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

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

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

План игры: ранние этапы

Медленное обучение команды новому языку может быть очень полезным. Если вы не хотите проводить несколько рабочих дней с практически нулевой продуктивностью (у кого есть время !?), вероятно, что большая часть команды не начнет работать с новой технологией, должным образом подготовленной с его лучшие практики и распространенные ошибки.

Мы начали процесс с нескольких поведенческих маркеров высокого уровня:

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

Ранние последователи

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

Большая часть первых трудностей у последователей была связана с type объявлениями, особенно в отношении сторонних библиотек и способов их использования для объявления типов свойств компонентов React. С типами реакции возникла большая проблема: после того, как шаблон использования был задан и впоследствии разъяснен в нашей внутренней документации, практически никто снова не задавал тот же вопрос.

Неправильно написанные сторонние типы были более болезненными. Лучшая методика смягчения последствий, которую мы придумали, заключалась в том, чтобы делать все .d.ts объявления в свое свободное время и отправлять запросы на вытягивание затронутым членам команды для наглядности. В некоторых случаях мы вообще не добавляли пакет @types/ и жили с неявными anys.

Противники

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

Эти члены команды также были ценными для получения обратной связи. Почему они не так обрадовались этому сдвигу, как мы? Было ли это пассивным сопротивлением? … Активное несогласие? …оба? …ни один? Понимание причин отсутствия у других энтузиазма помогает информировать как о восприятии, так и о технологических усилиях, которые мы приложили.

  • Для членов команды, обеспокоенных тем, что это замедляет время разработки, мы показали, как улучшенные рефакторинги и навигация VS Code ускорили разработку.
  • Для членов команды, которые не считали статическую типизацию полезной для поиска ошибок, мы публиковали каждую обнаруженную производственную ошибку или неиспользуемый фрагмент кода.
  • Для членов команды, нервничающих по поводу когнитивных накладных расходов, связанных с использованием другого языка, мы проповедовали принципы кодирования, которые поддерживали минимальные функции только для TypeScript, и продемонстрировали, как наши компоненты React были проще для понимания и более точными с типами TypeScript вместо prop-типов.

План игры: поздние стадии

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

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

Распространение знаний

Разделение оставшейся работы при преобразовании отлично для распространения знаний среди членов команды. Нам нужно было, чтобы каждый, кто работал с нашим веб-кодом, понимал TypeScript и его использование, и единственный надежный способ заставить кого-то понять - это заставить его использовать его. Можно сказать, что мы конвертировали себя в TypeScript. Прогресс можно было визуализировать по проценту членов команды, которые создали или преобразовали несколько файлов TypeScript. К тому времени, когда мы достигли 100% охвата файлов, мы уже давно достигли 100% охвата команды.

Наверх Далее: Часть вторая: технические изменения