Código elegante para quem? Qualidade interna precisa apoiar uma decisão

“Code is Poetry” funciona como elogio ao cuidado com o código. O problema começa quando a metáfora substitui critérios: uma solução parece elegante para quem a escreveu, mas é difícil de alterar, operar ou usar.

Poesia não precisa ser mantida por uma equipe durante anos, responder a incidentes ou preservar compatibilidade com integrações. Software precisa. A qualidade do código não pode depender apenas da sensação de beleza de seu autor.

Isso não torna a qualidade interna secundária. Ela protege a capacidade de entregar e operar o produto. O que muda é a pergunta: qual decisão de design reduz um custo ou um risco observável neste sistema?

“Limpo” e “elegante” não são critérios suficientes

Duas pessoas experientes podem discordar sobre o código mais legível. Uma pode preferir uma abstração que remove duplicação; outra pode considerar que a abstração esconde diferenças importantes. Sem o contexto de mudança, ambas conseguem defender sua preferência.

Eu avaliaria uma decisão de código por perguntas mais concretas:

um defeito fica confinado ou se propaga pelo sistema?
uma regra de negócio pode ser encontrada e alterada em um lugar previsível?
os testes detectam a mudança de comportamento relevante?
falhas deixam informação suficiente para diagnóstico?
dados sensíveis e permissões permanecem explícitos?
a equipe consegue desfazer ou substituir a decisão?
o custo de entender a abstração é menor que o custo que ela remove?

Esses critérios ainda exigem julgamento. A diferença é que podem ser conectados a mudanças, incidentes e restrições reais.

A ISO/IEC 25010:2023 define um modelo com nove características de qualidade para produtos de tecnologia da informação. O modelo serve como referência para especificar e avaliar qualidade durante o ciclo de vida, não como uma pontuação automática para código. Sua existência já expõe o limite da metáfora estética: qualidade é multidimensional e envolve diferentes interessados. (ISO/IEC 25010:2023)

Qualidade externa e interna se conectam por um mecanismo

Usuários normalmente não veem a estrutura dos módulos. Eles percebem disponibilidade, correção, tempo de resposta, segurança e facilidade de concluir uma tarefa. A equipe percebe tempo para implementar mudanças, dificuldade de testar e custo de recuperar falhas.

A ligação entre esses níveis precisa ser explicada. Por exemplo:

regra duplicada em três serviços
→ mudança aplicada de forma inconsistente
→ resultados diferentes para a mesma operação
→ retrabalho e erro para o usuário

Nesse caso, centralizar a regra pode reduzir uma classe de inconsistência. Mas a decisão também pode criar acoplamento e um ponto único de falha. “Remover duplicação” não basta; é preciso comparar as consequências.

Outro exemplo:

integração sem limite de tempo
→ requisição fica presa quando o fornecedor falha
→ recursos se acumulam
→ outras solicitações perdem disponibilidade

Aqui, timeout, tratamento de erro e observabilidade apoiam um resultado percebido pelo usuário. Não são adornos de engenharia.

O cliente não é a única pessoa afetada

“Foco no cliente” pode ocultar operadores, suporte, pessoas responsáveis por segurança e usuários indiretos. Uma funcionalidade simples na interface pode exigir uma operação manual insustentável. Uma automação conveniente pode retirar da pessoa afetada a possibilidade de contestar um erro.

Eu registraria pelo menos quatro perspectivas:

Perspectiva	Pergunta de qualidade
Usuário	consegue atingir o resultado com segurança e compreensão?
Operação	o serviço pode ser observado, recuperado e mantido?
Engenharia	mudanças permanecem localizadas, testáveis e reversíveis?
Pessoas afetadas	erros, exclusões e uso de dados podem ser percebidos e contestados?

A ISO 25065 trata requisitos de usuário como condições para atingir resultados pretendidos e como critérios de qualidade relacionados ao uso. A norma não prescreve um método de desenvolvimento, mas reforça que “atender ao usuário” precisa ser traduzido em requisitos verificáveis. (ISO 25065:2019 sobre requisitos de usuário)

Refatoração precisa de hipótese

Refatorar sem alterar o comportamento observável pode melhorar a estrutura interna. Ainda assim, o investimento compete por capacidade e merece uma razão mais precisa que “deixar bonito”.

Um registro possível seria:

sintoma: alterações de preço exigem editar três módulos
risco: regras divergentes chegam à produção
hipotese: concentrar a política reduz mudanças incompletas
escopo: regra de preço do canal direto
validacao:
  - testes de caracterizacao preservam o comportamento atual
  - uma nova regra exige alteração em um único módulo
contramedidas:
  - dependência criada entre serviços
  - impacto no tempo de resposta

O exemplo é ilustrativo; não relata um projeto real. Ele mostra como ligar uma intervenção interna a um problema e também registrar seus custos.

Martin Fowler chama de hipótese a ideia de que investir em design preserva a capacidade de alterar software ao longo do tempo. Ele também reconhece que não há uma medida objetiva simples para qualidade de design ou produtividade. Essa limitação é importante: a relação faz sentido como modelo de decisão, mas não autoriza prometer que toda refatoração produzirá velocidade. (Design Stamina Hypothesis)

XP e DDD não certificam excelência

A versão anterior deste texto aproximava “Code is Poetry”, Platão, Extreme Programming e Domain-Driven Design. A associação era construída por semelhanças de linguagem — excelência, clareza, colaboração — e não por uma relação que ajudasse a escolher uma prática.

Programação em pares, refatoração, integração contínua e linguagem compartilhada podem ser úteis. Nenhuma delas garante código bom ou produto valioso. Para cada prática, eu perguntaria:

qual problema ela tenta resolver;
que condição precisa existir para funcionar;
qual custo introduz;
que evidência mostrará melhora;
quando deve ser adaptada ou abandonada.

Programação em pares pode reduzir espera por revisão ou disseminar conhecimento; também pode consumir atenção sem resolver a principal restrição. Uma linguagem de domínio pode reduzir traduções ambíguas; também pode cristalizar um modelo que a equipe ainda não compreende. O nome da abordagem não decide o resultado.

Use a próxima mudança como teste de qualidade

Métricas estáticas, cobertura e complexidade podem localizar pontos para investigação. Não substituem a observação do trabalho. Uma maneira prática de avaliar design é acompanhar mudanças reais:

quanto tempo foi gasto para localizar a regra?
quantos módulos e equipes precisaram mudar?
quais testes falharam pelo motivo esperado?
quais efeitos colaterais apareceram?
o deploy exigiu intervenção excepcional?
o incidente, se ocorreu, pôde ser diagnosticado e revertido?

O histórico de mudanças fornece evidência situada. Ele não permite comparar qualquer repositório com uma escala universal, mas ajuda a equipe a descobrir onde seu próprio design cobra juros.

Eu ainda posso chamar um trecho de elegante. Só não usaria esse elogio para encerrar uma decisão. Se o código deve continuar vivo, a justificativa precisa mostrar quem conseguirá mudar, operar ou usar o sistema com menos custo e risco.