Как безболезненно конвертировать проект с Java на Kotlin и зачем это нужно
9 июня 2023 г.В одном проекте мы получили приложение, половина исходного кода которого была на Java, а другая половина на Kotlin. На самом деле я задал вопрос: "Почему так?" Вывод был прост.
Разработчики не смогли справиться с проблемами, которые принес этот переход. Перед нами стояла задача навести порядок и разобраться с этой проблемой.
Прежде всего, нам нужно начать с того, почему я считаю, что этот переход может быть необходим.
Обман
Это, конечно, шутка с долей правды. Однако таким образом можно переманить огромное количество разработчиков. Kotlin позволяет взглянуть на рутинное приложение Spring Rest под новым углом, привнося функциональный стиль программирования. А также предоставление таких функций, как:
* Необработанные типы — избавление от ClassCastException, когда в кучу попадает переменная, хранящая объект, параметризованный другим типом.
* Безопасность Nullable — стиль программирования Kotlin позволяет защитить себя от NullPointerException, просто не разрешая их использование (на самом деле это так, но проблема связана с этим далее).
* Функция высокого порядка — это то, о чем я писал выше — переход к функциональному стилю программирования, когда функция принимает в качестве параметра другие функции.
* Классы данных, которые избавят вас от использования Lombok.
* и т.д.
А теперь к проблемам
Забудьте об автоматическом преобразовании IDEA с Java на Kotlin. Первое, что вы обнаружите, это совершенно криво написанный код в стиле Java, который конвертируется. Например, вы можете взять PNG и преобразовать его в JPEG.
Да, результат будет тот же, за исключением того, что исходные свойства (прозрачность) будут потеряны. Здесь то же самое. Вы получите рабочий код, однако я не думаю, что вы будете в восторге от его поддержки. Привыкайте к мысли, что ВЫ ДОЛЖНЫ ЭТО ПЕРЕПИСАТЬ.
Включите Lint и прочитайте несколько книг о подходах и стилях. Досмотри до конца. Единственное место, где я могу порекомендовать вам использовать этот метод, — это классы данных. Также весь новый функционал нужно писать исключительно на Котлине, чтобы не повторилась история с проблемами.
Не злоупотребляйте обнуляемой безопасностью
Будет дикое желание начать использовать эту очень полезную вещь, однако, если вы будете иметь в виду своих пользователей API, они точно не будут в восторге от того, что вы портите им взаимодействие с вами.
Итак, версионирование API + размышления «Действительно ли мне нужна эта самая безопасность Nullable в моей будущей логике?» тут бы пригодился.
Вы всегда можете защитить себя на уровне контроллера с помощью необходимых Spring и Lombok. Вы обязательно столкнетесь с тем, что по умолчанию классы Kotlin закрыты для наследования, поэтому, если вы не «откроете» классы с аннотациями, такими как @Configuration и @Service, это приведет к ошибкам запуска.
И Lombok преподнесет вам несколько сюрпризов, потому что аннотации нарушают логику преобразования классов в Kotlin
Какой вывод?
Прекратите использовать технологический зоопарк. Часто ни к чему хорошему это не приводит. Если осмелишься - доведи до конца, чтобы у тебя и твоей работы не осталось неприятных впечатлений
Оригинал