Как безболезненно конвертировать проект с Java на Kotlin и зачем это нужно
programming kotlin javascript

Как безболезненно конвертировать проект с 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

Какой вывод?

Прекратите использовать технологический зоопарк. Часто ни к чему хорошему это не приводит. Если осмелишься - доведи до конца, чтобы у тебя и твоей работы не осталось неприятных впечатлений

Оригинал

Recent Post

Categories

PREVIOUS ARTICLE
NEXT ARTICLE