10 минут
Кейс перехода с Java на Kotlin: причины, особенности, процесс
Перевод проекта с Java на Kotlin — это стратегическое решение для повышения эффективности разработки. Однако такую миграцию часто сопровождает вопрос: оправданны ли масштаб и сложность предстоящей работы?
Всем привет! Я Влад, backend-разработчик компании SimbirSoft. Сегодня расскажу, как в одном из кейсов мы перешли из Java в Kotlin. Рассмотрим плюсы и минусы такого перехода, что понравилось, а что можно было бы сделать лучше, и ответим на главный вопрос — стоит ли мигрировать сервис с Java на Kotlin?
Оптимизация проекта
Мы работали над корпоративным SaaS-продуктом для автоматизации работы крупной логистической компании, который был написан на языке Java. Система была основана на микросервисной архитектуре и включала в себя модули:
-
планирования и отслеживания графика перевозок;
-
хранения и обработки документов;
-
интеграции с платёжными системами;
-
аналитики и генерации отчётов;
-
синхронизации с внешними API партнёров.
В системе было около 20 модулей, каждый из которых в виде отдельного микросервиса. Поддержка и доработка функциональности такой системы требовали все больше затрат со стороны команды.
Анализ затрат и результатов проекта показал, что нужен более эффективный подход к управлению проектом. Для этого провели ряд действий и поняли, как можно сократить затраты без потери качества разработки. Одним из таких действий стало архитектурное ревью.
Решение — переезд на Kotlin
После архитектурного ревью технический лид решил, что надо переписать два сервиса на язык программирования Kotlin. Почему только два, а не все 20? Именно в этих сервисах активно использовались новые бизнес-фичи и сложная логика обработки данных. Это делало код на Java избыточным и менее удобным для сопровождения.
Переход с Java на Kotlin обоснован рядом факторов:
-
безопасная работа с null;
-
удобная работа с коллекциями (map, filter, etc.);
-
лёгкая интеграция с Java-библиотеками;
-
более декларативный код.
Другими словами, меньше кода — меньше ошибок. Kotlin предлагал более лаконичный синтаксис и лучшую интеграцию с современными библиотеками, поэтому приняли решение о постепенном внедрении Kotlin без единовременного перехода.
При переписывании сервиса появилось возможность добавить новую функциональность:
-
в модуль расчёта маршрутов и стоимости доставк — автоматически подбирать оптимальный путь с учётом расстояния, времени и тарифов перевозки;
-
в модуль управления складскими запасами — обеспечивать учет, резервирование и автоматическое оповещение об остатках товаров.
Нам легко удалось внедрить новую логику в проект, не ломая CI/CD (непрерывной интеграции и доставки, Continuous Integration/Continuous Delivery), так как Kotlin полностью совместим с Java-кодом и интегрируется с Spring (фреймворк для языка программирования Java).
При этом, мы понимали, что у перехода с Java на Kotlin есть особенности процесса, которые обязательно стоит учитывать.
|
Нюансы перехода с Java на Kotlin |
Подробности |
|
Низкая скорость компиляции в больших (растущих) проектах |
Код на Java скомпилируется быстрее, чем аналогичный код на Kotlin. Каждая команда для себя должна решить, критична ли такая скорость. |
|
Совместимость с плагинами для разработки |
Часто приходится подбирать совместимые версии плагинов, чтобы избежать ошибок во время выполнения (runtime) в процессе разработки. |
|
Стиль разработки |
При постепенной интеграции Kotlin в Java-проект очень важно не упустить стиль проекта (хотя тут все зависит от команды разработчиков). |
|
Поддержка с другими инструментами |
Не все библиотеки и инструменты хорошо поддерживают Kotlin в продакшене. |
Процесс плавного перехода на Kotlin
Мы начали переход на Kotlin с тестов, и это оказалось верным решением. До перехода зафиксировали code-style, чтобы проект оставался понятным и поддерживаемым. Не все члены команды писали код на Kotlin, и интеграция, начатая с тестов, минимизировала риски потери или нарушения бизнес-логики проекта.
Также, уже на этапе тестов можно было настроить сборку проекта и подключить необходимые плагины, такие как:
-
all-open, чтобы адаптировать Kotlin под требования фреймворков (Spring, JPA и др.), автоматически делая классы с указанными аннотациями и их методы открытыми, без необходимости писать open вручную;
-
kapt, чтобы обеспечивать поддержку Java-аннотационных процессоров в Kotlin, позволяя использовать библиотеки вроде MapStruct, Dagger или QueryDSL. На данный момент, Kapt перестало получать обновления, разработчики Kotlin предлагают перейти на альтернативу в виде Kotlin Symbol Processor API(KSP);
-
no-args, чтобы генерировать дополнительный конструктор без аргументов (NoArgsConstructor) для классов с указанными аннотациями.
Это требовалось, чтобы обеспечить совместимость с используемыми фреймворками и упростить дальнейшую интеграцию языка в проект. Также мы увеличили количество ревьюеров, что позволило разработчикам быстрее «вкатиться в язык» и гарантировать безопасность рефакторинга сервиса.
Ниже на рисунке можно увидеть примерные этапы перехода:
В результате такого перехода удалось достичь следующих показателей:
-
количество кода в сервисе сократилось на 25–30%;
-
снизилось количество ошибок за счёт null-safety (механизм языка, предотвращающего использование неопределённых или «пустых» значений);
-
миграция шла постепенно, без полной остановки разработки.
Заключение
Постепенный переход с Java на Kotlin в нашем проекте показал, что эта стратегия может быть безопасной и эффективной при правильной организации процесса. Например, использование тестов в начале разработки позволило снизить риски и дать команде время привыкнуть к новому языку. Добавление кросс-код-ревью для разработчиков без опыта работы с Kotlin, а также мультиплатформенность языка, позволила, не изменяя CI/CD, продолжить разработку.
Совместимость Kotlin с Java и Spring также сыграла большую роль.
-
Через встроенные инструменты IntelliJ IDEA можно легко переписать код с Java на Kotlin.
-
Возможность наследования Java-классов позволило не тратить время на рефакторинг кода, в котором на тот момент не было острой необходимости.
Все же, каждый случай уникальный и только от команды зависит, стоит ли идти на такой шаг.
В нашем случае риски оправдались, так как главным условием для перехода оказалось именно добавление новой функциональности. В иных случаях, когда требуется лишь поддержка уже существующего проекта, такой переход может казаться излишним. Хотите оптимизировать разработку и поддержку проекта? Оставьте свою заявку по телефону 8-800-200-99-24 или отправьте письмо на request@simbirsoft.com