С ростом количества модулей, компонентов и функций становится сложно поддерживать согласованность в кодовой базе нашего внешнего интерфейса. Часто возникают непредвиденные ошибки, что снижает производительность наших инженеров в целом. Более того, с увеличением количества инженеров, вовлеченных в нашу клиентскую кодовую базу, становится постоянной задачей обеспечить их как можно более плавную адаптацию.
Один из принципов нашей технической стратегии — простота + скорость, и с этой целью мы не боимся вырывать старый код, фреймворк или шаблоны или внедрять новые. В этом сообщении блога мы пишем о том, как мы осуществляем одну из наших крупнейших миграций с Javascript на Typescript, и ее обоснование.
Почему мы мигрировали?
С Typescript мы стремимся достичь трех целей в нашей команде.
- Способствовать лучшей командной работе
- Увеличение скорости разработки
- Улучшить ремонтопригодность проекта
Исходя из кодовой базы Javascript, Typescript был выбран из-за его обратной совместимости, и его можно легко интегрировать в нашу кодовую базу.
Лучше облегчить командную работу
Раньше с Javascript нам было трудно заставить разработчиков использовать общие функции или библиотеки, и часто изменения в общих функциях или библиотеках вызывали непреднамеренные ошибки. Более того, между общими моделями в Javascript не было контракта, что добавляло сложностей и трудностей при реализации новых компонентов или функций. Typescript устраняет эти проблемы, предлагая более лаконичный и последовательный способ ввода текста в функцию или объект.
Взгляните на следующий фрагмент кода:
Без машинописного текста будет сложно сообщить, что ожидалось от определенных параметров или объектов. Это приведет к путанице и повлияет на производительность в целом. Typescript помогает инженерам более четко общаться и последовательно кодировать. В итоге продуктивность наших инженеров повысится при сохранении слаженной работы внутри команды.
Увеличение скорости разработки
Отладка и отслеживание ошибок всегда были проблемой при использовании Javascript. Ошибку сложно поймать, а иногда и саму проблему можно было бы предотвратить, если бы перед компиляцией кода был процесс проверки. Typescript обеспечивал проверку типов при компиляции для предотвращения тех мелких ошибок, которые обычно ускользали от внимания инженеров в процессе реализации.
Хотя есть еще другие ошибки, которые не могут быть обнаружены с помощью процесса проверки типов, в целом он экономит много времени и, кроме того, благодаря единым стандартам во всей кодовой базе, также повышает скорость разработки в целом. Инженерам не нужно гадать или бояться при использовании общих компонентов или библиотек. Это также побуждает инженеров создавать общие компоненты или библиотеки, которые уменьшают избыточность в кодовой базе.
Улучшить ремонтопригодность проекта
Поддержание унаследованной кодовой базы представляет собой особую проблему для инженеров. Даже малейшее изменение в коде потенциально может привести к поломке целых страниц или приложений. Мы должны убедиться, что даже самое маленькое изменение не нарушит функцию.
Раньше с Javascript было сложно изменять или модифицировать общие функции или библиотеки, поскольку нам нужно было проверять безопасность каждого вызывающего объекта. Часто ошибки обнаруживаются во время выполнения и сообщаются пользователями. Это ухудшает наш пользовательский опыт и потенциально может повлиять на бизнес-часть компании. Typescript немедленно отловит такие ошибки, что сделает процесс рефакторинга более безопасным в нашей кодовой базе.
Вариант использования:
Если мы изменим функцию в первом фрагменте кода на приведенный выше код, возникнет ошибка компиляции, и связанные функции также можно будет безопасно рефакторить.
Как мы мигрируем
Сама миграция была довольно простой, поскольку рекомендации были предоставлены в официальной документации typescript. Наша стратегия миграции кодовой базы началась с переноса более мелких частей нашей кодовой базы, таких как хуки, компоненты пользовательского интерфейса и утилиты. Кроме того, мы ввели строгие меры, потребовав, чтобы новая разработка новой функции была написана на машинописном языке. Мы также применяли такие стратегии, как рефакторинг старых файлов, который проводился постепенно, чтобы убедиться, что это не помешает нашему темпу разработки.
Заключение
Как видите, Typescript предлагает прямой способ общения, поскольку мы, как инженеры, точно знаем, чего ожидать, если вызовем конкретную функцию, и знаем, какой параметр следует передать функции. В нашем масштабе наличие таких функций много значит, инженеры могут больше сосредоточиться на процессе разработки, а не беспокоиться об ошибках. Это также помогает нам в процессе рефакторинга, поскольку мы можем легко определить, какое поведение мы хотим от нашей функции.
В конце концов, переход с Javascript на Typescript происходит исключительно из-за нашей потребности в более масштабируемом решении с нашей растущей кодовой базой и инженерами, что приводит к облегчению командной работы, увеличению скорости разработки и повышению удобства обслуживания нашего проекта.
На сегодняшний день мы перенесли около 90% кодовой базы нашего интерфейса на машинописный текст. Эта миграция — один из крупнейших рефакторингов в истории нашей кодовой базы, и он не будет последним. Мы рассматриваем долгосрочное здоровье нашей кодовой базы как коллективную ответственность нашей команды инженеров и разработчиков программного обеспечения в OY! имеют полномочия и поддержку для реализации таких проектов.
