Один из разработчиков пишет:
Я откликнулся на вакансию в компанию среднего размера на позицию Android-разработчика с Kotlin и Jetpack Compose.
Во время первичного собеседования рекрутер в основном спрашивал о чистой архитектуре и принципах SOLID, однако они не являются моими лучшими навыками. Его вопросы об Android были настолько простыми, что любой мог бы ответить на них с помощью простого поиска в Google.
Он настаивал на важности чистой архитектуры в их проектах и дал мне небольшую задачу, которая требовала от меня решения с использованием чистой архитектуры, и даже напомнил мне, что UI/UX не важен.
Это всего лишь простое CRUD-приложение с двумя/тремя сущностями, человеком, едой и любимыми блюдами с отношениями «многие ко многим».
Он настаивал на том, что приложение должно включать такие слои, как приложение, сервис, репо, домен и т.д., в то время как, на мой взгляд, чистая архитектура состоит в основном из слоя представления, домена и данных, и даже дядя Боб говорит, что вы можете добавлять столько слоев, сколько хотите, просто держите их проблемы отдельно.
Лично я предпочитаю использовать MVVM или вообще не использовать архитектуру в Android.
Является ли использование чистой архитектуры излишеством для Android или я просто неопытен и неинформирован?
Вот некоторые ответы:
- В основе этого лежит намерение интервьюера оценить, умеете ли вы эффективно разделять проблемы. Суть любой архитектуры — будь то чистая архитектура или MVVM — заключается в принципе разделения ответственности. Но почему это разделение так важно? Если этого не сделать, то любое изменение, внесенное в одну область, может повлиять на другие взаимосвязанные части, превращая обслуживание приложения в кошмар. Для простых приложений с несколькими экранами использование чистой архитектуры или MVVM может оказаться излишним. Однако для долгосрочного проекта, такого как банковское приложение, которое необходимо поддерживать в будущем, написание чистого кода с правильной архитектурой не просто необходимо — оно обязательно.
- Я бы сказал, что это неопытность в работе с большими кодовыми базами. Когда вы разрабатываете приложение самостоятельно или с небольшой командой, MVVM справляется со своей задачей. Для больших приложений каждый раз, когда требования меняются или добавляются, если у вас нет слоя абстракции, вас ждут большие неприятности. Вы также облегчаете тестирование конкретных требований, разделяя бизнес-логику на собственные домены/репозитории. Это ни в коем случае не идеальное решение, но большие приложения с несколькими командами разработчиков нуждаются в четком разграничении доменов для удобства сопровождения.
- Зависит от размера проекта, но в целом, если не уточнять, то да, чистая архитектура обычно избыточна для Android. MVVM с UseCase и Repository (которые технически «заимствованы» из Clean Architecture) для разделения проблем достаточно, структурирование в стиле фиксирования слоев ничего не решает.
- Чистая архитектура — это не про добавление как можно большего количества слоев, а про то, чтобы основной/доменный код не зависел от фреймворков, IO, UI и т.д. Я не уверен, что рекрутер это понимает.
- Я думаю, это зависит от проекта. Если у них есть ресурсы, чтобы потратить на это время, и они хотят добавить тесты, которые позволяет такая архитектура, то конечно. Это может показаться излишеством, но наличие надежных тестов может в долгосрочной перспективе помочь найти проблемы и сэкономить время. Тем не менее, потребности бизнеса должны стоять на первом месте, поэтому я думаю, что вы вправе спросить, действительно ли эти усилия приносят пользу или нет.
В конечном счете, наша цель — писать понятный, лаконичный, расширяемый и сопровождаемый (и тестируемый) код, причем не только для себя, но и для своих коллег. Таким образом, следуя «общим» принципам чистой архитектуры, вы достигаете чего-то достойного, знакомого всем.
- MVVM — это архитектура «представлений». Затем, отдельно, вы решаете архитектуру вашей M-части (или модели данных, которая отличается от модели представления). Чистая архитектура — один из таких вариантов, но она мало пересекается с MVVM. Традиционно эти архитектуры моделей данных были более применимы к бэкендам и API, но с учетом все более высоких ожиданий, возлагаемых на фронт-энд, они являются вполне приемлемыми (и особенно удобными для сопровождения) способами создания слоя данных во фронт-энде. Я считаю, что вы, скорее всего, неопытны и неинформированы, поскольку, за исключением действительно небольших приложений (т. е. ничего «профессионального»), вы всегда должны думать об архитектуре слоя данных.
- Если цель — создать приложение и на этом закончить, то да, чистый код, хорошая архитектура и куча юнит-тестов будут излишеством. Но когда вам нужно иметь возможность быстро добавлять функции и исправлять ошибки в приложении, которое будет продолжать расти и должно жить 10+ лет, уравнение полностью меняется. Именно в этом и заключается работа в средних и крупных компаниях. Создание того, на что можно опираться десятилетиями.
- Для изучения того, как работает разработка под Android… Да, это излишество, особенно раздражает внедрять архитектуру в todo-приложение, когда знаешь, что это гораздо проще сделать без нее. Но в конце концов, если речь идет о больших проектах, это просто помогает… Это помогает вам держать вещи организованными (с моей точки зрения).