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 предлагается следующее:
- Специалист в этой области дал бы коричневую сумку по TypeScript, чтобы повысить осведомленность команды.
- Мы бы попробовали преобразовать нашу Систему дизайна гаммы в TypeScript в качестве начального теста.
- Если все пойдет хорошо, мы добавим поддержку TypeScript в нашу систему сборки в нашей основной кодовой базе, а затем разделим преобразования файлов.
Первоначальный RFC сильно отличался от плана атаки, который мы выбрали для нашей основной кодовой базы. Он содержал оптимистические оценки времени преобразования, использование --checkJs
для проверки типов файлов JavaScript, рекомендацию отдавать предпочтение // @ts-ignore
, а не истинному исправлению сложных ошибок. И другой набор начальных флагов компилятора.
Оглядываясь назад, можно сказать, что оценка 12 часов на преобразование 2000 файлов в TypeScript не была особенно продуманным решением. Фактическое время было, вероятно, в три или четыре раза больше первоначального прогноза. Подобное изменение, вероятно, займет у вас больше времени, чем вы ожидали, и отклонится от ваших первоначальных планов, поэтому обязательно учтите это!
Тем не менее, преобразование гаммы было успешным и было положительно воспринято несколькими инженерами, которые работали над ним. Мы получили особенно высокие оценки за стандартизацию объявлений типов для компонентов, используемых в наших проектах. Даже инженеры, работающие с простыми файлами JavaScript, получили пользу от VS Code’s JavaScript IntelliSense. Все на борт TypeScript!
Обмен знаниями
Мы запустили нашу внутреннюю пропагандистскую машину TypeScript с двух обеденных презентаций:
- Статический анализ в JavaScript: общее введение в инструменты, которые анализируют код без его запуска, в основном сосредоточены на Prettier и ESLint.
- ✨TypeScript! ✨: полное введение в TypeScript, начиная с основ системы типов и заканчивая размеченными союзами.
Мой любимый слайд из этих презентаций был в самом начале, где мы указали на «Воронку обнаружения ошибок» как на идею того, как ошибки устраняются в процессе разработки. Предотвращение ошибок и повышение стабильности веб-сайта было одной из амбиций большой команды в начале 2019 года, и мы грамотно включили TypeScript в эти планы.
Извлеченный урок: если ваша команда осознает, что нужно улучшить, маневрируйте своими целями, чтобы казалось, что они совпадают с ними. Вы будете поражены, насколько восприимчивым будет руководство! 😉
Мы также представили регулярную серию тем TypeScript в нашей еженедельной серии Lightning Talks, в которой члены команды проводят 5-минутные мини-презентации на любые темы, которые им нравятся. В этих презентациях были затронуты более эзотерические темы, такие как обобщения и условные типы с отображением.
План игры: ранние этапы
Медленное обучение команды новому языку может быть очень полезным. Если вы не хотите проводить несколько рабочих дней с практически нулевой продуктивностью (у кого есть время !?), вероятно, что большая часть команды не начнет работать с новой технологией, должным образом подготовленной с его лучшие практики и распространенные ошибки.
Мы начали процесс с нескольких поведенческих маркеров высокого уровня:
- Разработчикам предлагалось писать новые файлы на TypeScript, когда им это было удобно.
- Эксперты команды и чирлидеры посвятят время преобразованию существующих файлов в TypeScript.
- Ресурсы TypeScript в виде документации, внутренних презентаций и внешних ресурсов были выделены как рекомендуемая посещаемость и чтение.
Ранние последователи
Некоторые участники команды с энтузиазмом взялись за дело и активно попробовали. Обнаружение пул-реквестов, поступающих с добровольными добавлениями и преобразованиями TypeScript, было замечательным моментом для подтверждения личности лидера проекта. Видеть проблемы, с которыми сталкиваются эти первые последователи, почти все из которых раньше серьезно не использовали TypeScript, также было весьма полезно. Мы использовали их усилия для информирования о документации и ресурсах, которые мы разослали команде, а также для некоторых переговоров по освещению.
Большая часть первых трудностей у последователей была связана с type
объявлениями, особенно в отношении сторонних библиотек и способов их использования для объявления типов свойств компонентов React. С типами реакции возникла большая проблема: после того, как шаблон использования был задан и впоследствии разъяснен в нашей внутренней документации, практически никто снова не задавал тот же вопрос.
Неправильно написанные сторонние типы были более болезненными. Лучшая методика смягчения последствий, которую мы придумали, заключалась в том, чтобы делать все .d.ts
объявления в свое свободное время и отправлять запросы на вытягивание затронутым членам команды для наглядности. В некоторых случаях мы вообще не добавляли пакет @types/
и жили с неявными any
s.
Противники
Некоторые члены команды предпочли не участвовать в преобразовании с самого начала. Совершенно разумно! Участвовать на ранних этапах внедрения технологий без предварительного опыта - сложная задача, и у всех разные мотивы и цели.
Эти члены команды также были ценными для получения обратной связи. Почему они не так обрадовались этому сдвигу, как мы? Было ли это пассивным сопротивлением? … Активное несогласие? …оба? …ни один? Понимание причин отсутствия у других энтузиазма помогает информировать как о восприятии, так и о технологических усилиях, которые мы приложили.
- Для членов команды, обеспокоенных тем, что это замедляет время разработки, мы показали, как улучшенные рефакторинги и навигация VS Code ускорили разработку.
- Для членов команды, которые не считали статическую типизацию полезной для поиска ошибок, мы публиковали каждую обнаруженную производственную ошибку или неиспользуемый фрагмент кода.
- Для членов команды, нервничающих по поводу когнитивных накладных расходов, связанных с использованием другого языка, мы проповедовали принципы кодирования, которые поддерживали минимальные функции только для TypeScript, и продемонстрировали, как наши компоненты React были проще для понимания и более точными с типами TypeScript вместо prop-типов.
План игры: поздние стадии
Когда мы достигли конверсии более 50%, мы перешли к предположению, что у большинства членов команды есть хотя бы средний опыт для перехода. Это привело нас к измененному набору поведенческих маркеров:
- Разработчикам предлагалось писать новые файлы на TypeScript, когда им это было удобно.
- Эксперты команды и чирлидеры будут посвящать время преобразованию существующих файлов в TypeScript. Оставшаяся работа по преобразованию кодовой базы была разделена на отдельные элементы и поручена различным членам команды.
- Ресурсы TypeScript в виде документации, внутренних презентаций и внешних сайтов были выделены как предполагаемая посещаемость и чтение, которые должны быть поняты
Распространение знаний
Разделение оставшейся работы при преобразовании отлично для распространения знаний среди членов команды. Нам нужно было, чтобы каждый, кто работал с нашим веб-кодом, понимал TypeScript и его использование, и единственный надежный способ заставить кого-то понять - это заставить его использовать его. Можно сказать, что мы конвертировали себя в TypeScript. Прогресс можно было визуализировать по проценту членов команды, которые создали или преобразовали несколько файлов TypeScript. К тому времени, когда мы достигли 100% охвата файлов, мы уже давно достигли 100% охвата команды.
Наверх Далее: Часть вторая: технические изменения