A importância das arquiteturas modulares em aplicativos móveis

Importância da arquitetura técnica no desenvolvimento de apps móveis

Quando se desenvolve um aplicativo móvel é importante planejar bem sua arquitetura técnica desde o início. Frequentemente, muitas empresas costumam se concentrar apenas em aspectos como a experiência do usuário, a usabilidade ou o design, mas costumam deixar de lado a qualidade do código ou conceitos como manutenibilidade e escalabilidade, entre outros.

O resultado é um aplicativo que inicialmente atende às expectativas tanto da própria empresa quanto dos usuários finais, mas que a longo prazo se torna algo difícil de manter, difícil de expandir com novas funcionalidades e um projeto no qual ninguém quer trabalhar. Neste artigo, vamos tentar analisar essas situações e como tentar evitá-las.

O que é a arquitetura de um aplicativo móvel?

Uma arquitetura é um conjunto de elementos e decisões que definem como deve ser (e evoluir) a estrutura interna do código de uma aplicação. Este conceito não é específico das aplicações móveis, mas está presente há muitos anos em muitos projetos de software de qualquer tecnologia.

No caso específico dos aplicativos para iOS e Android, uma arquitetura é a forma como são estruturadas as diferentes vistas, o código associado a elas, os recursos gráficos, a lógica de negócios, os modelos de dados, a comunicação com serviços e bancos de dados e a persistência de dados, entre outros. Também descreve como os diferentes elementos que fazem parte da estrutura de um aplicativo devem comunicar-se.

É bastante comum que nos aplicativos móveis não se leve tanto em conta o design técnico, mas sim outros aspectos. É importante não ignorar como uma arquitetura modular pode beneficiar um aplicativo móvel se o projeto for de tamanho médio. No caso de aplicativos menores, o uso desse tipo de arquiteturas seria considerado superengenharia.

Por que é importante considerar a arquitetura desde o início?

Para entendê-lo, o melhor é utilizar um exemplo do dia a dia: imaginemos que você acabou de adquirir um terreno e quer construir uma casa nele. Hoje em dia há uma grande variedade de opções: casas pré-fabricadas, por módulos, construção tradicional, etc.

Quando alguém decide construir uma casa ou comprar uma que já esteja pronta, presta atenção a vários aspectos, como: tipo de materiais que serão utilizados, qualidade dos mesmos, custo que representam para o conjunto da obra, durabilidade e outros temas de maior ou menor interesse.

Segundo as escolhas que fizermos, a casa que construirmos será uma casa de luxo ou uma casa normal, durará 10 anos ou durará 200, etc. Não significa que uma seja melhor que a outra, mas devemos levar em conta a quantidade de anos que queremos viver nela ou se pretendemos renová-la completamente com o passar do tempo. Precisamos garantir que o projeto atenda às nossas expectativas.

Se apenas nos concentrarmos em que fique bonita e seja funcional, mas não levarmos em conta elementos-chave como os alicerces, a qualidade das paredes e outros, certamente teremos problemas graves à medida que passarmos tempo vivendo nessa casa: umidade, ruídos do exterior, goteiras... e uma infinidade de problemas.

Você consegue imaginar uma casa onde o vaso sanitário esteja na cozinha e o banheiro tenha um forno? Com certeza você não moraria nessa casa ou, no mínimo, não poderia chamá-la de lar. Mas com um código, não somos capazes de ver essas coisas se não tivermos conhecimento técnico; provavelmente no seu aplicativo você tenha um forno no banheiro.

Podemos ter um aplicativo que seja bonito e funcional para seu lançamento, mas por dentro o código pode não ser ótimo e ter muitas funcionalidades acopladas. Nesse cenário, estender esse mesmo código com novas funções ou mantê-lo e buscar seus erros para corrigi-los se torna cada vez mais uma tarefa difícil. Seguindo o exemplo anterior, realocar o vaso sanitário no banheiro e o forno na cozinha não é tão simples quanto mover os elementos de lugar, mas requer mudar grande parte da instalação.

É um fator que não só impacta o projeto, mas também a rotatividade do pessoal técnico.

O impacto da rotatividade nos projetos

Que as arquiteturas não sejam bem pensadas desde o início não só provoca problemas para os desenvolvedores, mas também para as próprias empresas. Quando um projeto não foi bem planejado desde o início e se pede a alguém que continue estendendo seu funcionamento, no final acaba gerando frustração porque as coisas vão cada vez pior. É muito difícil estruturar algo que inicialmente já estava mal planejado, por muitas horas que se dediquem a refatorar código e a reescrever certas partes.

Essa frustração geralmente acaba em problemas entre membros da equipe (normalmente entre pessoas técnicas e não técnicas), pela incapacidade de transmitir e fazer entender aos stakeholders que a arquitetura da aplicação não foi bem planejada desde o início. No final, como tudo na vida quando algo não funciona, acaba se rompendo completamente e as pessoas acabam indo embora. Cada vez que uma pessoa da equipe sai, não só vai embora um recurso, mas também todo o conhecimento e a experiência dessa pessoa.

É comum pensar que com uma pessoa mais sênior ou com mais experiência resolveremos o problema, pois ela reescreverá partes do código que não estão boas e assim não haverá frustração. Mas normalmente se consegue o efeito contrário: quanto mais experiência tem um profissional, mais facilmente ele percebe os problemas estruturais de uma aplicação e provavelmente acabará abandonando o barco antes de um perfil mais júnior, que levará mais tempo para perceber a situação.

É um peixe que morde o próprio rabo, enquanto os usuários finais continuam esperando atualizações com novas funções e correções de erros que nunca chegam.

O que podemos fazer para melhorar essas situações?

A única solução possível é reescrever totalmente a aplicação, mas mudando o processo. Se você não considerou o design técnico quando o projeto começou, é hora de fazê-lo se decidir começar do zero. Se tentar reescrever partes ou corrigir alguns pequenos defeitos, a base do problema sempre estará lá. É como tentar resolver um problema de convivência sem que ambas as partes reconheçam seus erros com sinceridade, ele voltará a surgir com o tempo.

Hoje em dia há uma tendência em alta: as arquiteturas modulares. Elas não são uma moda passageira, pois as arquiteturas modulares vêm para resolver dois problemas principais: a manutenibilidade e a escalabilidade. Vamos ver como elas fazem isso.

O que é uma arquitetura modular?

Uma arquitetura modular é aquela que permite dividir uma aplicação em vários módulos. Um módulo é um subconjunto de uma aplicação que possui:

• Uma responsabilidade única, apenas uma
• Um comportamento funcional determinado e nenhum outro
• A capacidade de se comunicar com outros módulos, mas sem conhecê-los completamente
• A capacidade de mudar seu interior sem afetar o exterior

Esse tipo de arquitetura utiliza uma técnica chamada dividir para conquistar, que consiste em dividir um problema muito grande (uma grande aplicação) em fragmentos muito pequenos e específicos. Dessa forma, cada vez que se faz um desses módulos é como começar um projeto do zero: se algo não funcionar bem, você pode refazê-lo.

A principal diferença com uma arquitetura tradicional é que os diferentes módulos podem ser usados e se comunicar entre si, mas não devem se conhecer. Dessa forma, é relativamente fácil trocar uma peça que não funciona por outra, já que as outras peças saberão se comunicar com a nova imediatamente. A nível técnico, a descrição dessa arquitetura diz que ela segue os princípios SOLID, dos quais você certamente já ouviu falar anteriormente.

Vantagens e Desvantagens das Arquiteturas Modulares

Como tudo na vida, as arquiteturas modulares têm vantagens, mas também desvantagens. Vamos ver quais são:

Vantagens mais relevantes

• Permitem refazer partes que não funcionam sem afetar o restante.
• Permitem paralelizar mais o desenvolvimento uma vez que a base técnica está estabelecida.
• Facilitam a manutenção ao estar dividida em peças menores e menos complexas.
• Melhoram a felicidade da equipe a longo prazo, pois não geram tanta frustração.
• Permitem adaptar-se rapidamente a novas funcionalidades dos sistemas operacionais (por exemplo, os “App Clips” recentemente anunciados pela Apple).

Desvantagens mais relevantes

• Requerem um maior esforço inicial: o investimento econômico necessário em comparação com uma arquitetura tradicional é bastante mais elevado. Principalmente porque são necessários perfis com muita experiência e deve-se dedicar muito tempo a escrever documentação técnica e a realizar análises técnicas complexas que ofereçam soluções para as necessidades de negócios a longo prazo.
• Requerem uma monitorização constante: para evitar que o planejamento inicial se distorça, é fundamental monitorar periodicamente o estado do código, garantir que as diretrizes estabelecidas sejam cumpridas, etc. As equipes que costumam realizar essas tarefas são geralmente chamadas de escritórios técnicos. Não é necessário que sejam formadas por muitas pessoas, mas é estritamente necessário que existam.