📝 pt-br ~ 4 min

Fundamentals of Software Architecture

Share this post

Há quem diga que ler livros técnicos é perda de tempo. Tenho a opinião oposta: é essencial. Não existe melhor forma de transmissão de conhecimento focado e organizado do que em um livro. Código planejado é melhor código. Certamente não vai te deixar melhor na prática e esta é fundamental para saber de verdade. Mas livros te ajudam a pensar melhor. A pensar com o conhecimento formulado por outras pessoas que percorreram caminhos parecidos com os nossos. Ler é fundamental e este é um dos livros técnicos mais recentes e importantes que li.

Tudo em arquitetura de software é um trade-off.

Section titled %5Bobject%20Undefined%5D
Primeira lei da Arquitetura de Software

Leis da Arquitetura de Software

Section titled %5Bobject%20Undefined%5D

Logo no primeiro capítulo de “Fundamentals of Software Architecture” dos autores Mark Richards e Neal Ford, eles encerram dizendo que enquanto o escopo da arquitetura de software é para todos os fins impossivelmente ampla para qualquer indivíduo, existe uma forma de unificar. E eles encontram e aprenderam o que chama de Primeira lei da Arquitetura de Software:

“Tudo em arquitetura de software é um trade-off”

Primeira lei da Arquitetura de Software

E acrescentam, que nada existem em um limpo, elegante espectro para os arquitetos de software. Cada decisão deve levar em conta muitos fatores opostos. E acrescentaria algo que aprendo todos os dias: toda decisão é contextual e deve ser estratégica. E “decisões técnicas” muitas vezes são opinadas apenas ou mesmo de estilo. Desta lei eles definem:

“Se uma pessoa arquiteta acredita que descobriu algo que não possui um trade-off, o mais certo é que apenas não identificou o trade-off ainda.”

Corolário 1

A visão dos autores é que arquitetura de software vai além de estruturas bases, princípios e características, indo muito além de apenas a combinação dos elementos estruturais, refletida na próxima lei:

“Por quê é mais importante do que como.”

Segunda lei da Arquitetura de Software

Há uma interessante frase atribuida a Rich Hickey, criador da linguagem Clojure de programação:

Programadores sabem os benefícios de tudo e os trade-offs de nada. Arquitetos precisam entender ambos.

Essa frase resoou muito em mim. Fazendo essa transição - em processo - de um desenvolvedor web, para um desenvolvedor cloud e também na posição de direcionar os rumos de tecnologia da instituição que faço parte, percebo o quanto isto é verdade. Eu pensaria “Nem todo programador…”, mas é só nosso mecanismo de defesa. Queremos nos excluir de alguma categoria que parece limitante, mas ás vezes é necessário entender os limites, para explorar estes e descobrir novos caminhos.

Pensar arquiteturamente é olhar os benefícios de uma dada solução (SOA - Service Oriented Architecture, Event Driven, MVC, etc) mas também analizar os negativos, os trade-offs, associados com cada decisão. E não são poucos, para cada arquitetura há vários e vários deles, muitos devido exatamente às forças deles em uma área ou outra, ou condições e contextos. A entropia é inexorável.

O livro faz um ótimo trabalho de mostrar a variedade de arquiteturas existentes e as habilidades e campos da arquitetura de software, em tantas formas e profundidade que não conseguiria abordar melhor do que eles já fizeram no livro.

E se tem uma observação que vem se solidificando em mim é de que, se o movimento DevOps foi incorporando Operações e Segurança no desenvolvimento, a transição de uma desenvolvimento Cloud e o uso cada vez mais estratégico dos serviços gerenciados das clouds públicas, está transformando as habilidades de um desenvolvedor para além de codar, já que ele pode se concentrar em desenvolver mais os códigos das regras de negócio e pensar ao mesmo tempo arquiteturalmente, então, eu acredito que desenvolvedores cloud deverão ter uma visão arquitetural sólida para se criarem as melhores soluções.

Desenvolvedores cloud precisam ser tanto desenvolvedores quanto arquitetos.

Section titled %5Bobject%20Undefined%5D

Infelizmente o livro ainda está caríssimo nesse momento comprando na Amazon.com.br, ao preço de 323,75 para a versão de capa comum e 307,56 para a versão Kindle!!!! (preços de 19 de setembro, 2020). Então comprar pela Amazon.com, contando que não será sua única compra para justificar o frete, ainda é a melhor opção para ter o livro ou ainda a assinatura da própria O’Reilly, que é certamente cara com seus 49 dólares por mês - o que para nós brasileiros cada dólar agora grita por 5 reais, mas te dá 10 dias de acesso grátis a todo o conteúdo deles. Infelizmente acesso a material de qualidade exige custos elevados, a não ser que se encontre material disponível em outras plataformas. Este é certamente um livro que me impactou bastante e se tornou rapidamente em um dos meus livros técnicos favoritos e que certamente retornarei para reler muitas partes.