MVA — Quando Menos é Mais

Foto por danist07 em unsplash.com

Desde que comecei a programar profissionalmente, 7 anos atrás, arquitetura sempre foi um dos assuntos que mais me chamaram a atenção. Até hoje me instiga a ler, pesquisar, experimentar e aprender muito com tudo isso.

Quando fiz a migração definitiva do Java backend para o Android, uma das coisas que mais me chamou a atenção é que tudo estava ainda sendo desenvolvido (desde as ferramentas e IDEs, até as próprias ideias sobre organização do código em si). A arquitetura do próprio Android não chega a ser um primor, e muita gente vem trabalhando em melhores formas de se organizar um app sem tornar a tarefa da manutenção um trabalho árduo e desgastante.

Nessa vertente, duas abordagens surgiram há algum tempo e ganharam força nos últimos tempos: a MVP e a Clean Architecture. Não vou abordar conceitualmente as duas arquiteturas aqui, pois são assuntos que valem (mais de) um post inteiro cada. Inclusive, falei sobre várias abordagens e opiniões no Android Dev Conference 2015, e o Medium do Android Dev BR já teve posts sobre elas também (MVC/MVP e Clean Architecture).

Em ambas as abordagens, criam-se camadas para aumentar a abstração e facilitar o isolamento de cada uma das partes do sistema, de acordo com suas responsabilidades. A separação em si melhora a capacidade de se testar as partes de forma isolada, pois o uso de interfaces é bastante comum, facilitando o mock para os testes, permitindo-se testar fluxos inteiros em alguns casos utilizando apenas testes unitários.

É aí que o negócio começou a me incomodar. Principalmente na abordagem da Clean Architecture, mesmo uma funcionalidade simples exige a criação de várias camadas e classes, adicionando uma camada de burocratização na aplicação. Não estou dizendo que ela não traga nenhum benefício, mas esse problema me incomoda e muito nos projetos que vejo utilizando esta arquitetura.

O MVP sofre menos com esse problema, mas ainda exige a criação de uma série de interfaces com as abstrações de cada uma das camadas, com a justificativa de melhorar a testabilidade do sistema. O meu problema principal neste caso é a completa ausência de testes (e testes relevantes) nas mais diversas implementações do padrão que já encontrei. Se as abstrações são a troca a ser realizada para que se tenha uma aplicação testável, por que o objetivo não está aparecendo no final?

Ainda relacionado ao MVP, um paradigma criado pensando-se no ambiente da Web que surgiu com força por volta de 2007, alguns dos benefícios não se aplicam tanto ao Android, como a possibilidade de troca transparente da implementação de View (trocar uma implementação de Activity por Fragment não chega a ser um problema em qualquer que seja a arquitetura implementada), ou mesmo a troca dos modelos por mocks para propósitos de demonstração ou testes — é possível implementar cenários como o “development drawer” de forma agnóstica.

Conversando com algumas pessoas e vendo alguns projetos sendo desenvolvidos, vi que muitas vezes as arquiteturas são implementadas sem entender os conceitos, simplesmente reproduzindo o que foi visto em algum outro projeto. Muitas vezes faltam conceitos, mas principalmente um pouco de questionamento: preciso de tudo isso?

No meio de tantos Ms e Vs, acabei me deparando com o MVA — o Minimum Viable Architecture. Uma das frases que definem o MVA diz que:

O melhor código que você pode escrever agora é o código que você irá jogar fora em alguns anos.

Apesar de ser um conceito voltado muito mais para o desenvolvimento de produtos do que programação em si, ele traz conceitos que servem para questionarmos um pouco a forma como desenvolvemos os nossos apps hoje.

  • A arquitetura não é construída pensando nos piores cenários. Em vez disso, o produto é construído pensando nos cenários mais comuns.
  • Escreva código em pequenos incrementos através do tempo. Para que isso aconteça, as definições principais de requisitos e tecnologias já devem ter sido definidas.
  • Tudo que é desenvolvido deve ser baseado em requisitos concretos ou pelo menos razoáveis, não sobre achismos ou deduções.

Entendam estes conceitos como uma forma de implementações mais objetivas. Isso não quer dizer que a qualidade e organização deve ser deixada de lado. Nem que os testes devem ser ignorados nem que a aplicação não deve ter uma arquitetura e padrões definidos. Mas pensem e questionem sobre o que está sendo feito. A troca está valendo a pena? Quais objetivos estão sendo buscados com isso?

Enfim, essa é uma grande e excelente conversa, que só estou começando aqui. O Android está evoluindo e a nossa forma de pensar a respeito das nossas aplicações também deve evoluir. Não sou contra os vários MVs, mas o questionamento faz-se necessário.

E você, o que acha? Vamos conversar sobre arquitetura? :)