В процессе перехода двух зрелых кодовых баз внешнего интерфейса (всего ~ 5 тыс. Файлов / 300 тыс. Строк) с Javascript на Typescript я немного узнал о процессе, который может быть полезен любому, кто рассматривает это изменение в своем стеке. Многие из этих советов на самом деле не относятся к Typescript и, возможно, могут быть обобщены для любого языка или миграции фреймворка, но я буду придерживаться того, что знаю.
1. Пишите весь новый код на Typescript - иногда
Не создавайте дополнительной работы для своей команды в будущем, подталкивая больше кода для переноса позже - как только Typescript будет добавлен в ваш стек, каждый будущий запрос на перенос должен быть написан на TS. Но насколько это должно быть строго? Записать новые файлы и компоненты в TS достаточно просто, но как насчет изменений в существующих файлах? Если запрос на вытягивание изменяет только одну строку в файле, следует ли преобразовывать весь файл?
Требование от разработчиков перенести каждый измененный файл может быть убийцей морального духа и производительности. Даже самые мелкие исправления ошибок превращаются в рутинную работу, а PR для новых функций невозможно просмотреть, так как diff часто интерпретирует перенесенные файлы как новые. С другой стороны, если миграция не требуется, работа может никогда не быть завершена. Это особенно актуально для старых файлов, которые редко редактируются. Найдите баланс, который имеет смысл для вашей команды и способствует продвижению миграции.
2. Сначала конвертируйте общие файлы и общие компоненты
Вы получите самые непосредственные выгоды от возможностей Typescript, выбрав файлы, которые с наибольшей вероятностью будут импортированы при работе с любой новой функцией. Если эти общие компоненты не преобразованы, вы накапливаете технический долг во всех своих новых файлах TS. Опередите это и наслаждайтесь автозаполнением и мгновенными ошибками во всех ваших новых файлах.
Используйте наиболее точный тип, доступный для всех свойств API для этих основных компонентов. Может быть сложно найти точный тип для функций, обратных вызовов и событий (особенно для событий React, свойств DOM или сторонних зависимостей), но это избавит вас от проблем ниже по течению у ваших потребителей. Медленное исправление основных компонентов сэкономит ваше время в целом.
3. Сообщите своей команде о предстоящих миграциях
Иногда миграции могут создавать огромные различия, которые приводят к кошмарным конфликтам слияния, если несколько разработчиков работают с одним файлом. Не настраивайте себя на бессмысленные часы разочарований и ошибок в разрешении конфликтов. Свяжитесь со своей командой, прежде чем начинать миграцию. Если в этой области кода наблюдается значительная активность, подумайте о том, чтобы отложить работу или основать свою ветку на их ветке.
4. Не поддавайтесь желанию провести рефакторинг
При переносе любой большой базы кода вы неизбежно обнаружите, что открываете старые файлы с ужасными долгами. Грубо, посмотрите на все эти устаревшие шаблоны и неэффективность. О, вы могли бы полностью написать это в трети строк. Никто больше не пользуется этой функцией, верно? Снайперский.
Это высокомерие. Не делай этого. Вы собираетесь создать регрессию. Будьте добры к себе и своей команде. Не переусердствуйте с QA.
5. Избегайте поддержки параллельных версий одного и того же компонента
Иногда перенос сложного или часто используемого компонента слишком чреват для риска преобразования на месте - в таких ситуациях единственным выходом может быть дублирование, преобразование и постепенная замена старого на новое во всей кодовой базе. Но пока существуют обе версии, будет неразбериха, какую из них использовать; старый будет импортирован по привычке или копипасту; исправления ошибок и улучшения должны быть применены к обоим; поведение может даже измениться со временем.
Сведите к минимуму время, затрачиваемое в этой ситуации - при добавлении дублирующего компонента TS установите приоритет этой области миграции. Четко называйте файлы и компоненты, чтобы избежать путаницы при импорте.
6. Учет миграции при оценках и планировании
Предоставляя временные или точечные оценки для будущей работы, добавьте еще 20%, если вы планируете сначала перенести код. Спланируйте свои миграции; если вы знаете, что в какой-то области предстоит большая работа, сделайте миграцию как можно раньше. Не оставляйте это невидимой или неожиданной ценой.
7. Оставляйте комментарии всякий раз, когда используете ts-ignore или any
Некоторые из ваших сторонних зависимостей будут давать вам неправильные определения типов, из-за которых вы будете чесать голову в течение нескольких дней. Непонятный угловой случай с общими кортежами отправит вас в червоточину Stack Overflow на 5 часов. Наибольшее благо - продолжать двигаться вперед и оставлять хорошие комментарии всякий раз, когда вас заставляют взломать.
8. Не позволяйте этому задерживаться
Один из возможных путей миграции для Typescript - постепенное повышение его строгости; отключение этих правил может быть полезно при начале работы, но если отложить это на долгое время, ваша команда не сможет воспользоваться всеми преимуществами языка. На начальном этапе это может быть дорого, так как вы переносите необходимые зависимости, так что даже один компонент может быть полностью типизирован, но это лучше, чем столкнуться с огромным различием на горизонте, как только вы его включите.
В скорости изменений будут периоды бума и спада, но справляться с техническим долгом в середине миграции утомительно. Вы никогда не сможете вспомнить, какой компонент уже был преобразован или нет. Вы по-прежнему не можете доверять IDE в обнаружении самых серьезных ошибок в вашем коде. Почему мы вообще начали этот глупый переход?
Но достоинства строго типизированного языка растут по экспоненте по мере преобразования большей части кодовой базы. В первый раз, когда вы реорганизуете базовый компонент, и компилятор немедленно сообщает вам до строки и столбца, где требуются исправления, все это того стоит. Конечно, в большинстве других языков подобный опыт существует уже несколько десятилетий, но не в Javascript.
Удачи! Это большая работа, но со временем она окупится.
