Salve galera! Tudo bem?

Nos últimos dias estive pensando bastante sobre arquitetura de software, padrões de desenvolvimento, soluções que acabam ficando complexas de manter por conta de overengineering e outros problemas do dia-a-dia que encontro no meu trabalho.

Vários projetos em que trabalhei, tiveram padrões que se perderam no decorrer do tempo e outros que geraram uma sobrecarga de tecnologias e padrões que tornaram estes mais complexos para serem mantidos, mesmo que por pessoas mais experientes e com tempo de casa.

Por conta disso, resolvi iniciar uma série de artigos, cobrindo além de uma visão da responsabilidade de um arquiteto de software e como sua atuação pode afetar a qualidade de entrega, além de abordar os padrões de desenvolvimento mais utilizados e boas práticas. Não irei abordar todos, pois caso contrário seria um livro, não uma série de artigos, o conteúdo é bem extenso...

Na lista de patterns, abaixo de cada um dos já lançados, coloquei o link direto, tornando esta primeira parte um índice para cada um dos design patterns, além uma introdução sobre o papel do arquiteto e a importância da arquitetura de software para desenvolvedores.

Arquitetura

Antes de mais nada, o que é arquitetura de software? Não, não é um conjunto de técnicas para Minecraft… Apesar de eu gostar muito do jogo :)

Tela do Minecraft, “arquitetando” e construindo cidades

Vários autores já deram definições diferentes para arquitetura de software, como:

“o conceito de mais alto nível de um sistema em seu ambiente […] a organização ou estrutura de componentes significantes interagindo através de interfaces de modo que estes componentes mais importantes são compostos de componentes e interfaces sucessivamente menores”. “Parte do sistemas que são difíceis de se modificar” — Martin Fowler

Se buscarmos outros autores ou fontes de informação, teremos mais conceitos, mas todos eles acabam convergindo para um ponto em comum, que resumo como:

Alguém que define e acompanha a evolução do software, tanto tecnicamente como a nível de processo. Um arquiteto que se preocupa apenas com a parte técnica do projeto, não está ligado ao mesmo como um todo, e vai falhar.

O processo de desenvolvimento de software tem como principal analogia uma esteira de fábrica, onde as peças vem passando, cada um faz sua parte e no final algo é entregue para o cliente, sempre seguindo o mesmo processo. Algo errado? Com certeza, a esteira está sempre produzindo, mas de forma igual a de ontem, sempre repetindo… Software é algo que muda, evolui em algumas horas apenas…

Cito aqui uma frase que o MVP Ramon Durães sempre usa em suas palestras e vídeos:

A fórmula de ontem não funciona mais hoje…  -  Ramon Durães

As variáveis mudam, e de forma rápida… a fórmula desenvolvida hoje pela manhã pode já não ser mais válida ao fim do dia inclusive. E não me refiro somente a tecnologia, mas processos, experiênciao usuário está ficando mais exigente a cada dia.

Acredite… software como entregávamos anos atrás, aquele projeto de 1 ano ou mais que somente sofria mudanças em casos de bugs, todo procedural e cheio de formulários, já não vende mais, está em extinção! Assim como aquele arquiteto que apenas define padrões, coloca os mesmos em uma intranet e apenas responde alguns e-mails também…

Algo que já se consolidou em projetos fora do país (principalmente em startups) e agora está cada vez mais forte aqui no brasil, é que a responsabilidade de toda a arquitetura está em toda a equipe. O arquiteto é um profissional de grande experiência, seria um degrau acima de um engenheiro de software sênior, mas não é o único responsável pela tecnologia do projeto, ele também em alguns casos é o responsável por estar “prestando contas” para o projeto. Uma pergunta comum para os que veem esse modelo é: onde estão os gerentes? A verdadeira pergunta é: “Mas para que eles realmente servem?”. Uma equipe madura não apenas sabe gerenciar seu tempo e tarefas sem um gerente, mas também acompanhar e discutir a evolução dos seus produtos, seja em caráter técnico ou de negócios. O arquiteto é apenas como um líder que ajuda a organizar e guiar a equipe, mas ela deve poder caminhar de forma independente e sem distorcer seus objetivos e processos, mas sim, evoluir eles de forma adequada e estratégica.

Toda a equipe pode e deve opinar na arquitetura e evolução do software.

Resumindo, antes que tomemos um rumo totalmente fora dos objetivos do artigo, Arquitetura de software, na minha visão, consiste em definir os componentes de um software, sua comunicação e comportamento com outros softwares e seu ambiente. Algo que deve ser feito por toda a equipe, sendo que normalmente temos na figura do arquiteto alguém responsável por “prestar contas” sobre os padrões e evolução da solução, assim como facilitar a comunicação entre times e sistemas, para que a solução evolua de forma simples e agregue valor para a empresa e seus clientes.

Iniciei o artigo com essa reflexão, pois de nada vale estudarmos todos os padrões de desenvolvimento sendo que a equipe não conversa, não age como um time onde todos são responsáveis pela definição e evolução da arquitetura, pela qualidade, pela entrega dos projetos…

Agora que colocamos alguns pingos em alguns I’s, vamos aos padrões de desenvolvimento.

Padrões de desenvolvimento

Existem diversos padrões de desenvolvimento, que são técnicas / formas de organizar nosso código / ambiente, nos ajudando a desenvolver software com agilidade, qualidade e que torne o mesmo fácil de manter e evoluir com o passar do tempo. Normalmente vemos eles em artigos e livros pelo seu nome em inglês: Design Patterns.

A forma como utilizamos ou combinamos esses padrões é definida de acordo com o tipo de solução que vamos trabalhar, quais os requisitos, ambiente, experiência desejada, verba disponível para o projeto… Diversos fatores que afetam o como desenvolvemos software.

Alguns padrões possuem regras e recomendações mais rígidas enquanto outros não. Não existe receita mágica que vai resolver todos os problemas, por isso a necessidade de um desenvolvedor e um arquiteto experientes, que já tenham vivido situações diversas em projetos, para poder ajudar a equipe a superar desafios, que estes já tenham vivido, ou algo próximo, e para que passem adiante essa experiência, esse conhecimento, formando novos líderes experientes.

Como dito antes, o arquiteto deve acompanhar de perto os projetos no qual está envolvido, não apenas fazer um documento ou arquétipo em um repositório padrão e os desenvolvedores da empresa, principalmente os mais novos, que ainda tem um caminho longo pela frente, terem que adivinhar como evoluir aquilo sem um guia. Todos devem participar e definir a evolução do software, mas os mais experientes, principalmente um arquiteto, irá saber conduzir a equipe para o caminho correto.

Padrões GoF (Gang of Four)

Livro dos padrões GoF

De acordo com o livro “Padrões de Projeto: Soluções reutilizáveis de software orientado a objetos”, os padrões “GoF” são divididos em 3 tipos.

Mas o que é GoF? Em 1995 um grupo de pessoas, mas especificamente quatro, escreveram um livro iniciando os Design Patterns mais conhecidos no mercado: Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides. Eles foram conhecidos como Gang of Four, ou GoF.

Existem outros inúmeros padrões de desenvolvimento além do livro, somando mais de 125 padrões diferentes. Mas, de agora em diante nesta série de artigos, iremos abordar os 23 padrões definidos pelo GoF. Os padrões segundo o GoF, possuem o seguinte formato:

  • Nome: Uma identificação para o padrão;
  • Objetivo / intenção: Também conhecido como (a.k.a);
  • Motivação: Um cenário ou situação mostrando um problema a ser resolvido;
  • Aplicabilidade: Como identificar cenários onde esse padrão é aplicável.
  • Estrutura: Uma representação gráfica da estrutura de classes do padrão, utilizando um diagrama de classes (UML), por exemplo;
  • Consequências: Quais as vantagens e desvantagens que teremos ao aplicar o padrão;
  • Implementações: Quais detalhes devemos nos preocupar quando implementamos o padrão, inclusive para cada linguagem a qual se aplica.
  • Usos conhecidos;
  • Padrões relacionados: Outros padrões que são semelhantes ou que podem ser utilizados em conjunto deste para a solução do problema;

Dada a estrutura, que iremos utilizar para apresentar os padrões, temos 23 definidos pelo GoF, que foram classificados em 3 famílias:

Padrões de criação

Abstract Factory

Arquitetura e desenvolvimento de software — Parte 2 — Abstract Factory
Nestas próximas partes, vamos analisar no detalhe cada um dos 23 padrões, suas propostas, quando aplicar, quando não aplicar, vantagens de desvantagens de cada um. Vamos começar com o primeiro da lista que apresentei, o Abstract Factory.

Factory Method

Arquitetura e desenvolvimento de software — Parte 3 — Factory Method
Continuando nossa viagem através dos 23 portais interdimensionais… Ops, filme errado… Digo, através dos 23 Design Patterns definidos pelo GoF, vamos abordar o próximo da lista, Factory Method.

Builder

Arquitetura e desenvolvimento de software — Parte 4— Builder
Continuando nossa série de artigos sobre os 23 Design Patterns do GoF, vamos abordar nesta parte o pattern Builder.

Prototype

Arquitetura e desenvolvimento de software — Parte 5 — Prototype
Salve galera!! Continuando, já foram 4, restam 19 + extras! Hoje vamos abordar o pattern Prototype, vamos lá!

Singleton

Arquitetura e desenvolvimento de software — Parte 6 — Singleton
Continuando nossa série sobre design patterns, vamos ao último da lista de criacionais, o Singleton. Vamos lá?

Padrões estruturais

Adapter

Arquitetura e desenvolvimento de software — Parte 7 — Adapter
Hoje vamos abordar o primeiro do grupo de padrões estruturais, o Adapter.

Composite

Arquitetura e desenvolvimento de software — Parte 9 — Bridge
Hoje vamos abordar o pattern Bridge, seus conceitos, usos e exemplos. Vamos lá!

Bridge

Arquitetura e desenvolvimento de software — Parte 10 — Decorator
Retomando, hoje vamos abordar o pattern Decorator!

Decorator

Arquitetura e desenvolvimento de software — Parte 10 — Decorator
Retomando, hoje vamos abordar o pattern Decorator!

Flyweight

Arquitetura e Desenvolvimento de software — Parte 11 — Flyweight
Retomando nossos estudos sobre design patterns, hoje vamos abordar o pattern Flyweight!

Facade

Arquitetura e Desenvolvimento de software — Parte 12 — Facade
Voltando a ativa, vamos ao primeiro post de 2019, continuando a série sobre design patterns. Hoje vamos aprender sobre o pattern Facade.

Proxy

Arquitetura e Desenvolvimento de software — Parte 13 — Proxy
Vamos hoje abordar o último pattern do grupo Estruturais, o Proxy.

Padrões comportamentais

Chain of Responsibility

Arquitetura e Desenvolvimento de software — Parte 14 — Chain of Responsability
Neste artigo, vamos dar início ao estudo dos padrões comportamentais, continuando a série sobre design patterns, começando pelo padrão Chain of Responsability.

Iterator

Arquitetura e Desenvolvimento de software — Parte 15 — Iterator
Hoje vamos conhecer o pattern Iterator. É um pattern bem simples e iremos ver exemplos em Java e C#.

State

Arquitetura e Desenvolvimento de software — Parte 16 — State
Continuando nossa série sobre Design Patterns, vamos conhecer agora o padrão State.

Command

Arquitetura e Desenvolvimento de software — Parte 17 — Command
Continuando nossa série sobre design patterns, vamos hoje conhecer o pattern Command.

Mediator;

Strategy;

Interpreter;

Memento;

Template Method;

Observer;

Visitor;

Alguns destes padrões se aplicam a classes e outros a objetos. Vamos ver quais se aplicam ao que no detalhe de cada um. Temos alguns padrões extras aos 23 do GoF que creio serem importantes de serem abordados, pois são muito utilizados atualmente. São estes:

Dependency Injection;

Lazy Initialization;

Lock, ou Semáforo;

Repository;

Pausa para memorizar

Aprendi que se esforçar para se manter organizado e estudar um pouco por dia vale muito mais do que estudar tudo de uma vez em um fim-de-semana ou noite…

Dica do dia!
Acho que artigo já está ficando um pouco extenso e causando sono, certo?

Para este artigo não ficar muito extenso, iremos começar a abordar o detalhe de cada padrão a partir da parte 2 desta série. Fiquem ligados pois pretendo publicar esta série de forma rápida, com um intervalo curto entre um post e outro.

Por enquanto ficamos por aqui, não deixem de comentar com dúvidas e feedbacks. Boa parte do que aqui foi escrito reflete muito de minha opinião sobre o papel do arquiteto de software, portanto este primeiro artigo pode e deve ser discutido e melhorado.

Um abraço e até o próximo post, onde vamos começar os estudos de cada pattern, iniciando pelo Abstract Factory.