Проект с несколькими модулями Gradle известен как многомодульный проект. В этом руководстве представлены лучшие практики и рекомендуемые шаблоны для разработки многомодульных приложений для Android.
Растущая проблема с кодовой базой
В постоянно растущей кодовой базе масштабируемость, читаемость и общее качество кода часто со временем снижаются. Это происходит из-за того, что размер кодовой базы увеличивается, а ее сопровождающие не принимают активных мер по обеспечению легко поддерживаемой структуры. Модуляризация — это средство структурирования вашей кодовой базы таким образом, чтобы улучшить удобство сопровождения и помочь избежать этих проблем.
Что такое модульность?
Модуляризация — это практика организации кодовой базы на слабосвязанные и автономные части. Каждая часть представляет собой модуль. Каждый модуль независим и служит четкой цели. Разделив проблему на более мелкие и более простые для решения подзадачи, вы снижаете сложность проектирования и обслуживания большой системы.
Преимущества модульности
Преимущества модульности многочисленны, хотя каждое из них направлено на улучшение удобства сопровождения и общего качества кодовой базы. В таблице ниже приведены основные преимущества.
| Выгода | Краткое содержание |
|---|---|
| Многоразовое использование | Модульность открывает возможности для совместного использования кода и создания нескольких приложений на одной основе. Модули по сути являются строительными блоками. Приложения должны представлять собой сумму своих функций, организованных в виде отдельных модулей. Функциональность, предоставляемая определенным модулем, может быть включена или не включена в конкретном приложении. Например, :feature:news может быть частью полной версии приложения, но не частью демо-версии. |
| Строгий контроль видимости | Модули позволяют вам легко контролировать то, что вы предоставляете другим частям вашей кодовой базы. Вы можете пометить все, кроме вашего общедоступного интерфейса, как internal или private чтобы предотвратить его использование за пределами модуля. |
| Настраиваемая доставка | Play Feature Delivery использует расширенные возможности пакетов приложений, позволяя вам предоставлять определенные функции вашего приложения при определенных условиях или по требованию. |
Вышеописанные преимущества достижимы только при использовании модульной базы кода. Следующие преимущества могут быть достигнуты с помощью других методов, но модульность может помочь вам еще больше усилить их.
| Выгода | Краткое содержание |
|---|---|
| Масштабируемость | В тесно связанной кодовой базе одно изменение может вызвать каскад изменений в, казалось бы, несвязанных частях кода. Правильно модульный проект будет учитывать принцип разделения задач и, следовательно, ограничивать взаимосвязь. Это расширяет возможности участников за счет большей автономии. |
| Право собственности | Помимо обеспечения автономии, модули также можно использовать для обеспечения подотчетности. У модуля может быть выделенный владелец, который отвечает за поддержку кода, исправление ошибок, добавление тестов и проверку изменений. |
| Инкапсуляция | Инкапсуляция означает, что каждая часть вашего кода должна иметь минимально возможный объем знаний о других частях. Изолированный код легче читать и понимать. |
| Тестируемость | Тестируемость характеризует, насколько легко протестировать ваш код. Тестируемый код — это код, компоненты которого можно легко протестировать изолированно. |
| Время сборки | Некоторые функции Gradle, такие как инкрементная сборка, кэш сборки или параллельная сборка, могут использовать модульность для повышения производительности сборки . |
Распространенные ловушки
Детализация вашей кодовой базы — это то, насколько она состоит из модулей. Более детализированная кодовая база имеет больше модулей меньшего размера. При проектировании модульной базы кода вам следует определиться с уровнем детализации. Для этого примите во внимание размер вашей кодовой базы и ее относительную сложность. Слишком детальный подход увеличит накладные расходы, а слишком грубый уменьшит преимущества модульности.
Некоторые распространенные ошибки заключаются в следующем:
- Слишком детальный : каждый модуль приносит определенные накладные расходы в виде повышенной сложности сборки и шаблонного кода . Сложная конфигурация сборки затрудняет поддержание согласованности конфигураций между модулями. Слишком много шаблонного кода приводит к громоздкой кодовой базе, которую трудно поддерживать. Если накладные расходы препятствуют улучшению масштабируемости, вам следует рассмотреть возможность консолидации некоторых модулей.
- Слишком крупнозернистый : И наоборот, если ваши модули становятся слишком большими, вы можете получить еще один монолит и упустить преимущества, которые может предложить модульность. Например, в небольшом проекте можно поместить уровень данных в один модуль. Но по мере его роста может возникнуть необходимость разделить репозитории и источники данных на отдельные модули.
- Слишком сложно . Не всегда имеет смысл разбивать проект на модули. Доминирующим фактором является размер кодовой базы. Если вы не ожидаете, что ваш проект превысит определенный порог, выигрыш в масштабируемости и времени сборки не будет применен.
Подходит ли мне модульность?
Если вам нужны преимущества повторного использования, строгого контроля видимости или использования Play Feature Delivery , тогда модульность вам необходима. Если вы этого не делаете, но все же хотите получить выгоду от улучшенной масштабируемости, владения, инкапсуляции или сокращения времени сборки, то стоит рассмотреть модульность.
Образцы
- Теперь и в Android — полнофункциональное Android-приложение с модульной структурой.
- Пример многомодульной архитектуры
Проект с несколькими модулями Gradle известен как многомодульный проект. В этом руководстве представлены лучшие практики и рекомендуемые шаблоны для разработки многомодульных приложений для Android.
Растущая проблема с кодовой базой
В постоянно растущей кодовой базе масштабируемость, читаемость и общее качество кода часто со временем снижаются. Это происходит из-за того, что размер кодовой базы увеличивается, а ее сопровождающие не принимают активных мер по обеспечению легко поддерживаемой структуры. Модуляризация — это средство структурирования вашей кодовой базы таким образом, чтобы улучшить удобство обслуживания и помочь избежать этих проблем.
Что такое модульность?
Модуляризация — это практика организации кодовой базы на слабосвязанные и автономные части. Каждая часть представляет собой модуль. Каждый модуль независим и служит четкой цели. Разделив проблему на более мелкие и более простые для решения подзадачи, вы снижаете сложность проектирования и обслуживания большой системы.
Преимущества модульности
Преимущества модульности многочисленны, хотя каждое из них направлено на улучшение удобства сопровождения и общего качества кодовой базы. В таблице ниже приведены основные преимущества.
| Выгода | Краткое содержание |
|---|---|
| Многоразовое использование | Модульность открывает возможности для совместного использования кода и создания нескольких приложений на одной основе. Модули по сути являются строительными блоками. Приложения должны представлять собой сумму своих функций, организованных в виде отдельных модулей. Функциональность, предоставляемая определенным модулем, может быть включена или не включена в конкретном приложении. Например, :feature:news может быть частью полной версии приложения, но не частью демо-версии. |
| Строгий контроль видимости | Модули позволяют вам легко контролировать то, что вы предоставляете другим частям вашей кодовой базы. Вы можете пометить все, кроме вашего общедоступного интерфейса, как internal или private чтобы предотвратить его использование за пределами модуля. |
| Настраиваемая доставка | Play Feature Delivery использует расширенные возможности пакетов приложений, позволяя вам предоставлять определенные функции вашего приложения при определенных условиях или по требованию. |
Вышеописанные преимущества достижимы только при использовании модульной базы кода. Следующие преимущества могут быть достигнуты с помощью других методов, но модульность может помочь вам еще больше усилить их.
| Выгода | Краткое содержание |
|---|---|
| Масштабируемость | В тесно связанной кодовой базе одно изменение может вызвать каскад изменений в, казалось бы, несвязанных частях кода. Правильно модульный проект будет учитывать принцип разделения задач и, следовательно, ограничивать взаимосвязь. Это расширяет возможности участников за счет большей автономии. |
| Право собственности | Помимо обеспечения автономии, модули также можно использовать для обеспечения подотчетности. У модуля может быть выделенный владелец, который отвечает за поддержку кода, исправление ошибок, добавление тестов и проверку изменений. |
| Инкапсуляция | Инкапсуляция означает, что каждая часть вашего кода должна иметь минимально возможный объем знаний о других частях. Изолированный код легче читать и понимать. |
| Тестируемость | Тестируемость характеризует, насколько легко протестировать ваш код. Тестируемый код — это код, компоненты которого можно легко протестировать изолированно. |
| Время сборки | Некоторые функции Gradle, такие как инкрементная сборка, кэш сборки или параллельная сборка, могут использовать модульность для повышения производительности сборки . |
Распространенные ловушки
Детализация вашей кодовой базы — это то, насколько она состоит из модулей. Более детализированная кодовая база имеет больше модулей меньшего размера. При проектировании модульной базы кода вам следует определиться с уровнем детализации. Для этого примите во внимание размер вашей кодовой базы и ее относительную сложность. Слишком детальный подход приведет к увеличению накладных расходов, а слишком грубый подход уменьшит преимущества модульности.
Некоторые распространенные ошибки заключаются в следующем:
- Слишком детальный : каждый модуль приносит определенные накладные расходы в виде повышенной сложности сборки и шаблонного кода . Сложная конфигурация сборки затрудняет поддержание согласованности конфигураций между модулями. Слишком много шаблонного кода приводит к громоздкой кодовой базе, которую трудно поддерживать. Если накладные расходы препятствуют улучшению масштабируемости, вам следует рассмотреть возможность консолидации некоторых модулей.
- Слишком крупнозернистый : И наоборот, если ваши модули становятся слишком большими, вы можете получить еще один монолит и упустить преимущества, которые может предложить модульность. Например, в небольшом проекте можно поместить уровень данных в один модуль. Но по мере его роста может возникнуть необходимость разделить репозитории и источники данных на отдельные модули.
- Слишком сложно . Не всегда имеет смысл разбивать проект на модули. Доминирующим фактором является размер кодовой базы. Если вы не ожидаете, что ваш проект превысит определенный порог, выигрыш в масштабируемости и времени сборки не будет применен.
Подходит ли мне модульность?
Если вам нужны преимущества повторного использования, строгого контроля видимости или использования Play Feature Delivery , тогда модульность вам необходима. Если вы этого не делаете, но все же хотите получить выгоду от улучшенной масштабируемости, владения, инкапсуляции или сокращения времени сборки, то стоит рассмотреть модульность.
Образцы
- Теперь и в Android — полнофункциональное Android-приложение с модульной структурой.
- Пример многомодульной архитектуры