Бауыржан (brotandos) wrote,
Бауыржан
brotandos

Categories:

Заметки по Android. Чистая архитектура

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

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

Я работал в разных компаниях, и в команде и в одиночке, и вот эти архитектурные слои почти везде были лишними и усложняли работу черезчур и увеличивали бюрократию.

Мой хороший знакомый, который 5 лет проработал мобильщиком сказал, что расплодившиеся сущности - плата за стандарт и прозрачность. Вот только там прозрачности кот наплакал. Когда 10 разработчиков пытаются следовать этому подходу, получается не приложение, а Гордиев узел, который хрен распутаешь.

Чтобы вы понимали мое негодование, я обьясню, как рисуется экран в андроид приложении по этому паттерну. Предлагаю представить экран, где есть тулбар, меню в тулбаре, сложный список элементов, поле поиска, выдвижное меню (Drawer как в телеграме) и диалоговым окном. Только для отрисовки могут понадобиться такие файлы, как:
1) Верстка экрана на xml
2) Верстка тулбара, так как она часто общая
3) xml представление меню от тулбара
4) xml представление меню от выдвижного элемента
5) Верстка заголовка выдвижного элемента (header view)
6) Верстка отдельного элемента списка типа ‘А’ (item_a.xml)
7) Верстка отдельного элемента списка типа ‘В’ (item_b.xml)
8) Файл логики представления активити для этого экрана
9) Файл адаптера для списка
10) Файл логики для элемента списка типа ‘А’ (AItemViewHolder)
11) Файл логики для элемента списка типа ‘В’ (BItemViewHolder)
12) Верстка диалогового окна
13) Файл логики представления диалогового окна



Вот, 13 файлов вышло. А я еще опустил некоторые детали, ведь могут быть файлы, от которых вышесказанные унаследованы, могут быть утилитарные классы. Вот 10 файлов это уже минимум для простой отрисовки. Теперь вернемся к чистой архитектуре и слоям, которые они рекомендуют:
1) Слой презентации отображения
2) Слой interactor
3) Слой repository для базы данных
4) Слой repository для обращения к серверу
5) Слой моделей
6) Всякие интерфейсы
7) Описания Dependency Injection

Вот еще 7 файлов. Если вдруг и логика диалога непростая, добавьте еще 2-3 файла. И это минимум, чтобы удовлетворить правила паттерна. Итого 20 файлов. Если вспомнить про дополнительные ньюансы, которые почти в каждом экране есть, вспомнить про файлы тестов, бюрократию и обобщения, может выйти до 30-40 файлов. Вдумайтесь, сколько файлов нужно поддерживать, чтобы один несчастный экран работал. Это, на минуточку, идеальный расклад, архитектура в вакууме. Можно сверху накинуть всякие костыли и “временные” решения. Добавление новой фичи может превратиться в квест по масштабу доставке кольца в Мордор. Пока ты дойдешь до 15-го файла, ты забудешь зачем пришел. А обсуждение фич превращается в этот концерт:


В итоге файлы плодятся, как кролики весной. А если учесть, что дизайн и тех.задания могут быть динамичны и меняться каждые 2-3 недели, вы поймете откуда у разработчиков синяки под глазами. Вот и расплодилось куча сущностей, хотели придерживаться одними правилами, нарушили другие.

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

Я работал с web-приложениями, там такого извращения нет. Скорее всего потому, что веб-разработка началась десятилетиями раньше и опережает в развитии мобильную разработку.

И как же быть? На мой взгляд невозможно обойтись без этих Слоев Бесконечности от дядушки Боба в двух случаях. Когда вы пишите автотесты и когда пишите демо проекты для работодателей. Все. В остальных случаях сомневаюсь, что это упростит вашу работу. С файлами ui ничего не поделаешь, таков стандарт от гугла, другого нет либо они еще хуже, тут придется файлы громоздить.

Если вы работаете в одиночке или паре, думаю можно обойтись без этих слоев, потому что новый разраб вряд ли ваше толкование схватит на лету. Если уйдете, заменяющий вас на 95% снесет ваше добро и начнет заново.

Какие ваши мнения и какой опыт у вас? Если вы с другой области, поделитесь проблемами?
Tags: android разработка, Работа, разработка
Subscribe

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic
  • 0 comments