Em primeiro lugar, eu realmente gosto muito do estilo de escrita do Uncle Bob.

Não é à toa que ele tem esse apelido: ao longo da leitura você tem aquela sensação intimista de estar falando com um velho (e sábio) tio que está tentando colocar algum juízo na sua cabeça e colocar você no caminho certo.

No prefácio e na introdução do livro, U.B. trás uma discussão bastante interessante sobre o por quê que arquitetura é um tópico universal e por que se trata de um tópico que é tão essencial para a computação há 50 anos, desde o surgimento das primeiras máquina programáveis, quanto é hoje, quanto (provavelmente) será daqui a mais 50 anos, independentemente dos novos tipos de tecnologias que possam surgir.

O impacto real da arquitetura

No capítulo 1, entramos numa discussão prática da importância da arquitetura no mundo real. E nada pode ser mais brutalmente concreto do que isto: rentabilidade, custo ou, em outras palavras, dinheiro.

Nesse capítulo ele apresenta um estudo de caso de uma empresa. Acompanhamos a evolução de um projeto específico analisando os seguintes parâmetros: produtividade, custo e recursos dispendidos longo do tempo. Esse estudo trás uma realidade brutal que, se você é desenvolvedor, já experimentou em algum momento de sua carreira.

Os dados apresentados - que eu não posso reproduzir aqui sem violar alguma lei de direitos autorais - mostram que, no início do projeto, que começa com um número pequeno de desenvolvedores, a produtividade é alta e novas funcionalidades são adicionadas no sistema de forma rápida e ágil. "Produtividade" aqui é medida simplesmente pelo número de linhas de código adicionadas ao projeto. Uma abordagem simplista, mas que serve perfeitamente para demostrar o problema.

Ao longo da evolução do projeto, apesar de o número de desenvolvedores estar sempre aumentando, a produtividade começa a cair vertiginosamente e os custos por linha de código começam a subir na mesma proporção.

Por que? Esse é o sinal claro de uma bagunça! Sejamos francos: você e eu já estivemos aí. É aquele situação em que a menor mudança na base de código pode gerar uma grande dor de cabeça. E embora não seja impossível fazer a mudança, frequentemente ela se torna impraticável, porque a alteração desse componente tem o potencial de afetar o sistema como um todo.

...

Se nós vivêssemos em um mundo estático, isso não seria um problema: faríamos nossa grande e gigantesca bagunça funcionar e o problema estaria resolvido para sempre.

Porém vivemos em um mundo dinâmico de constante mudanças onde os requerimentos e especificações do sistemas precisam se adaptar a esse cenário. E se continuarmos construindo bagunças é isto que nós teremos: um sistema que eventualmente vai se tornar inútil por não atender mais às demandas do mundo real e por ser, não impossível, mas absolutamente impraticável de mudar.

O que nos leva ao capítulo 2: uma fábula de dois valores (tradução livre).

O bem maior

Aqui temos a ideia de que software pode ser enxergado através da dicotomia de dois valores ou duas virtudes: funcionalidade e estrutura.

Funcionalidade diz respeito à capacidade do software de realizar o que ele foi projetado para fazer.

Estrutura ou arquitetura se refere à articulação dos componentes de um sistema. Em outras palavras, pode ser entendido como uma medida:

• do quanto ele é resiliente a mudanças;

• do quanto ele é testável;

• do volume de esforço humano que é necessário para fazer com que esse sistema continue a entregar valor aos seus usuários ao longo do tempo.

Funcionalidade é primeira coisa que a maioria das pessoas enxergam no software. Afinal, esse é o propósito imediato: resolver o problema que está na mesa. Entretanto, se esse for o único objetivo que temos em mente, mais cedo do que se imagina vamos construir para nós mesmos uma grande armadilha: a princípio pode parecer que estamos avançando rápido, porém, rapidamente, o processo que nos levou até ali vai nos frear de forma brutal.

O que a maioria das pessoas tende a pensar é que estrutura só é uma virtude válida a ser considerada em projetos grandes. Mas o que o U.B. traz aqui - e o que eu mesmo já experienciei por conta própria - é que estrutura é a a virtude primordial do software em qualquer contexto.

E, sinceramente, eu poderia gastar várias linhas tentando explicar o por que disso, mas esse é o tipo de coisa que você só consegue absorver tendo vivido o processo na pele. E esse processo é mais ou menos o seguinte:

• Escrever "bagunças" que te levam de A a B rapidamente (se a distância entre A e B for bem pequena), mas que têm um custo infinito para te levar de B a C (por menor que seja);

• Se frustrar com essa forma de construir;

• Buscar formas alternativas (melhores);

• Sentir atrito e desconforto ao tentar por em prática o que você aprendeu;

• Começar a entender e enxergar valor na arquitetura, inclusive no aspecto produtividade.

Não me entenda mal: apesar de já ter vivido esse processo em algum grau, estou longe de estar "no fim" dessa jornada, muito pelo contrário (de outra forma não haveria sentido em ler esse livro, haha).

Mas quanto mais eu projeto e construo software, mais eu tendo a chegar nesse consenso... Sobre que arquitetura é, de fato, o bem maior.

E assim terminamos a primeira parte do livro.

...

Espero que a essa discussão desperte o interesse por arquitetura. Lembrando que estou sempre disponível para falar/discutir a respeito. Não hesite em entrar em contato!

Talvez para os próximos capítulos eu resolva trazer conteúdo em outros formatos. Tenho a impressão de que talvez consiga me aprofundar mais nas discussões do livro trazendo o conteúdo em formato de vídeo.

Bem, de toda forma, é isso!

Este artigo é parte da série Clean Architecture baseada no livro de mesmo nome do Uncle Bob. Confira os demais:

Seguinte: Paradigmas de programação e Arquitetura

Anterior: Arquitetura e Design de Software: Clean Architecture