Fala, 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 over-engineering 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 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 abordarei todos, pois caso contrário, seria um livro, não uma série de artigos – o conteúdo é bem extenso.

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.

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 dos 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 vêm 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 poucas horas .

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 à tecnologia, mas processos e experiência. O usuário está ficando mais exigente a cada dia.

Acredite, software como entregávamos anos atrás, aquele projeto de um 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 vêm 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, não distorcendo seus objetivos e processos, mas sim evoluindo eles de forma adequada e estratégica.

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 e 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, enfim. 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 nos quais está envolvido. Não apenas fazer um documento ou arquétipo em um repositório padrão para os desenvolvedores da empresa – principalmente os mais novos, que ainda têm 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, saberão conduzir a equipe para o caminho correto.

Padrões GoF (Gang of Four)

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 três tipos.

Mas o que é GoF? Em 1995 um grupo de pessoas, mais 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 abordaremos 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 três famílias:

Padrões de criação

• Abstract Factory
• Factory Method
• Builder
• Prototype
• Singleton

Padrões estruturais

• Adapter
• Composite
• Bridge
• Decorator
• Flyweight
• Facade (ou Façade, pela pronúncia)
• Proxy

Padrões comportamentais

• Chain of Responsability
• Iterator
• State
• Command
• Mediator
• Strategy
• Interpreter
• Memento
• Template Method
• Observer
• Visitor

Alguns destes padrões se aplicam a classes e outros a objetos. Veremos 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 em uma noite.

Para este artigo não ficar muito extenso, começaremos a abordar o detalhe de cada padrão a partir da Parte 02 desta série. Fiquem ligados, pois pretendo publicar esta série de forma rápida, com um intervalo curto entre um artigo 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 artigo, onde começaremos pelo padrão Abstract Factory.