Зачем нужна многомодульная архитектура. Плюсы и минусы
Вставка
- Опубліковано 17 лис 2024
- Разбираемся зачем в проектах нужна многомодульная архитектура и как она улучшить ваш проект. Также говорим о минусах такого подхода и для какой команды/проекта нужен такой подход
💰 Поддержать проект на Boosty bit.ly/3sratqQ или Patreon / android_broadcast
🔗 Telegram канал "Android Broadcast" ttttt.me/andro...
#AndroidBroadcast #Модуляризация #Архитектура #Gradle #КириллРозов #РозовКирилл #Android #AndroidDev
💰 Поддержать проект на Boosty bit.ly/3sratqQ или Patreon patreon.com/android_broadcast
🔗 Telegram канал "Android Broadcast" ttttt.me/android_broadcast
Тема интересная, рад был бы услышать более детальный разбор)
комментарий для продвижения канала
Жду видео про многомодульный проект! Спасибо!
Как всегда кратко и по делу! Спасибо за контент! После Дагера и Карутин - может быть сделаешь пару видео по этой теме?)
Планов уже получается столько, что ничего не буду обещать
Костя, вы ж Даггер не признавали или уже сменили гнев на милость?
@@mrgagarinn я и сейчас считаю, что подключать его в небольшие приложения - не очень правильное решение. Как и переписывать приложения в которых и так разведен DI - не очень оправданно. Есть случаи когда он действительно полезен...
Но речь тут шла о модульности, и т.к. я знаю что у Кирилла (автора канала) - курс по Дагеру и Корутинам уже в разработке, то понимал, что ждать видео раньше их окончания - немного бессмысленно.
Останусь пожалуй при своем мнении - многомодульность делать только тогда, когда без нее никак. В основном это для больших команд и больших проектов. Или если фича-тоглы нужны. В других кейсах минусы и гемор многомодульности перевешивают его плюсы.
По-моему я так и сказал в видео
@@AndroidBroadcast да, я ж не спорю о сказанном))) Спасибо за видео. Просто из этой многомодульности какой-то хайп сделали. Пилят на аутсорсе приложение полтора разработчика, эстимейт 3 месяца, зато многомодульность обязательно.
Расскажи про возможность писать gradle файлы на kotlin'е.
Что это даёт? Какие преимущества. Стоит ли переписывать существующие файлы с Groovy на kotlin если сейчас всё хорошо работает?
А что там рассказывать? Есть гайд по миграции. Если кратко, то вместо minSdk 21 вы пишите minSdk = 21 и вместо implementation "..." вы пишите implementation("..."). Если кроме добавления либ вы больше ничего не делаете, то вообще пофиг на чем писать. Если вам прямо сейчас понадобилось что-то активно дописывать, то все зависит от того на сколько хорошо вы знаете Groovy. Если хорошо, то переходить нет смысле. Если вообще не знаете, то писать на Kotlin будет проще по понятной причине. С переходом есть еще одно неудобство. На Groovy уже есть все, что только придет в голову. Можно просто нагуглить и вставить. С Kotlin так не получится.
Спасибо за видео, да будет очень интересно посмотреть как правильно варить эти прекрасные многомодульные проекты )
Это скорее будет не единственный правильный, а моё видение
Спасибо за видео)
Было бы классно увидеть видос с обзором какого-нибудь многомодульного проекта и как это всё дело варить
Спасибо!
Хочется узнать как сделать хороший многомодульный проект, расскажи
Было бы очень интересно услышать в таком же формате про App Bundle.
Да, очень хочу про него рассказать
Поддерживаю идею многомодульности за счет одного из подхода к построению архитектуры, если не прописаны в другом виде контракты, то, например в "Совершенный код" Макконнелла описана неплохая мысль про использования разных способов построения - это дает те вещи, о которых никогда не думал, при использовании других подходов или вообще их отсутствии. Хоть я ещё начинающий в андроид разработке, и оказывается тема многомодульности не особо распространена по форумам (на мой взгляд) и оказывает для многих дополнительную сложность. Я скажу, что мне было легче строить логику жизненных циклов в маленьком проекте, легче возвращаться через долгое время и дополнять функционал) Очень интересно узнать про скорость сборки, и в каких случаях повышается или понижается, например даггер в реализации фича лучше вынести в главный модуль и тд.
Тема актуальна была во все времена и не только для андроид разработки. Всегда стоит выбор: с одной стороны хочется соответствовать принципу yagni, а с другой SOLID с его принципом расширяемости.
Полностью согласен, что тут может помочь только опыт и хорошая команда. Универсального решения нет, всегда есть компромисс)
Архитектура - это не путь, а лишь набор советов как его можно пройти. Самурай (разработчик) должен выбрать сам как его пройти
Классно было увидеть уроки про многомодульность!!!!
Будет следующий. Пока я в отпуске
Отличное видео, добавил бы в плюсы, что отдельному модулю гораздо проще регулировать зависимости, чем всему проекту целиком.
Да, хороший поинт!
Жаль только все остальное усложняется на порядок ;)
Очень инересно на примере посмотреть, как это работает с DI. Еще посмотрел бы на Clean Architecture
В сети куча примеров. Учи нехочу
@@JamesBond-mq7pd мне интересно видео, а не разбирать кучу исходников без объяснений, но ты прав, примеров много
Отличное видео! Хотелось бы практическую часть
А точно много модульный собирается быстрее? Мне кажется что не очень, а может и наоборот.
Про архитектуру в многомодульном очень интересно бы послушать. Сравниваю что есть сейчас со старыми статьями и это большая разница
Сборка с нуля точно не будет существенно быстрее, но если правильно организованы зависимости между модулями то выигрыш точно будет. Особенно на машинах со множеством ядер и оперативки
Спасибо за видео! Подписка и лайк. Жду видео про многомодульный проект, стыдно наверно, но для меня открытие что многомодульность поможет быстрее собирать проект если изменения произошло только в одном модуле. Интересно бы увидеть доказательства по скорости на пет-проекте.
Не факт что быстрее. Если изменения произошли в модуле от которого зависят все модули приложения, то собирается придётся всему
ждем видос, что в конце обещал)
Жду лайков и больше комментариев для него )))
Отличный видосик, полностью поддерживаю)
Мне кажется многомодульность даже обязательно нужно использовать, мне нравится инкапсуляция, короткие имена классам, отдельно описывается верстка экранов и ресурсов.
А на мой взгляд многомодульность стоит использовать только если она объективно необходимо. Иначе усложнение и накладные расходы никогда не окупятся.
koin с многомодульностью нормально вяжется или нет?
Тут очень вопрос что значит "нормально" Сделать можно, проблем нет. Насколько это "нормально" решать каждому для себя
Хочу майку, хочу видосы про многомодульнность!!!
За видос спасибо!
Работаю в продуктовой конторе, пилим небольшие приложения под заказ, сейчас в работе приложение экранов на 20, фичей буквально штуки четыре-пять. Я это с самого начала пытаюсь сделать многомодульным. Стоит ли поворачивать назад, пока не поздно, и пока меня hilt не начал больно бить по голове?
П.С. я джун, коммерческого опыта полгода в одиночку, а в компании спросить некого, андроид-разработчиков больше нет
Да не надо разворачивать назад, если чувствуешь силы. Будет опыт по крайней мере)
Hilt плохо ложиться на многомодульность. Если раньше у вас не было опыта в этом - не рискуете. Лучше будет побольше сборка, зато не будете страдать из-за неправильных архитектурных решений, которые уже пронзили все модули
Круто. Спасибо 🔥
7:04 забыл всплывающую подсказку добавить
Видео пока нет
@@AndroidBroadcast , а теперь есть! Можно и подсказку добавить.
@@ki16or Готово!
Насчёт скорости сборки большие сомнения. Если сам делаешь фичу и тронул запрос, ресурс из другого модуля - привет, сборка 20 минут. А если есть всего один модуль, на мой взгляд, скорость сборки сопоставима с многомодульным (в пределах пары минут). Скажем спасибо и Dagger, который дополнительно повысит время сборки в многомодульном проекте. Поэтому для небольших команд я бы не рекомендовал.
еще к плюсам - отдельный модуль можно заюзать на другом проекте.
У вас часто такое получается?