Иерархия модулей: как выстроить связи между модулями в Android

[jumperk]

Хотелось бы еще раскрыть тему деления на модули + ui тесты для них. Например, есть у вас три аппликейшн модуля - applicant, hr-mobile, design-gallery. Есть ui тесты в каждом из этих модулей в папке androidTest, которые относятся к конкретному апликейшену, есть ui фича от которой зависят все три апп модуля - надо написать ui тест для это фичи, вопрос куда поместить этот тест и можно ли общие тесты вынести в отдельный модуль? Интересует как вы пишете ui тесты для каждого апп модуля и что делаете, если нужно протестировать общую ui фичу от которой зависят несколько апп модулей?) Спасибо

[georgyR]

Мы ui-тесты не выносим в отдельные модули. Допустим, тесты для applicant лежат в app-модуле этого приложения. Фичи достаточно сложно тестить в отрыве от контекста их использования. Фича может иметь внешние зависимости, несколько точек входа, и это все может сильно менять поведение фичи. Поэтому если фича покрывается ui-тестами, то в контексте конкретного приложения.

На самом деле у нас не так много общих ui-фичей между приложениями. В основном это какие-то общие core-модули для архитектурных компонентов, работа с data-слоем и пр. А этот код хорошо покрывается unit-тестами. А такие тесты уже складываем в конкретные модули этих компонентов.

[Savitskiy_Sergey]

как вы посчитали зависимости (критический путь) между модулями у себя в проекте? Руками или есть какой то инструмент?

[horseunnamed]

Когда-то считали самописным Gradle-плагином в связке с https://github.com/cdsap/Talaiot, чтобы учитывать фактическое время сборки тасок, но сейчас эта фича есть в Gradle Build Scan (https://scans.gradle.com/). В build scan есть Timeline сборки и в поиске по нему можно поставить галочку "On critical path", чтобы подсветить участвующие в критическом пути таски. При этом для оценки критического пути важно запускать сборку с флагом --no-cache, чтобы исключить влияние кэша.

[Steeshock]

Полезная статья. Главное сильно не увлекаться вынесением общего кода между фичами, бывает сложно на начальном этапе выделить корректную абстракцию. И то, что кажется похожим и общим сейчас, может иметь тенденцию к расхождению по разным сторонам в будущем. Общий код != правильная абстракция, и иногда бывает даже лучше продублировать некоторые вещи, чем закинуть всё в Core модуль.

[Xanderblinov]

Очень частый вопрос: как вообще выделять правильно модули. Так и не смог для этого вынести какие-то формальные критерии. Получается что-то типа: отдельная фича — это кусок кода с изолированной логикой, не очень большой и не очень маленький >_<

[krossovochkin]

Первая проблема — если у нас большой проект, становится сложно ориентироваться в коде. Наше приложение — многомодульный проект, в котором несколько сотен модулей. Если сложить весь код в одну директорию, потеряться будет проще простого. 

Очень странный абзац

Можно с той же структурой пакетов держать один модуль и проблемы ориентации в коде не будет

Как сложить код нескольких сотен модулей в одну директорию? Обычно код модуля и так лежит в отдельной директории

В остальном, хорошая статья, спасибо

[maxkachinkin]

@georgyRспасибо за статью, очень интересно! У меня 2 вопроса:

1. Можешь, пожалуйста, рассказать подробнее про sub-feature? А то ты перечислял типы модулей, а потом буквально вскользь написал про sub-feature. Но что это, и чем это отличается в feature?

2. Есть ли у вас механизм, как переиспользовать фичу в другой фиче? Например, есть фича на одном экране. И надо её точно также показать совершенно в другом. Как вы это делаете?

[georgyR]

1. В разделе "Зачем делить большие фичи" как раз и идет речь о sub-feature. Из текста, конечно, это не очевидно получилось. По сути это обычные feature-модули, только они объединены общей бизнес-областью, и имею общие core-модули.

2. Да, конечно есть, без этого дальше 1-2 экранов не получилось бы навигироваться). У каждого модуля есть свой api. Допустим есть модуль c экраном Resume, api модуля содержит функцию getNavScreen(). У модуля ResumeList, который хочет открыть этот экран, есть зависимость deps - интерфейс с функцией getResumeNavScreen(). Оба модуля подключены к app-модулю, поэтому мы через него можем реализовать зависимость модуля ResumeList и связать 2 фичи. Но это если в вкратце, подробно про связывание модулей можно почитать в https://habr.com/ru/company/hh/blog/566450/