Зачем нужна многомодульная архитектура. Плюсы и минусы
Vložit
- čas přidán 18. 07. 2021
- Разбираемся зачем в проектах нужна многомодульная архитектура и как она улучшить ваш проект. Также говорим о минусах такого подхода и для какой команды/проекта нужен такой подход
💰 Поддержать проект на Boosty bit.ly/3sratqQ или Patreon / android_broadcast
🔗 Telegram канал "Android Broadcast" ttttt.me/android_broadcast
#AndroidBroadcast #Модуляризация #Архитектура #Gradle #КириллРозов #РозовКирилл #Android #AndroidDev - Věda a technologie
💰 Поддержать проект на Boosty bit.ly/3sratqQ или Patreon patreon.com/android_broadcast
🔗 Telegram канал "Android Broadcast" ttttt.me/android_broadcast
Тема интересная, рад был бы услышать более детальный разбор)
комментарий для продвижения канала
Жду видео про многомодульный проект! Спасибо!
Останусь пожалуй при своем мнении - многомодульность делать только тогда, когда без нее никак. В основном это для больших команд и больших проектов. Или если фича-тоглы нужны. В других кейсах минусы и гемор многомодульности перевешивают его плюсы.
По-моему я так и сказал в видео
@@AndroidBroadcast да, я ж не спорю о сказанном))) Спасибо за видео. Просто из этой многомодульности какой-то хайп сделали. Пилят на аутсорсе приложение полтора разработчика, эстимейт 3 месяца, зато многомодульность обязательно.
Спасибо за видео, да будет очень интересно посмотреть как правильно варить эти прекрасные многомодульные проекты )
Это скорее будет не единственный правильный, а моё видение
Спасибо за видео)
Было бы классно увидеть видос с обзором какого-нибудь многомодульного проекта и как это всё дело варить
Как всегда кратко и по делу! Спасибо за контент! После Дагера и Карутин - может быть сделаешь пару видео по этой теме?)
Планов уже получается столько, что ничего не буду обещать
Костя, вы ж Даггер не признавали или уже сменили гнев на милость?
@@mrgagarinn я и сейчас считаю, что подключать его в небольшие приложения - не очень правильное решение. Как и переписывать приложения в которых и так разведен DI - не очень оправданно. Есть случаи когда он действительно полезен...
Но речь тут шла о модульности, и т.к. я знаю что у Кирилла (автора канала) - курс по Дагеру и Корутинам уже в разработке, то понимал, что ждать видео раньше их окончания - немного бессмысленно.
Круто. Спасибо 🔥
Отличное видео! Хотелось бы практическую часть
Расскажи про возможность писать 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, который дополнительно повысит время сборки в многомодульном проекте. Поэтому для небольших команд я бы не рекомендовал.