Развенчиваем 6 мифов про современную Android-разработку

Забудьте о формальностях! В этом посте нет вступления 😅 (или, может быть, у меня синдром пустой страницы). Давайте попробуем развенчать некоторые мифы о разработке под Android и проясним ситуацию (на самом деле это хорошее вступление, не так ли?).

Помните, это моя точка зрения (подкрепленная фактами).

Разработка под Android — это не Jetpack Compose

Хотя Jetpack Compose — это мощный набор инструментов для создания пользовательских интерфейсов в Android, разработка Android включает в себя гораздо больше, чем просто создание пользовательских интерфейсов. Чтобы стать квалифицированным разработчиком Android, необходимо понимать фундаментальные концепции программирования, такие как объектно-ориентированное программирование, владеть языками, которые вы будете использовать (например, Kotlin). Кроме того, разработчики должны работать с сетевыми данными, используя базы данных и API, проектировать надежные архитектуры, управлять жизненным циклом Android, оптимизировать приложения для различных устройств и т.д. Все эти навыки в совокупности позволяют разработчикам создавать надежные, эффективные и качественные приложения для Android.

Инъекция зависимостей — это не использование Hilt

«В программной инженерии инъекция зависимостей — это техника программирования, при которой объект или функция получает нужные ему объекты или функции извне, в отличие от создания их внутри«, — Википедия.

Суть DI заключается в том, чтобы отделить создание зависимостей от классов, которые их используют, что упрощает управление и тестирование компонентов в изоляции. Этого можно достичь вручную с помощью инъекции конструкторов, инъекции методов или инъекции свойств, не прибегая к помощи фреймворков. К сожалению, некоторые разработчики становятся чрезмерно зависимыми от фреймворков вроде Hilt и с трудом реализуют принципы DI без них.

Хотя Hilt, Dagger, Koin и другие DI-фреймворки упрощают процесс, автоматизируя подключение зависимостей (и делая другие вещи за вас), понимание основных принципов DI очень важно. Это даже даст вам больше комфорта при работе с этими фреймворками, и вы будете знать, почему вы их используете (или не используете).

DI — это паттерн, а не фреймворки, используемые для его реализации.

Jetpack ViewModel не является «ViewModel» MVVM

Вопреки распространенному мнению, реализация архитектурного паттерна Model-View-ViewModel (MVVM) не обязательно требует использования Android Architecture Components (AAC) ViewModel (или Jetpack Viewmodel). Распространенным заблуждением является то, что использование Android Jetpack ViewModel автоматически означает, что вы следуете архитектурному паттерну MVVM. Это не так.

Jetpack ViewModel — это компонент, учитывающий жизненный цикл, предназначенный для управления данными пользовательского интерфейса таким образом, чтобы они выдерживали изменения конфигурации, такие как поворот экрана (мы даже можем обрабатывать это разными способами). Хотя это ценный инструмент, его использование само по себе не является MVVM-архитектурой.

В MVVM ViewModel выступает в качестве слоя абстракции, который инкапсулирует состояние и поведение представления, а также раскрывает свойства, к которым представление может привязываться. Она также выступает в роли преобразователя значений, отвечая в первую очередь за подготовку и передачу объектов данных из слоя Модели в слой Представления в формате, удобном для управления и представления.

В отличие от Презентера в паттерне MVP, который обычно содержит ссылку на представление, ViewModel в MVVM не содержит прямой ссылки на представление. Вместо этого она полагается на биндинг данных или другие механизмы для синхронизации данных между представлением и собой.

Весь этот длинный абзац я написал лишь для того, чтобы сказать вам, что вы можете использовать Jetpack ViewModel в своем проекте и не реализовывать MVVM, и наоборот, вы можете следовать принципам MVVM, не обязательно внедряя Jetpack ViewModel.

Вы можете вызывать репозиторий непосредственно из ViewModel

Многие сторонники «чистой архитектуры» (на Linkedin и X) выступают против вызова Репозитория непосредственно из ViewModel, считая это сокращением или нарушением архитектурных принципов. Они внедряют ненужные слои, например, создавая классы UseCase, которые выступают в качестве посредников между ViewModel и Репозиториями. Такой подход часто приводит к чрезмерной инженерии, когда разработчики получают проекты, наполненные классами UseCase, которые не служат никакой цели, кроме вызова метода хранилища и возврата данных. А самое интересное, что они размещают логику, предназначенную для UseCase, в неправильном месте (например, во ViewModel).

Обратите внимание, что очень важно оценить, приносит ли добавление этих дополнительных слоев реальную пользу вашему проекту. Для более простых приложений или сценариев, где бизнес-логика остается простой, вызов хранилища непосредственно из ViewModel может упростить вашу кодовую базу и улучшить понимание кода.

Пропаганда ненужных слоев в архитектуре набирает популярность в социальных сетях. Она может ввести в заблуждение, особенно начинающих разработчиков, поскольку может подтолкнуть к внедрению сложных архитектур без явных преимуществ.

Рекомендации Google — это всего лишь «рекомендации Google»

К рекомендациям и «лучшим практикам» Google следует подходить критически. Зачастую они связаны с отменой ранее рекомендованных практик и последующим их повторным внедрением.

Вы не являетесь крупной компанией

К «лучшим отраслевым практикам» следует подходить критически, оценивая, насколько они соответствуют конкретным целям, срокам и ресурсам вашего проекта. Слепое принятие практик, основанных исключительно на одобрении крупных технологических компаний, может привести к ненужной сложности, чрезмерной инженерии или неэффективности. Вместо этого очень важно оценивать каждую рекомендацию в контексте вашей собственной среды разработки и разумно адаптировать все подходы, чтобы убедиться, что они действительно приносят пользу вашему проекту.

Легко попасть в ловушку, полагая, что то, что работает в крупных технологических гигантах, будет работать без проблем для небольших команд разработчиков или отдельных разработчиков. То, что работает для них, не обязательно будет наиболее эффективным или практичным решением для небольших проектов или команд с другими потребностями и ограничениями.

Начните с хорошего фундамента и расширяйте его по мере необходимости.

Заключение

Эта статья не охватывает все мифы, циркулирующие об Android или о разработке программного обеспечения в целом. Моя цель — подчеркнуть жизненную важность анализа и оценки информации, которую вы потребляете. Очень важно отдавать предпочтение практичности, а не слепому принятию популярных практик или следованию за технологическими авторитетами.

Источник