Когда я прочитал статью, в которой автор рассказал про то, что архитектура VIPER полна проблем, это вызвало у меня несколько негативные эмоции, после чего я сразу решил написать статью в поддержку архитектуры.
VIPER, подобно современным блогерам, собрала вокруг себя достаточно много хайпа. У неё появились как хейтеры, так и люди, свято верующие в идеальность этой архитектуры. Хейтеры VIPER породили множество заблуждений разного характера. Вот некоторые из них:
Не могу похвастаться большим числом проектов, написанных мной с использованием VIPER, но всё же они есть. И, исходя из своего опыта, могу сказать, что на все эти заблуждения есть вполне логичные ответы.
Начнём с того, что в архитектуре много классов и протоколов не просто так. Это необходимо для обеспечения слабой связности и высокого зацепления, которые вместе делают код понятным, легко поддерживаемым, переиспользуемым и устойчивым ко внешним изменениям. Это облегчает работу над проектом, причем не важно — командная это разработка или нет. VIPER, благодаря соблюдению этих принципов, позволяет легко менять части модуля, тем самым обеспечивая быстрое реагирование на изменение дизайна или требований.
Теперь про порог вхождения. Он действительно «большой», но только для новичка. Не скрою — я и сам не сразу разобрался как написать VIPER модуль, но и опыта разработки в то время у меня было всего несколько месяцев. А, когда мы в компании первый раз решили использовать VIPER, моим коллегам было достаточно одного code review готового модуля чтобы написать свой. Так что архитектура совсем несложная, сложно заставить себя в ней разобраться.
На первый взгляд кажется, что все в VIPER понятно — View отображает, Interactor предоставляет, Router переходит, а Presenter связывает. Но это только верхушка айсберга. Когда начинаешь писать первый модуль, то часто не можешь понять — где писать определенный код. И многие программисты основываются на чужих решениях, которые могут решать одну проблему по-разному. И программисты начинают говорить про то, что VIPER — это плохо. Мне кажется, что тут дело не в VIPER, а в тех самых примерах, которые смотрят люди. Какова вероятность, что человек хорошо разобрался в архитектуре перед тем как выложить свой код? Столько же сколько и вероятность встретить динозавра на улице — 50%. Поэтому прежде всего надо думать своей головой и тогда всё встанет на свои места. На самом деле в VIPER очень чётко разделены обязанности между компонентами модуля. И, если Вы не знаете куда отнести какую-то вещь, то просто перечитайте ещё раз про VIPER или посмотрите книгу Rambler&Co.
Бытует мнение, что Presenter выполняет роль посредника между View и Interactor, и что этот компонент лишний в VIPER модуле. Тут я скажу, наверно, очевидные вещи, но всё же. Во-первых, Presenter хранит состояние всего модуля. Во-вторых, Presenter выступает в качестве Input и Output модуля. В-третьих, он не просто передает команды от View к Interactor и т.д., а принимает решения — в каком случае что именно надо сделать, а это уже не совсем посредничество.
И последнее — зачем же нам 99% покрытие кода тестами, которое обеспечивает VIPER? На первый взгляд ответ на вопрос лежит на поверхности — затем, чтобы быть уверенным в корректной работе приложения. Но тут дело, скорее всего, не в цифре, а в самом факте того, что VIPER это позволяет. И позволяет сделать достаточно легко в отличии от некоторых других архитектур. И при разработке любых по сложности проектов это является огромным плюсом.
Да, у VIPER есть свои недостатки (нет ничего идеального), но не стоит ей пренебрегать. Но и не стоит использовать её во всех проектах подряд. Всё-таки архитектура приложения выбирается исходя из множества различных факторов и требований, а не только из-за фанатизма. И, прежде чем говорить что она плохая или хорошая, стоит написать на ней 2-3 приложения, чтобы всё как следует взвесить.
Надеюсь, я не превысил количество слова 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 на квадратный сантиметр.
Спасибо за прочтение!