Porque decidimos usar o VIPER na XP Inc.
Quando entrei na XP em 2018, tínhamos como objetivo estruturar uma área de mobile do zero. Tínhamos o sonho grande de ser o maior aplicativo de investimentos do Brasil, e para tornar esse sonho realidade, era necessário pensar em uma arquitetura robusta e escalável, que pudesse suportar nosso crescimento e no futuro permitir que fosse possível modularizar e continuar com um desenvolvimento mais eficiente em nosso app
Na mesma época, muitos desenvolvedores que faziam parte da comunidade do iOS, mais conhecida como Cocoaheads, a cada evento realizado tinha alguma talk falando sobre arquitetura de software e VIPER, foi ai então que decidimos estudar ela mais a fundo.
VIPER, para quem não sabe, é uma abordagem para desenvolvimento de aplicação com base na arquitetura limpa (a Clean Architecture) especialmente para o iOS. A Clean Architecture, de forma bem resumida, divide nosso software em camadas. Seu objetivo é separar a estrutura de lógica da aplicação em diversos caminhos de responsabilidade.
De uma forma mais resumida, podemos destacar cada área da seguinte forma:
View: responsável por receber as entradas do usuário e redirecionar a quem sabe de fato lidar com ela, o seu Presenter. A View conceitualmente conhece seu único Presenter.
Presenter: o Presenter não sabe lidar com todo tipo de requisições. Algumas ele de fato vai dar conta de processar por si só, mas outras ele apenas sabe a quem enviar a depender do comando recebido. Essa camada tem conhecimento de quem é sua View, pois ele precisa atualizá-la. Essa camada também conhece a camada de Router e Interactor.
Router: é responsável por manter as funções de trocas de telas e troca de dados entre elas.
Interactor: é a camada responsável por fazer chamadas a fontes de dados, como banco de dados ou API externas. Essa camada conhece a Entity e faz uso da mesma para montar a resposta das requisições.
Entity: camada que contém a estrutura dos dados a ser utilizado na aplicação.
É interessante observar que aqui existe uma liberdade para escolher a forma de isolamento entre as camadas, que pode ser feita sem maiores dificuldades através de protocolos ou observer, porem na XP optamos por usar protocolos
Porem nem tudo são flores, e nenhuma arquitetura pode ser usada como bala de prata, então, mesmo entendendo melhor como o VIPER funciona, buscamos ver suas limitações e benefícios que eram mais comentados na época.
Pontos fracos
- Necessidade de escrever mais código (muito boilerplate)
- Curva de aprendizado média para alta, até aquela época não tinha muito material, e cada material trazia alguma visão um pouco diferente.
Pontos fortes
- Possibilidade de reuso
- Maior facilidade para testes unitários
- Separação de código em camadas, com single responsibility
Hoje, quatro anos depois, com dezenas de desenvolvedores, seguimos firme nessa arquitetura, trazendo pequenas melhorias para o nosso dia a dia. Além das camadas citadas acima, hoje utilizamos:
- Configurator que fica com a responsabilidade de fazer o setup do nosso módulo, e cuidar de toda injeção de dependência necessária.
- EventTracker, dados fazem parte do nosso dia a dia, então tínhamos que ter uma forma clara de manipular e enviar qualquer interação do usuário.
Caso, você tenha ficado interessado em nosso template, da uma conferida no meu GitHub, vou deixar um exemplo prático, e de quebra um script de instalação para o Xcode.
Quer se juntar ao nosso time? Estamos contratando
