Blog: ederson

Clean Architecture com MVVM em aplicações Android

A Clean Architecture foi idealizada por Robert C. Martin, autor de um livro abordando este tema, ajudou a criar uma arquitetura em que os componentes fossem desacoplados, testáveis e de fácil manutenção.

O que é a Clean Architecture? A Clean Architecture consiste em um diagrama de camadas, em que cada um dos seus componentes possuem suas próprias responsabilidades e cada uma delas tem conhecimento apenas de camadas de dentro, ou seja, a camada de “Frameworks e Drivers” enxerga somente a de “Interface Adapters”.

Image

Vantagens: O código é facilmente testável, se comparado a arquitetura MVVM simples; Componentes ainda mais desacoplados, a estrutura do pacote é facilmente de se navegar entre eles; Novas funcionalidades podem ser adicionadas rapidamente pelo time de desenvolvedores.

Desvantagens: Curva de aprendizado relativamente íngreme, considerando que todas as camadas funcionam juntas, exigindo um certo tempo para entender seus conceitos, principalmente desenvolvedores provenientes de padrões como MVVM e MVP simples; Pela arquitetura exigir o acréscimo de muitas classes adicionais, este modelo não é ideal para projetos de baixa complexidade. A intenção é de demonstrar as regras de dependência dentro da arquitetura.

Image

Cada camada de MVVM usando Clean Architecture no Android e os códigos se dividem em três camadas:

Camada de Apresentação (Presentation Layer):

Nesta camada, são incluídas as “Activity”s, “Fragment”s como sendo as “Views”, e as “ViewModel”s, devem ser mais simples e intuitivo possível e ainda, não devem ser incluídas regras de negócio nas “Activity”s e “Fragment”s.

Uma “View” irá se comunicar com sua respectiva “ViewModel”, e assim, a “ViewModel” se comunicará com a camada de domínio para que sejam executadas determinadas ações. Uma “ViewModel” nunca se comunicará diretamente com a camada de dados;

Camada de Domínio (Domain Layer):

Na camada de domínio, devem conter todos os casos de uso da aplicação. Os casos de uso tem como objetivo serem mediadores entre suas “ViewModel”s e os “Repository”s.

Caso for necessário adicionar uma nova funcionalidade, tudo o que deve ser feito é adicionar um novo caso de uso e todo seu respectivo código estará completamente separado e desacoplado dos outros casos de uso. A criação de um novo caso de uso é justamente para evitar que ao adicionar novas funcionalidades, quebrar as preexistentes no código;

Camada de Dados (Data Layer):

Esta camada possui todos os repositórios que a camada de domínio tem disponíveis para utilização e “DataSource”s, que são responsáveis por decidir qual a fonte em que devem ser recuperados os dados, sendo de uma base de dados local ou servidor remoto.

Arquitetura Android mvc x mvp x mvvm

Fixando o conhecimento basico em arquiteura Android, vou descrever os Patterns de arquitetura já utilizados:

  • MVC - Model View Controller
  • MVP - Model View Presenter
  • MVVM - Model View ViewModel

MVC

Image

Esta abordagem separa sua aplicação em um nível macro com 3 conjuntos de responsabilidades. Sendo eles:

Model No Model irá conter Data + State + Business Logic, de forma não técnica. Podemos usar como exemplo lógica comercial, acesso a dados e regra de negócios, que não está ligado a View ou Controller e com isto se torna muito reutilizável.

View Representa o Model, ela é a UI (user interface) e faz a comunicação com a Controller sempre que ocorre uma interação do usuário. Quanto menos eles souberem do que deve ser feito com a interação, mais flexíveis serão para mudar.

Controller Ele é o responsável pelo que acontece no aplicativo. Quando a View diz para o Controller que um usuário clicou em um botão, ele decide como interagir. Se ocorrer modificação de dados no Model, o Controller pode decidir atualizar o estado de exibição, quase sempre representado por uma activity ou fragment.

Desvantagens:

Testabilidade - O controlador está tão ligado às APIs do Android que é difícil testar a unidade. Modularidade e flexibilidade - Os Controllers estão bem acoplados às Views. Pode também ser uma extensão da View. Caso você mude a View, devemos voltar e mudar o Controller. Manutenção - Pode ocorrer de o código começar a ser transferido para os Controllers, tornando-os cheios, complexos e com grande facilidade de crashs.

MVP

Image

O MVP quebra o Controller de modo que o acoplamento de View/Activity pode ocorrer sem amarrá-lo ao restante das responsabilidades do “Controller”. Veremos mais sobre isso abaixo, mas comecemos novamente com uma definição comum de responsabilidades, em comparação com o MVC.

Model Igual ao MVC / Nenhuma mudança

View A única alteração aqui é que a Activity/Fragment agora é considerada parte da View. A boa prática é ter uma Activity implementando uma interface de exibição para que o Presenter tenha uma interface para codificar. Com isto é eliminado o acoplamento e permite testes unitários.

Presenter Este é o Controller do MVC, exceto por ele não estar vinculado ao View, apenas a uma interface, com isto ele não mais gerencia o tráfego de solicitações recebidas, como é feito no Controller.

Desvantagens:

Manutenção - Os Presenters, assim como os Controllers, são propensos a colecionar lógica comercial adicional, espalhados com o tempo. Podemos nos deparar com grandes Presenters difíceis de separar.

MVVM

Image

MVVM com o Data Binding tem como benefícios testes mais fáceis e modularidade, ao mesmo tempo que reduz a quantidade de código que temos que escrever para conectar o Model com a View. Este Pattern suporta ligação bidirecional entre View e ViewModel, com isto nos permite ter propagação automática de mudanças. Bem, vou explicar.

Model Igual ao MVC e MVP / Nenhuma mudança

View A View liga-se a variáveis ​Observable ​​e ações expostas pelo ViewModel de forma flexível.

ViewModel O ViewModel é responsável por expor métodos, comandos e propriedades que mantém o estado da View, assim como manipular a Model com resultados de ações da View e preparar dados Observable necessários para a exibição.

Desvantagens:

Manutenção - As Views podem se ligar (bind) a ambas as variáveis ​​e expressões, adicionando código efetivamente ao XML. O ideal é obter valores diretamente do ViewModel em vez de tentar calcular utilizando no XML.

Ciclo OODA na arte da guerra dos negócios rápidos

Estratégia é uma das disciplinas que deveria ter grande importância para nossa vida, ouso dizer que deveria ser ensinada nas escolas. Uma boa estratégia tem grande valor, basta observar sua ampla discussão no livro a Arte da Guerra, de Sun Tzu.

Pensando nisso, John Boyd, Coronel da Força Aérea Norte Americana nascido em 1927 desenvolveu um modelo para a tomada de decisão no combate aéreo, e sua potencial utilização ao mundo dos negócios tornou-se evidente. Sua história é um fato a parte e pode ser pesquisada para entender melhor seu objetivo, mas podemos resumir no que chamamos de ciclo OODA.

O Ciclo OODA é um modelo baseado em um ciclo de quatro pontos que apoia uma tomada de decisão rápida e eficaz.

Observar, Orientar, Decidir e Agir

Qual a diferença entre o OODA e o PDCA?

O Ciclo do PDCA(ou ciclo de Deming) é uma abordagem analítica que pode ser usada de maneira interna. Dependendo do processo que estamos tentando melhorar, não é necessário consultar o ambiente externo ou realizar qualquer ajuste para que o ciclo do PDCA funcione.

O PDCA tem grande sucesso em chão de fábrica. Envolve o uso de um conjunto de dados para chegar a uma conclusão. Utilizamos os dados para tomar uma decisão sobre como proceder, nós verificamos e agimos para confirmar ou rejeitar a possibilidade analisada.

O Ciclo OODA tem maior foco em sintetizar uma ação em um conjunto de dados, mesmo que incompletos, para tomar uma decisão rápida e efetiva.

Mas o ciclo OODA peca no aspecto da Qualidade e dos testes que não são as prioridades no topo das suas entregas, já que a visão é rapidez. Porque para acelerar o seu ciclo OODA, é preciso terminar os projetos mais rapidamente. O que leva o tempo de ciclo para o topo da lista de prioridades do gerenciamento de projetos.

Assim como a capacidade de "agir" nem sempre é simples o suficiente para ser um requisito atendido por um único projeto. Mesmo falando de ágil.

Mas poderia ser bem empregada com o uso de metodologias como a 6sigma, onde o PDCA também é usado.

Matriz swot o que e e como usar

SWOT a sigla dos termos ingleses Strengths (Forças), Weaknesses (Fraquezas), Opportunities (Oportunidades) e Threats (Ameaças) que consiste em uma  ferramenta de análise  bastante popular no âmbito empresarial.

Análise SWOT é uma ferramenta utilizada para fazer análise ambiental, sendo a base da gestão e do planejamento estratégico numa empresa ou instituição, recolhendo dados importantes que caracterizam o ambiente interno(forças e fraquezas) e externo (oportunidades e ameaças) da empresa.

Graças à sua simplicidade pode ser utilizada para qualquer tipo de análise de cenário, desde a criação de um blog à gestão de uma multinacional.

A técnica de análise SWOT foi elaborada pelo norte-americano Albert Humphrey, durante o desenvolvimento de um projeto de pesquisa na Universidade de Stanford entre  1960 e 1970, usando dados da Fortune 500, uma revista que compõe um ranking das maiores empresas americanas.

As informações referidas abaixo devem ser enquadradas nas categorias SWOT para análise do cenário da empresa:

Ler mais…

Scrum of Scrums

Você já deve ter ouvido falar em Scrum of Scrums (SoS) , que nada mais é que uma importante técnica para escalar Scrum em grande times e projetos.  Trabalhada em reuniões que permitem agrupar os times para discutir seus trabalhos, focando especialmente em área de sobreposição e integração.

Definição Uma técnica para escalar Scrum em grupos grandes (mais de 6 pessoas), consistindo em dividir os grupos em equipes Agile de 5-10. Cada Daily dentro de uma sub-equipe termina designando um membro como embaixador para participar de uma reunião diária com embaixadores de outras equipes, chamado Scrum of Scrums. Dependendo do contexto, os embaixadores podem ser contribuidores técnicos, ou Scrum Master de cada equipe, ou gerentes de cada equipe.

O Scrum of Scrums transcorre como uma reunião diária normal, com os embaixadores que informam as conclusões, as próximas etapas e impedimentos em nome das equipes que representam. Espera-se que a resolução de impedimentos se centre nos desafios da coordenação entre as equipes; As soluções podem implicar concordar com interfaces entre equipes, negociar limites de responsabilidade, ...

O Scrum of Scrum realiza seu acompanhamento dos itens através de um backlog próprio, onde cada item contribui para melhorar a coordenação entre equipes.

Lendo diversos artigos para buscar entender limitações e pontos onde a aplicação venha a aparesentar baixa performance ou qualquer entrave, cheguei a Allan Shalloway, que preve alguns problemas em praticar Scrum com grupos grandes (350 pessoas ou mais). Neste caso há vários diferentes produtos sendo construídos com componentes compartilhados.

Ele cita 3 exemplos de problemas que ocorreram:

  • Nível Técnico. Dado que estávamos fazendo desenvolvimento iterativo, os times esperam seguir princípios de design emergente. Isso significa que estamos escrevendo código de qualidade, mas não adicionamos funcionalidade ou design até que eles sejam necessários.
  • Nível Inter Times. A forma como os times trabalham juntos quando há diferentes Product Owners e Scrum Masters para cada time, nem sempre é tão óbvia. Mais uma vez, uma visão mais abrangente ajuda. Isso é especialmente verdade quando há um time de componentes fazendo trabalho de suporte para vários outros times. Orientar-se através de business value requer olhar através dos product owners. Eles podem cooperar, porém, mais uma vez, eles podem não cooperar.
  • Nível de Estrutura do Time. Muitos times scrum trabalhando juntos tem problemas sérios para entregar uma funcionalidade final quando muitos times estão envolvidos.

Já Mike Dwyer diz preferir o SoS e Meta Scrums: para coordenar a decomposição de estórias, de forma que assim você não termina com a mesma coisa construída por vários times. Aquelas coisas devem ser trabalhadas através de conversas diárias e frequentes que ocorrem em todos os níveis.

Em sua experiência, times bem conduzidos focam na infraestrutura, dados e arquitetura para fazer um bom trabalho de reunir código compartilhado. O que mais acabaremos encontrando como receita para o sucesso da reunião Scrum of Scrums será o que todos já devemos ter em mente: **Manter a reunião curta. 15 minutos no máximo. Mantenha-a focada. O que os outros querem/precisam ouvir? Discussões devem ser reservadas para uma reunião separada para manter a reunião curta e focada. Traga os problemas que bloqueiam para cada reunião SoS até que sejam resolvidos.