Крутой выпуск! Кажется, я узнал из него больше, чем из DPE Summit. Куча полезной инфы для большого не-Android сетапа (большая группа микросервисов в монорепе), достаточно много общего.
Вопрос: верно ли утверждать, что Declarative Gradle не так уж и не нужен, если написать линтер build. gradle файлов, который отсекает всё кроме блока plugins (только разрешенные, конечно), dependencies и некоторого количества разрешенных extension'ов. Linter реализуем на базе анализа Groovy AST (что-то вроде netflix nebula linter). А дальше - просто - если нужна какая-то кастомная логика в скрипте - пишем Gradle Plugin/Task на Kotlin/Java, код этот обязателен для ревью платформенной команде (через CODEOWNERS) в buildSrc или build-logic. В итоге если даже проект очень большой, хоть тысячи модулей, все это можно вполне держать под контролем и нет нужды ревьюить каждое изменение любого из .gradle файлов. Ну и синтаксис, в итоге, максимально знакомый всем, не нужно переучиваться. Или я что-то упускаю?
Declarative решает проблему не только запретов, но и простоты написания билдскриптов продуктовыми инженерами. Если им просто и они не пишут ненужные вещи, то Declarative вам не нужен
🔗 Платная подписка на Boosty abdev.by/oroS и в Telegram abdev.by/lrpW
🔗 Telegram Android Broadcast t.me/+mBXLNRgEwNcwNjli
✉ Написать Кириллу kirill@androidbroadcast.dev
Все ещё ждём курс по грэдл😊, неоновая вывеска для поколения 90х удачное решение))
Глыба ) Сержио, лично я тебе всегда рад в любых выпусках, спасибо, парни!
От души
Крутой выпуск! Кажется, я узнал из него больше, чем из DPE Summit. Куча полезной инфы для большого не-Android сетапа (большая группа микросервисов в монорепе), достаточно много общего.
Вижу Серёгу, ставлю лайк не глядя)
Из наблюдения. Чем выше (или серьёзнее) специалист, тем приятнее у него подача
Вопрос: верно ли утверждать, что Declarative Gradle не так уж и не нужен, если написать линтер build. gradle файлов, который отсекает всё кроме блока plugins (только разрешенные, конечно), dependencies и некоторого количества разрешенных extension'ов. Linter реализуем на базе анализа Groovy AST (что-то вроде netflix nebula linter). А дальше - просто - если нужна какая-то кастомная логика в скрипте - пишем Gradle Plugin/Task на Kotlin/Java, код этот обязателен для ревью платформенной команде (через CODEOWNERS) в buildSrc или build-logic. В итоге если даже проект очень большой, хоть тысячи модулей, все это можно вполне держать под контролем и нет нужды ревьюить каждое изменение любого из .gradle файлов. Ну и синтаксис, в итоге, максимально знакомый всем, не нужно переучиваться.
Или я что-то упускаю?
Declarative решает проблему не только запретов, но и простоты написания билдскриптов продуктовыми инженерами. Если им просто и они не пишут ненужные вещи, то Declarative вам не нужен
О! Сергей крутой! За него сразу лайк.
😔
Топ.
Ньюфаги не знают , олдфаги не помнят.
Пусть грэдл будет уже нет тот, главное что бы Серега всегда был тот😊
Это что-то личное