Fundamentals of Software Architecture: um breve comentário
Olá!
O intuito desse artigo é ser um compêndio do que eu andei estudando sobre arquitetura de software do livro abaixo, porém, de uma forma mais resumida.
Arquitetura é sobre as coisas importantes… seja lá o que for. (Martin Fowler)
A engenharia de software é uma criança comparada com outras engenharias, portanto, o grau de previsibilidade em software que é possível obter ao construir uma ponte talvez nunca seja possível, por dois motivos: software é um trabalho exploratório e criativo e o fato de existir a possibilidade de não saber nem o que se não se sabe é o principal ofensor no desenvolvimento de software. Devido ao excesso de coisas que não conseguimos saber em alguns casos, arquiteturas como Big Design Up Front sempre estão fadadas ao fracasso, pois sempre haverão coisas impossíveis de antecipar.
Uma abordagem mais saudável de enxergar arquitetura é como uma espécie de princípios de System Design que se pode seguir para um determinado sistema, ao invés de regras rígidas. Ou seja, ao invés de diretivas rígidas como use Java para o back-end de todos os sistemas novos, uma abordagem melhor seria: para back-end, a recomendação de arquitetura é utilizar linguagens de programação orientada a objetos, que suportem tipos estáticos e que tenham garbage collector. Nesse caso, fica a critério da equipe decidir se irá usar Java, C# ou Golang, de acordo com seu próprio contexto, pois todas as linguagens mencionadas atendem ao critério descrito.
Podemos chamar de variância uma determinada decisão deliberada (e embasada) que foge dos princípios de arquitetura pré-definidos. O que é necessário em alguns casos. Ao invés de rigidez, é mais saudável ter um processo preparado para lidar com essa variabilidade natural no processo de desenvolvimento.
Uma das formas de se lidar com variância de forma saudável é o uso de fitness functions, que nada mais são do que formas de garantir a saúde da arquitetura, mesmo com as mudanças que ela sofre ao longo de tempo. Como exemplo, temos: tempo de resposta médio, tempo de resposta no 99 percentil, requests por segundo e demais métricas que podem ser verificadas de forma automatizada. A ideia aqui é: se a mudança sistêmica gerou queda em algum valor, ela é inadequada e precisa ser revista. Esse conceito é melhor explorado no livro Building Evolutionary Architectures.
Para resumir bem a disciplina, gostaria de citar as leis de arquitetura propostas pelo Neal Ford:
Primeira lei da arquitetura: Tudo em arquitetura de software é um trade-off.
Corolário 1: Se o arquiteto descobriu algo que não é um trade-off, é mais provável que ele ainda não tenha identificado o trade-off.
Segunda lei da arquitetura: Porque é mais importante que o como.
Em outros termos, essas leis são o não existe almoço grátis da arquitetura.
Segundo o autor, não existe curso para arquiteto de software, pois as expectativas da posição são muito densas para se ensinar em um curso, que são as seguintes (com um breve comentário sobre cada uma delas):
Tomada de decisões arquiteturais: como ensinar alguém a estar preparado para decidir como serão os sistemas de uma empresa inteiro sem que essa pessoa tenha vivência nas consequências de suas decisões?
Análise contínua da arquitetura: Se a única constante é a mudança, alguém precisa continuar olhando para descobrir o que ainda faz sentido.
Acompanhar as tendências da indústria: Você confiaria em algum arquiteto que sugere monolitos on-premise em Delphi com banco de dados Sybase em 2022?
Impor compliance com suas decisões: A arquitetura surge para atender algum requisito de negócio, portanto, para algum lugar coeso as decisões arquiteturais precisam apontar. Isso depende de empresa para empresa e é difícil generalizar em cursos.
Background diversificado: Assim como times diversos são mais felizes e produtivos, aquela experiência específica com linguagens funcionais do arquiteto ou o deep dive que o Senior fez em PostgresSQL com certeza ajudam a gerar soluções melhores no geral, por exemplo.
Conhecimento de domínio: É uma armadilha comum achar que é possível pensar nos aspectos técnicos sem saber que problema ele resolve. Um sistema não é somente um conjunto de APIs, queues e SQL. Essas ferramentas atendem a um propósito, que geralmente é resolver algum problema de alguém. Conhecimento de domínio é algo válido somente para aquela empresa com uma ou outra pequena reutilização possível em empresas do mesmo segmento. Exemplo: O jeito de fazer um banco pode ser mais ou menos o mesmo, mas varia muito de um banco laranja e um banco roxo.
Soft Skills: É necessário liderança, negociação e comunicação para atuar com arquitetura. Só para citar as mais básicas. Experimente tentar vender uma ideia com resistência de todos os lados (inclusive dos desenvolvedores, achando que tem uma ideia melhor). Em último caso, toda decisão será desafiada. A proposta do autor do livro é: Aceite que dói menos e aprenda a negociar.
Entendimento e traquejo de política: Toda empresa tem seus momentos de expansão, contração ou estabilidade. Assim como tem hora para fazer projetos novos ou simplesmente corrigir bugs no legado. Entender isso é crucial para tomar melhores decisões.
Toda arquitetura é produto de seu contexto, portanto, não existe a solução definitiva! Quem tá dizendo que existe provavelmente está querendo te vender algo.
Se você gostou das ideias aqui propostas, recomendo fortemente que vá na fonte original se aprofundar.
Até a próxima!
Você gostou do conteúdo e gostaria de fazer mentoria comigo? Clique aqui e descubra como.
