Почему VIPER это хороший выбор для вашего следующего приложения

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

    Введение


    VIPER, подобно современным блогерам, собрала вокруг себя достаточно много хайпа. У неё появились как хейтеры, так и люди, свято верующие в идеальность этой архитектуры. Хейтеры VIPER породили множество заблуждений разного характера. Вот некоторые из них:

    • В VIPER модуле слишком много классов
    • Высокий порог вхождения — неопытные программисты не смогут с ней работать
    • На множество проблем нет стандартизованного решения
    • Presenter — ненужный компонент, который занимается исключительно посредничеством
    • Зачем мне 99% покрытие кода тестами, которое обеспечивает VIPER?

    Не могу похвастаться большим числом проектов, написанных мной с использованием VIPER, но всё же они есть. И, исходя из своего опыта, могу сказать, что на все эти заблуждения есть вполне логичные ответы.

    О большом количестве классов


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

    О пороге вхождения


    Теперь про порог вхождения. Он действительно «большой», но только для новичка. Не скрою — я и сам не сразу разобрался как написать VIPER модуль, но и опыта разработки в то время у меня было всего несколько месяцев. А, когда мы в компании первый раз решили использовать VIPER, моим коллегам было достаточно одного code review готового модуля чтобы написать свой. Так что архитектура совсем несложная, сложно заставить себя в ней разобраться.

    О стандартах


    На первый взгляд кажется, что все в VIPER понятно — View отображает, Interactor предоставляет, Router переходит, а Presenter связывает. Но это только верхушка айсберга. Когда начинаешь писать первый модуль, то часто не можешь понять — где писать определенный код. И многие программисты основываются на чужих решениях, которые могут решать одну проблему по-разному. И программисты начинают говорить про то, что VIPER — это плохо. Мне кажется, что тут дело не в VIPER, а в тех самых примерах, которые смотрят люди. Какова вероятность, что человек хорошо разобрался в архитектуре перед тем как выложить свой код? Столько же сколько и вероятность встретить динозавра на улице — 50%. Поэтому прежде всего надо думать своей головой и тогда всё встанет на свои места. На самом деле в VIPER очень чётко разделены обязанности между компонентами модуля. И, если Вы не знаете куда отнести какую-то вещь, то просто перечитайте ещё раз про VIPER или посмотрите книгу Rambler&Co.

    О Presenter'е


    Бытует мнение, что Presenter выполняет роль посредника между View и Interactor, и что этот компонент лишний в VIPER модуле. Тут я скажу, наверно, очевидные вещи, но всё же. Во-первых, Presenter хранит состояние всего модуля. Во-вторых, Presenter выступает в качестве Input и Output модуля. В-третьих, он не просто передает команды от View к Interactor и т.д., а принимает решения — в каком случае что именно надо сделать, а это уже не совсем посредничество.

    О тестировании


    И последнее — зачем же нам 99% покрытие кода тестами, которое обеспечивает VIPER? На первый взгляд ответ на вопрос лежит на поверхности — затем, чтобы быть уверенным в корректной работе приложения. Но тут дело, скорее всего, не в цифре, а в самом факте того, что VIPER это позволяет. И позволяет сделать достаточно легко в отличии от некоторых других архитектур. И при разработке любых по сложности проектов это является огромным плюсом.

    Заключение


    Да, у VIPER есть свои недостатки (нет ничего идеального), но не стоит ей пренебрегать. Но и не стоит использовать её во всех проектах подряд. Всё-таки архитектура приложения выбирается исходя из множества различных факторов и требований, а не только из-за фанатизма. И, прежде чем говорить что она плохая или хорошая, стоит написать на ней 2-3 приложения, чтобы всё как следует взвесить.

    Надеюсь, я не превысил количество слова VIPER на квадратный сантиметр.
    Спасибо за прочтение!
    Поделиться публикацией

    Комментарии 13

      0

      Вот знаете, не могу с вами не согласиться. По сути, просто нужно понимать где VIPER будет хорош, а где нет. Поэтому, в принципе, можно считать что оба поста: за VIPER и против — дополняют друг друга. :)

        0
        Я просто хотел восстановить равновесие)
        +1
        Размышления, описание- проблем есть. Ни примеров — ни выводов?????
          0
          Не могу не согласиться с автором.

          Только чувствую, как сейчас понабегут с криками, что автор адепт секты.

          Из данной статьи в очередной раз можно вынести, что не нужно читать подобные статьи на тему «оно плохое». Если интересно, разберись и для себя реши.
            0
            Из данной статьи в очередной раз можно вынести, что не нужно читать подобные статьи на тему «оно плохое».


            Это может привести к застою и слепому фанатизму. Я считаю, что нужно уметь слушать обе стороны и собирать как можно большее количество информации. Вопрос только в том как эту информацию обрабатывать и как воспринимать факты. А так же в каких ситуациях плюсы архитектуры вам помогают, а в каких ситуациях минусы сильно сыграют вам не на руку. Опять таки, не читая критику, очень сложно будет осознать недостатки и минуса того или иного подхода.

            Например то как я воспринимаю факт из этой статьи:
            Высокий порог вхождения — неопытные программисты не смогут с ней работать


            — Ага, понятно, у меня в команде 2 джуна и 2 мидла, значит скорее всего потратим много времени на тренинг джунов под новую архитектуру, а сроки проекта даже при стандартных подходах поставлены впритык — значит отметаем.

            Или же

            — Ага, нас тут 3 синьора и мы уже все давно поняли — значит можно пробывать или же писать дальше.

            +2
            Мне иногда кажется, что VIPER придумали ради холиваров. Я пока не видел другого такого архитектурного паттерна, про который везде спорят. Везде.
              0
              «Во-первых, Presenter хранит состояние всего модуля»
              А для чего тогда модель(ну или энтити, как она называется в вайпер)?
                +1
                Модель хранит данные. Состояние, если говорить просто, определяет что можно сделать с этими данными в текущий момент
                  0
                  Ну ок.
                  А при сериализации(ну например нужно сделать сейв) вы это состояние из пресентера куда сбрасываете?
                  Просто то, что вы описали — это не состояние а скорее логика смены состояний. Само состояние как раз таки хранится(ну по крайней мере должно) в модели.
                0
                Вы используете классический VIPER или немного модифицированную версию от Рамблера? Или между ними нет существенной разницы?
                  0
                  Я использую версию от Рамблер, но с незначительными изменениями, которые мы решили сделать в компании.
                  Между этими версиями есть разница — о ней писали в Рамблере. В основном, в компаниях видоизменяют архитектуру исходя из собственных взглядов и требований(например, в uber используют Riblets). В этом нет ничего плохого, так как основная задача — следовать принципам чистой архитектуры.
                  +1
                  Сам когда-то думал что VIPER это громоздко, ненужно и вообще просто «модно». После применения этой архитектуры в нескольких проектах я поменял своё мнение :)
                    0
                    Немного занудства:
                    Во-вторых, Presenter выступает в качестве Input и Output модуля. В-третьих, он не просто передает команды от View к Interactor и т.д., а принимает решения

                    Это же нарушает принцип Single Responsibility. Столько обязанностей у одной сущности.
                    Но на самом деле это неизбежно, должен же быть класс, который никак не переиспользовать при изменении требований.

                    Вопрос к знатокам VIPER:
                    Недавно делал одну функциональность для проекта на VIPER. Компонент представлял собой UITableView c двумя секциями с возможностью перетаскивания ячеек.
                    Для удобства разместил алгоритм перетаскивания в UITableViewDelegate непосредственно в слое View. Это допустимо или следовало бы прокидывать вызовы делегата до интерактора и обратно во View?

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое