Fundamentos da Arquitetura de Software - Capitulo 2

Pensando como um Arquiteto de Software: Estrutura, Trade-offs e Código

Você já parou para pensar no impacto que uma única alteração pode ter na escalabilidade de todo o seu sistema? Entender como diferentes componentes interagem e escolher as bibliotecas e frameworks corretos para cada cenário é a essência de pensar de maneira arquitetural.

Mas, na prática, o que realmente separa a arquitetura do design de software? E como o arquiteto consegue manter a mão na massa sem perder a visão do todo? Vamos explorar as respostas para essas questões.

Arquitetura vs. Design: Qual a diferença?

Embora andem de mãos dadas, a divisão entre os dois conceitos pode ser resumida em estrutura e aparência:

. Arquitetura lida com a estrutura do sistema. Envolve as decisões estratégicas e de alto nível.

. Design foca na aparência e no detalhe da implementação. Está diretamente ligado às decisões táticas do dia a dia.

A grande bússola para diferenciar os dois é a relevância dos trade-offs. Toda decisão técnica exige compromissos, mas quanto mais críticos, amplos e difíceis forem os trade-offs, mais arquitetural é a decisão em questão.

A Pirâmide do Conhecimento: Amplitude vs. Profundidade

Para desempenhar bem o papel, um arquiteto precisa desenvolver uma forte amplitude técnica.

Profundidade técnica é o domínio absoluto sobre uma linguagem ou framework (por exemplo, conhecer os detalhes internos do Java e do Spring Boot).

Amplitude técnica é saber um pouco sobre muitas coisas.

Podemos visualizar o nosso conhecimento como uma pirâmide dividida em três partes:

1. O que sabemos (Topo).

2. O que sabemos que não sabemos (Meio) — É exatamente aqui que a amplitude técnica do arquiteto deve atuar!

3. O que não sabemos que não sabemos (Base).

O Desafio: Equilibrando Arquitetura e Código

Um dos maiores desafios da área é não se afastar da codificação prática. Todo arquiteto deve codificar para validar suas ideias e manter certo nível de profundidade técnica. Para conseguir esse equilíbrio, siga estas 6 dicas:

1. Evite a "Armadilha do Gargalo": Não assuma tarefas de código que estejam no caminho crítico de entrega. Se você for chamado para resolver um problema de arquitetura, seu código não pode travar a equipe.

2. Crie POCs (Provas de Conceito): Validar decisões de arquitetura exige escrever código. As POCs são a oportunidade perfeita para testar hipóteses na prática.

3. Ataque a Dívida Técnica: Use seu tempo de codificação para refatorar, melhorar a estrutura existente e pagar débitos do projeto.

4. Corrija Bugs: Caçar bugs é uma excelente maneira de descobrir onde a arquitetura atual está frágil ou dificultando a vida dos desenvolvedores.

5. Automatize: Invista tempo criando scripts ou ferramentas que facilitem o fluxo de trabalho de todo o time.

6. Faça Revisões de Código (Code Reviews): Uma ótima forma de se manter próximo do código e garantir que as diretrizes arquiteturais estão sendo seguidas na implementação.

Para refletir e debater: E você, olhando para as tarefas do seu dia a dia, tem tomado decisões mais estratégicas ou mais táticas? Deixe sua visão nos comentários!