Design emergente: por que software não nasce pronto no diagrama

Bom software raramente nasce de um desenho completo feito antes do código. A tese defendida por Fabio Akita, ao comentar uma lista de livros de ciência da computação e engenharia de software, é que o design de um sistema emerge do contato disciplinado com o próprio código: escrever, testar, perceber os problemas reais, refatorar e só então consolidar uma estrutura melhor. Isso não elimina planejamento, mas limita a fantasia de que diagramas, especificações extensas ou vocabulários arquiteturais resolvem o problema antes da implementação.

O contraste histórico ajuda a explicar por que essa ideia demorou a se impor. Akita lembra que, nas décadas de 60 a 80, programar era caro, lento e dependia de computadores compartilhados, terminais remotos e pouca memória. Nesse ambiente, tentar acertar mais no papel fazia sentido. Com microcomputadores mais potentes, redes melhores e ferramentas locais, tornou-se viável rodar o sistema, errar mais cedo e melhorar a estrutura depois. A refatoração, no sentido de Martin Fowler, entra justamente aí: mudar a estrutura interna sem alterar o comportamento externo, reduzindo o risco de transformar melhoria em reescrita disfarçada.

A crítica recai sobre duas confusões recorrentes. A primeira é tratar processos como RUP e UML como se ainda fossem o centro do desenvolvimento, quando parte de seu valor atual está mais no vocabulário do que no ritual. A segunda é ler livros como Design Patterns ou Domain-Driven Design como manuais de arquitetura antecipada. Na leitura de Akita, padrões são nomes para repetições observadas em projetos; DDD ajuda a nomear domínios, fronteiras e contextos. Nenhum deles autoriza um programador a empilhar abstrações antes de ter evidência de que elas resolvem um problema concreto.

A consequência prática é dura para iniciantes e útil para profissionais: código que apenas roda pode continuar sendo ruim. Se ele tem baixa manutenibilidade, nomes ruins, complexidade alta e dificulta mudanças futuras, ele atrapalha quando o problema muda. Por isso livros como Clean Code, Extreme Programming Explained e The Pragmatic Programmer aparecem na conversa menos como receitas definitivas e mais como tentativas de disciplinar uma atividade instável. A pergunta relevante deixa de ser qual arquitetura parece melhor no começo e passa a ser que mecanismos a equipe tem para aprender com o código sem perder o controle do sistema.

Assistir ao episódio original

Referências encontradas

Livros

• Algoritmos - Teoria e Prática, de Thomas H. Cormen — Ver livro na Amazon
• Art Of Computer Programming, The, Volumes 1-4b, Boxed Set: Volume 1-4b, de Donald E. Knuth — Ver livro na Amazon
• Compiladores: Princípios, Técnicas e Ferramentas, de Alfred V. Aho, Ravi Sethi, Jeffrey D. Ullman — Ver livro na Amazon
• The Design And Evolution Of C++, de Bjarne Stroustrup — Ver livro na Amazon
• Análise e Projeto Orientados a Objetos com Python (Fundamentos na Oficina), de Grady Booch — Ver livro na Amazon

Este post contém links de afiliado. Se você comprar por eles, eu posso receber uma pequena comissão sem custo adicional para você.