Ra'Reilly - Заметки про Android и не только

На выходных посмотрел доклад про Declarative Gradle и демку Amper от JetBrains с KotlinConf'24. Вообще, когда только услышал про эти два инструмента, было много вопросов, главные из которых: "Мы только Gradle готовить научились, зачем что-то менять?", "Уже пора переезжать? Если нет, то как подготовиться?" и, конечно, "Какое решение выбрать?". После прочтения доки и просмотра докладов, я нашёл для себя ответы на эти вопросы.

Зачем что-то менять?

Оба проекта направлены на разделение конфигурации сборки (декларативная часть) и логики сборки (императивная часть). Конфигурация остаётся в модулях, а декларативная часть переезжает в плагины. Аргументы такие:

• Для декларативных конфигов проще писать тулинг. Помните случаи когда IDE предлагает добавить или обновить какую-то зависимость? Правда нажимать на эту кнопку не хочется, потому что этот автоматический рефакторинг не знает ничего про специфику проекта и в лучшем случае обновит версию не там, а в худшем сломает сборку. Поддержать в тулинге все возможные варианты объявления зависимостей — нетривиальная задача, которая решается очень просто для декларативных конфигов.

• Ещё один аспект интеграции с тулингом — декларативные конфиги можно парсить "на лету", без компиляции. Открываются возможности для оптимизации. Команда Gradle показала, запуск ./gradlew assemble на проекте с 500 модулями и вариант с декларативной конфигурацией занял 11 секунд против 72 секунд с Kotlin DSL. Скорее всего это какой-то супер простой не-Android проект и, к тому же, они сами говорят, что когда фичей в декларативном варианте будет больше, будет уже не так быстро, но всё равно впечатляет. Стоит воспринимать этот результат как экономию именно на этапе конфигурации.

• Человеку тоже проще читать и понимать декларативные конфиги. Возможно это субъективно, но сложнее понимать что происходит в билд скриптах если логика перемешана с конфигами, так же сложно воспринимается код на Compose где логика не вынесена во ViewModel.

• С декларативным конфигом сложнее "выстрелить себе в ногу", сложнее сделать сборку неэффективной. Просто потому что набор инструментов для этого ограничен. Конечно, такая возможность всё ещё остаётся в декларативной части. Все эти знания про "configuration cache", "configuration avoidance" и т.д. просто не будут нужны для грамотной настройки проекта, но всё ещё пригодятся если хочется написать свой плагин.

Что нам делать сейчас?

Оба проекта в экспериментальном статусе, а значит ещё будут значительные изменения, поэтому в прод тащить пока рано. Но уже можно экспериментировать на небольших проектах или попробовать смигрировать один простой модуль на новый вариант конфигурации (даже не обязательно эту ветку потом вливать). Благо оба инструмента можно использовать поверх сконфигурированного Gradle-проекта. Конечно, в результате экспериментов хорошо бы собрать список пожеланий и отправить их командам.

Если на эксперименты нет времени, можно упростить себе жизнь сейчас и миграцию на декларативный подход в будущем, если приблизить конфигурацию сборки к декларативной. Для этого нужно перенести всю логику в precompiled script plugins или обычные плагины, а в скриптах сборки оставить только настройку этих плагинов.

Какое решение выбрать?

Ответ на этот вопрос будет понятен позднее, но уже видны некоторые отличия. Amper строится с Kotlin Multiplatform в уме, а Declarative Gradle всегда будет лучше интегрирован с Gradle. У Amper больше свободы в решениях, так как он не зависит от Gradle. Как пример, изменение структуры проекта с src/main/kotlin/ на src/. Standalone вариант Amper может дать ещё больше свободы и более тесную интеграцию с IDE.

В общем, следим как будут развиваться эти инструменты. Похоже, что в будущем конфиги сборки будут всё-таки декларативными. Интересно как будет соблюдаться баланс между ограничениями декларативной конфигурации и свободой, которую даёт Gradle.

По теме:
- Репозиторий Amper
- Репозиторий Declarative Gradle
- Why Declarative Gradle is a cool thing I am afraid of: Maven strikes back - краткая история систем сборки и другая точка зрения

#gradle #amper

www.group-telegram.com/ua/rareilly.com/168

1.9K viewsOsip Fatkullin, edited  Jun 17, 2024 at 12:01

На выходных посмотрел доклад про Declarative Gradle и демку Amper от JetBrains с KotlinConf'24. Вообще, когда только услышал про эти два инструмента, было много вопросов, главные из которых: "Мы только Gradle готовить научились, зачем что-то менять?", "Уже пора переезжать? Если нет, то как подготовиться?" и, конечно, "Какое решение выбрать?". После прочтения доки и просмотра докладов, я нашёл для себя ответы на эти вопросы.

Зачем что-то менять?

Оба проекта направлены на разделение конфигурации сборки (декларативная часть) и логики сборки (императивная часть). Конфигурация остаётся в модулях, а декларативная часть переезжает в плагины. Аргументы такие:

• Для декларативных конфигов проще писать тулинг. Помните случаи когда IDE предлагает добавить или обновить какую-то зависимость? Правда нажимать на эту кнопку не хочется, потому что этот автоматический рефакторинг не знает ничего про специфику проекта и в лучшем случае обновит версию не там, а в худшем сломает сборку. Поддержать в тулинге все возможные варианты объявления зависимостей — нетривиальная задача, которая решается очень просто для декларативных конфигов.

• Ещё один аспект интеграции с тулингом — декларативные конфиги можно парсить "на лету", без компиляции. Открываются возможности для оптимизации. Команда Gradle показала, запуск ./gradlew assemble на проекте с 500 модулями и вариант с декларативной конфигурацией занял 11 секунд против 72 секунд с Kotlin DSL. Скорее всего это какой-то супер простой не-Android проект и, к тому же, они сами говорят, что когда фичей в декларативном варианте будет больше, будет уже не так быстро, но всё равно впечатляет. Стоит воспринимать этот результат как экономию именно на этапе конфигурации.

• Человеку тоже проще читать и понимать декларативные конфиги. Возможно это субъективно, но сложнее понимать что происходит в билд скриптах если логика перемешана с конфигами, так же сложно воспринимается код на Compose где логика не вынесена во ViewModel.

• С декларативным конфигом сложнее "выстрелить себе в ногу", сложнее сделать сборку неэффективной. Просто потому что набор инструментов для этого ограничен. Конечно, такая возможность всё ещё остаётся в декларативной части. Все эти знания про "configuration cache", "configuration avoidance" и т.д. просто не будут нужны для грамотной настройки проекта, но всё ещё пригодятся если хочется написать свой плагин.

Что нам делать сейчас?

Оба проекта в экспериментальном статусе, а значит ещё будут значительные изменения, поэтому в прод тащить пока рано. Но уже можно экспериментировать на небольших проектах или попробовать смигрировать один простой модуль на новый вариант конфигурации (даже не обязательно эту ветку потом вливать). Благо оба инструмента можно использовать поверх сконфигурированного Gradle-проекта. Конечно, в результате экспериментов хорошо бы собрать список пожеланий и отправить их командам.

Если на эксперименты нет времени, можно упростить себе жизнь сейчас и миграцию на декларативный подход в будущем, если приблизить конфигурацию сборки к декларативной. Для этого нужно перенести всю логику в precompiled script plugins или обычные плагины, а в скриптах сборки оставить только настройку этих плагинов.

Какое решение выбрать?

Ответ на этот вопрос будет понятен позднее, но уже видны некоторые отличия. Amper строится с Kotlin Multiplatform в уме, а Declarative Gradle всегда будет лучше интегрирован с Gradle. У Amper больше свободы в решениях, так как он не зависит от Gradle. Как пример, изменение структуры проекта с src/main/kotlin/ на src/. Standalone вариант Amper может дать ещё больше свободы и более тесную интеграцию с IDE.

В общем, следим как будут развиваться эти инструменты. Похоже, что в будущем конфиги сборки будут всё-таки декларативными. Интересно как будет соблюдаться баланс между ограничениями декларативной конфигурации и свободой, которую даёт Gradle.

По теме:
- Репозиторий Amper
- Репозиторий Declarative Gradle
- Why Declarative Gradle is a cool thing I am afraid of: Maven strikes back - краткая история систем сборки и другая точка зрения

#gradle #amper

BY Ra'Reilly - Заметки про Android и не только