Você não é (ou, pode não ser) arquiteto. Saiba o porquê (e aceite isso)

Olá pessoal, tudo certo?

O post de hoje mostra minhas considerações sobre os papéis de arquitetura e desenvolvimento. Nessa posição, sou extremista (embora acredite que toda verdade extremista é fraca): arquitetos são arquitetos, desenvolvedores são desenvolvedores.

Vamos aos fatos…

O que é arquitetura?

Todo software possui uma arquitetura. Boa ou ruim, ela está presente. Planejada ou não, ela se forma, consiste e persiste. Ela pode estar “escondida”, mal-entendida, corrompida, vilipendiada, ignorada ou, até mesmo, esquecida. Mas está ali.

A arquitetura de um software pode até não estar descrita em documentos formais, representada em diagramas ou quaisquer outros tipos de artefatos. Mesmo assim, se há um software, há uma arquitetura.

A arquitetura é a expressão máxima das principais decisões relacionadas a um software. Ela contempla o conjunto de propriedades e comportamentos essenciais do software. Ela explicita o escopo fundamental do sistema.

A arquitetura é a visão fundamental do sistema. Mais que isso, ela define o sistema.

Em software, não há “visão do todo” sem profunda compreensão da arquitetura. Arquiteturas ocultas ou mal evangelizadas implicam em sistemas ruins e cheios de partes “descartáveis”. Um sistema com arquitetura “oculta” é um Frankenstein, uma colcha de retalhos, um pesadelo para o time, um pesadelo para todos os interessados.

A arquitetura de um software consiste de sua estrutura mais fundamental que são, por razões evidentes, praticamente imutáveis. Todo sistema possui uma estrutura fundamental, logo, todo sistema possui uma arquitetura.

Ao observar qualquer software, podemos identificar seus componentes principais -comportamentos e papéis. Além disso, conseguimos enxergar como esses componentes se relacionam com os outros componentes. A esse conjunto rico de informações chamamos arquitetura.

Sumarizando, a arquitetura de um software é descrita através da elucidação de seus componentes fundamentais – seus comportamentos, papéis e relacionamentos. É essa “visão” do todo – sem detalhes, sem internals desses diversos componentes, comportamentos e dos seus relacionamentos – que representa as decisões fundamentais de um software.

Toda arquitetura de sistema pode ser explicitada

Explicitando a arquitetura de um sistema

Fica claro e evidente que a arquitetura está presente em qualquer sistema. Entretanto, como identifica-la. Em outras palavras, como tonar a arquitetura de um sistema evidente?

Façamos um exercício simples:

• Pense no sistema que está trabalhando agora;
• Enumere as partes/componentes fundamentais desse sistema.
• • Primeiro em sentindo horizontal. Pense nos módulos de seu sistema (chamo-os, também, componentes);
  • Depois, em sentido vertical. Considere todos componentes que dão “sustentação” aos módulos (persistência, interface com usuário, regras de negócio, monetização);
• Descreva, mesmo que superficialmente, as principais atribuições e comportamentos de cada componente;
• Identifique as relações entre esses módulos e componentes;
• Vá para um quadro branco…
• Desenhe uma caixa para cada componente, começado do alto para baixo, na seguinte sequência;
• • Interface com o usuário ou sistemas externos;
  • Serviços (server side) e APIs expostas;
  • Módulos de seu sistema
  • Componentes de negócio compartilhados entre os diversos módulos;
  • Componentes de infraestrutura;
• Desenhe setas ligando essas caixas para representar as relações mais importantes;
• Elimine o que parece excesso. Generalize e não se prenda a especificidades de tecnologia.

De forma básica, garanta que sua estrutura tenha, pelo menos, uma descrição básica de componentes e relações semelhantes ao template que indico a seguir (explico esse template com detalhes nesse post):

Esse modelo é útil para arquiteturas que estejam fundamentadas em camadas. Sinta-se a vontade se precisar criar representações alternativas (há patterns diferentes para representar arquiteturas diferentes).

Uma arquitetura devidamente explicitada facilita a comunicação com o grupo. Pratique esse exercício, compartilhe com seu time o resultado e verifique seus feedbacks.

Toda arquitetura pode e deve ser planejada

Não podemos confundir arquitetura emergente com anarquia arquitetônica. Em qualquer momento, o time precisa ter condições de descrever sua visão da estrutura fundamental de um projeto. Uma boa arquitetura dificilmente será obra do acaso. Uma boa arquitetura é resultado de um planejamento cuidadoso.

Não há razão para repetir velhos enganos. Mesmo trabalhando em uma área de conhecimento relativamente recente, há milhares de exemplos e experiências de projetos bem-sucedidos que podem servir como modelo para formação de uma boa arquitetura. Se há design patterns, há também patterns arquiteturais.

Construir e consolidar uma boa arquitetura colabora com o talento do time de desenvolvimento para uma definição mais clara das tecnologias que serão empregadas em cada componente. Uma boa arquitetura permite que seja selecionada a melhor tecnologia para cada escopo.

A definição dos componentes – seus papéis, comportamentos e relacionamentos – permite que o time perceba, o mais cedo possível, as entradas e saídas esperadas por cada componente, bem como oportunidades de generalização e reaproveitamento.

A construção de frameworks corporativos (entenda-se: componentes com alta possibilidade de reuso em novos projetos) é consequência de uma visão arquitetônica coerente. É comum que projetos sendo desenvolvidos em paralelo em uma corporação necessitem de componentes semelhantes.

Arquitetura não está relacionada DIRETAMENTE a atividade de desenvolvimento

Arquitetura não está relacionada diretamente a desenvolvimento

Pelo descrito, a arquitetura de um sistema nasce junto com o plano de como implementar esse sistema.

Repare que falo todo o tempo em componentes – papéis, comportamentos e relacionamentos. Não falo de classes, instâncias ou gestão de dependências. Logo, patterns para arquitetura não estão relacionados diretamente com patterns de design.

Arquiteturas emergentes decorrem da necessidade de ajustar componentes ou seus relacionamentos. Novos componentes surgem, ou componentes inicialmente percebidos como importantes perdem relevância. Relacionamentos ficam evidentes (junto com suas demandas), ou perdem seu propósito devido a uma melhor compreensão do domínio. De qualquer forma, isso ocorre durante o desenvolvimento e não por causa do desenvolvimento.

Arquitetos, geralmente, são (ou foram) bons desenvolvedores

Desenvolvimento de software é uma atividade relativamente recente e, por consequência, imatura. Mesmo com toda a relevância da arquitetura de software, poucos são os projetos que têm um desenvolvimento arquitetônico conduzido de forma coerente.

Na maioria dos casos, conta-se com a expertise dos desenvolvedores mais experientes que, por feeling e arrogância, tomam para si algumas atividades arquitetônicas. Infelizmente, o que temos na prática, na maioria dos casos, é a aplicação do mais do mesmo (até quando o “mesmo” não é o mais adequado).

Alguns desenvolvedores, geralmente com maior senioridade, percebem e valorizam a importância do projeto arquitetônico. Esses mesmos desenvolvedores percebem e evidenciam a necessidade de desenvolver competências distintas daquelas que já possuem visando maior efetividade e retorno.

Esses mesmos desenvolvedores acabam participando ativamente dos trabalhos de implantação e identificam rapidamente eventuais desvios (deterioração ou erosão arquitetônica) fazendo os ajustes necessários. Entretanto, que fique evidente: são desenvolvedores que também são arquitetos. Competência para arquitetura é distinta e isolada da competência para desenvolvimento.

Bons desenvolvedores não são, necessariamente, arquitetos

Todo software têm uma arquitetura definida. Fato!

Arquitetura pode ser, ou não, planejada. Fato!

Nem todas as empresas têm arquitetos (não estou falando de cargo, estou falando de alguém com competência para a atividade). Fato!

Toda empresa que faz software, possui desenvolvedores (mais ou menos qualificados). Fato!

Desenvolvedores não têm, necessariamente, habilidade para trabalhar arquitetura. Fato!

Você pode ser um excelente desenvolvedor (sênior até) e, mesmo assim, ter enorme dificuldade para identificar e planejar componentes – seus papéis, comportamentos e relacionamentos. Por quê? Porque nem todo desenvolvedor tem as competências (conhecimentos + habilidades + atitudes) para “desenvolver” arquitetura. Simples assim!

Enfim…

Pode ser que você seja um bom arquiteto e também um bom desenvolvedor. Parabéns para você!

Pode ser que você seja um bom arquiteto e seja um desenvolvedor bem ruinzinho (é raro, mas acontece!). Parabéns para você, também!

Talvez você seja um ótimo desenvolvedor, e não seja um arquiteto. Parabéns para você (com todo o meu respeito)! Se for uma opção, então, fantástico! Você deverá ser feliz com sua decisão.

Arquitetos fazem arquitetura. Desenvolvedores, não! São atividades diferentes, importantes, e com competências necessárias distintas.

Quer ser um arquiteto, estude para ser arquiteto. Não é o mesmo que estudar desenvolvimento.

 

Por hoje, era isso!