Em busca do software belo

5 min readMay 2, 2023

Portão de Roubaix, Lille, França. Arquivo pessoal.

Para você, o que é um software belo? É aquele que se adapta às necessidades dos clientes? É aquele que suporta milhares de usuários e requisições simultâneas por minuto? Ou aquele que segue as melhores práticas de codificação e design patterns? Em minha opinião, a resposta é um misto de todas essas coisas, e o estudo da Arquitetura nos ajuda a entender melhor o porquê.

Contudo, não estou falando aqui de Arquitetura de Software e sim da boa e velha Arquitetura de edificações! Neste post, vou traçar alguns paralelos entre essas duas disciplinas tão diferentes na prática, mas que compartilham vários conceitos fundamentais. Para começar, vou mostrar o que um texto escrito na Roma antiga tem a ver com a maneira que desenvolvemos software hoje em dia.

Útil ou estável?

O filósofo romano Vitrúvio foi um dos primeiros a escrever um tratado sobre arquitetura. Em sua obra entitulada “De architectura”, ele identifica três aspectos da disciplina que são ainda hoje essenciais em qualquer edifício: firmitas (estabilidade), utilitas (utilidade) e venustas (beleza).

Mas qual desses aspectos é o mais importante? Nesse ponto, há muita controvérsia. Há quem diga que a firmitas é mais importante que a utilitas, pois enquanto uma construção pode mudar de propósito com o passar do tempo, sua qualidade estrutural permanece. Como explica o arquiteto francês Auguste Perret em seu livro Contribution à une théorie de l’architecture (1945):

A arquitetura é a arte de organizar o espaço; mas é através da construção que ela se manifesta… Funções, costumes, regulamentações e modismos de construção impõem condições que são apenas transitórias.

Um exemplo deste argumento é a construção que ilustra este post, e que tive o prazer de visitar no ano passado em Lille, na França: o Portão de Roubaix. Construído em 1621, era um dos portões de Lille na época em que a cidade era cercada por muralhas. A história dele é interessante pois nos mostra que embora portões e muralhas sejam criados para serem robustos e imóveis, existe uma força capaz de derrubar todos eles: o progresso.

Século após século, trechos da muralha foram sendo derrubados para dar lugar à ruas e prédios. Em 1875, arcos foram abertos nas laterais do portão para permitir a passagem de linhas de bonde (ainda visíveis na parte inferior da foto). Em 1929, já há séculos sem cumprir o papel de fortificação, o portão foi tombado como patrimônio histórico e seu entorno agora é acessível somente à pedestres.

Assim como o propósito do Portão de Roubaix mudou ao longa da história, o propósito de um software também pode mudar. Essa mudança é motivada pela experiência: através de acertos e erros, arquitetos e desenvolvedores vão preparando o sistema para o futuro enquanto tentam não repetir os equívocos do passado. Podemos ver um exemplo disso no artigo Is High Quality Software Worth the Cost?, no qual Martin Fowler descreve uma conversa que teve com um colega arquiteto logo após a entrega de um projeto:

Nosso chefe de tecnologia estava feliz mas confessou que a arquitetura do sistema não era boa. Minha reação foi dizer “isso não é possível — você é um de nossos melhores arquitetos!”. A resposta dele é familiar a qualquer arquiteto de software experiente: “tomamos boas decisões [sobre o sistema], mas só agora entendemos como deveríamos tê-lo construído em primeiro lugar”.

Embora eu não pretenda dar nenhum veredito sobre o assunto, acho que a lição que fica dessas duas anedotas é: a utilitas muda, mas a firmitas permanece. Ou seja, embora a mudança seja inevitável, isso não significa que não devamos pensar nossa estrutura de maneira inteligente.

O app Vitruviano

O Homem Vitruviano, Leonardo da Vinci. Fonte: Wikimedia Commons, montagem do autor deste post.

Falei sobre utilitas e firmitas, mas e a venustas? Deixei esse aspecto para o final justamente porque é difícil falar da beleza estética de um software. Para começar, o que é a parte estética de um software? Poderíamos falar da interface de usuário (UI), mas ela diz respeito somente aos elementos visuais de um app e nossa interação com eles. Porém, muito dos aspectos que tornam a utilização de um app agradável não são visuais. Esse é o tópico de estudo da Experiência de Usuário (UX), explicado por Don Norman e Jakob Nielsen em The Definition of User Experience:

Mesmo que a UI [de um app] para buscar filmes seja perfeita, a UX pode ser ruim para um usuário que busca pequenos lançamentos do cinema independente se o banco de dados contiver apenas filmes de grandes estúdios.

Do ponto de vista do desenvolvedor, a estética de app se apresenta também no estilo e formatação do código. Esses padrões de organização tornam o código não apenas mais legível, mas também mais fácil de alterar e testar, o que por sua vez se reflete diretamente na qualidade do software. Como explicam Raymond Buse and Westley Weimer em A Metric for Software Readability (2008):

Além disso, mostramos que essa métrica [legibilidade] se correlaciona fortemente com métricas tradicionais de qualidade de software, como quantidade de mudanças no código (code changes) e falhas (defect reports).

Contudo, nem todo padrão de codificação gera grande melhorias qualitativas. Por exemplo, estudos mostram que camelCase é tão bom quanto snake_case em termos de legibilidade. Já estive em diversos debates sobre essas questões com desenvolvedores, e se o debate é sensato no final a conclusão é sempre a mesma: não importa o padrão, o que importa é seguí-lo de forma consistente. Por exemplo, se você escolher utilizar snake case nos nomes de variável no seu app, utilize o padrão em_TODOS_os_nomes_de_variável.

E quanto ao desempenho? Será que o tempo gasto em padronização não poderia ser melhor utilizado “polindo bits” para deixar a aplicação mais otimizada? Nesse sentido, é importante lembrar a famosa frase do cientista da computação estadunidense Donald Knuth:

A otimização precoce é a raiz de todo o mal.

Para otimizarmos um bloco de código precisamos primeiro entendê-lo. Esse entendimento nos permitirá saber o quê, onde e como otimizar. E para tornar o código mais compreensível, a beleza é fundamental. Portanto, a venustas é um pré-requisito da otimização.

Considerações finais

Firmitas, utilitas e venustas — estabilidade, utilidade e beleza — andam lado a lado tanto na Arquitetura de edificações quanto na Arquitetura de Software. Se queremos não apenas código belo mas também software belo, precisamos estudar e aplicar Arquitetura de Software em nossos projetos. Como desenvolvedores e arquitetos que trabalham no dia a dia da indústria nem sempre conseguimos criar software que possui um equilíbrio entre esses três aspectos arquiteturais, mas isso não significa que não seja importante conhecê-los. É quando surgem os grandes desafios que esses conhecimentos fazem a diferença.

Fontes:

Em busca do software belo

Written by Gabriel Ullmann