Perfeição não é over-engineering: é exigência de requisitos claros

Perfeição e over-engineering

O texto distingue perfeição de over-engineering, conceitos que, segundo o autor, foram silenciosamente confundidos pela indústria. A cautela com soluções “perfeitas” faz sentido porque o over-engineering pode consumir equipes e acrescentar complexidade, mas o problema não é se importar demais ou construir algo bom demais. Over-engineering é resolver o problema errado - muitas vezes com boas intenções e com uma quantidade crescente de complexidade incidental.

O autor defende que uma solução perfeita pode existir quando os requisitos são suficientemente claros. Ao colocar sobre a mesa todas as restrições relevantes, pode-se chegar a uma única solução possível: ela será perfeita não por ser universalmente superior, mas por ser a única que se encaixa naquele conjunto de necessidades. Por isso, pessoas que enfrentam o mesmo tipo de problema podem escolher soluções diferentes. Em um projeto novo, por exemplo, serverless e Python podem ser escolhas adequadas para alguém que valoriza a ausência de compilação e o envio direto de arquivos para o Lambda, mas inadequadas para quem não conhece Python ou precisa priorizar desempenho. Da mesma forma, Django e Flask podem produzir resultados semelhantes em uma aplicação web, embora tenham filosofias diferentes. Requisitos mais específicos e restrições mais rígidas orientam a escolha.

Sistemas também são produtos

A causa do over-engineering, afirma o texto, quase sempre está nos requisitos - entendidos no sentido de produto, e não apenas no sentido técnico. Bibliotecas, APIs e ferramentas internas não estão fora da lógica de produto: têm usuários, e esses usuários têm necessidades que precisam ser compreendidas. Dependendo dessas necessidades, a melhor resposta pode ser um serviço, uma biblioteca ou um pacote, em vez de uma API HTTP. A forma da solução só se torna evidente quando o sistema é tratado como um produto e seus requisitos são definidos de maneira honesta.

O custo de resolver problemas inexistentes

Um sinal claro de over-engineering aparece quando as justificativas para a arquitetura não resistem à pergunta “por que isso foi construído dessa maneira?”. O exemplo apresentado é uma equipe de três pessoas que mantém cinco microsserviços dentro do mesmo domínio, embora os serviços compartilhem dados. A divisão pode ter sido a resposta correta para problemas de escala ou de autonomia de equipes, mas esses problemas talvez nunca tenham existido naquele contexto.

A separação substitui referências rígidas e chaves estrangeiras do banco de dados por identificadores soltos. Com isso, a integridade dos dados diminui: um serviço pode apagar um registro sem que outro saiba, deixando uma referência inválida que só será descoberta mais tarde. Em troca, a equipe obtém implantações independentes, mas talvez sem que isso resolvesse uma dificuldade real. O custo inclui inconsistência distribuída, sobrecarga operacional e um sistema que tenta resolver vários problemas parcialmente, além de introduzir outros que não existiriam em uma arquitetura mais simples.

Requisitos como diagnóstico

A conclusão é que over-engineering é uma falha na coleta de requisitos: a engenharia pode ser cuidadosa e competente, mas estar orientada por necessidades incorretas. A perfeição não é o inimigo; requisitos ambíguos são. Quando todas as restrições relevantes são esclarecidas, a solução adequada deixa de ser uma fantasia e pode se tornar a única alternativa compatível com o problema real.