Complexidade inútil: o preço do «por precaução»

A complexidade inútil quase nunca nasce de má intenção. Nasce de uma boa: «caso precisemos de várias bases de dados», «caso liguemos outro fornecedor», «caso a equipa cresça». Cada «por precaução» acrescenta uma camada. E cada camada paga-se — não no dia em que se escreve, mas todos os dias seguintes.

O custo é diário, o benefício é hipotético

Uma abstração «por precaução» lê-se em cada debug, contorna-se em cada evolução, explica-se em cada chegada à equipa. O cenário que ela prepara, esse, muitas vezes nunca chega — ou chega com uma forma que a abstração não previu, e é preciso desfazê-la na mesma.

Três perguntas para filtrar

Perante uma camada existente ou uma que está prestes a escrever: um caso real usa-a hoje? Se a retirasse, o que partiria concretamente? A pessoa que ler este código daqui a um ano perceberá porque existe sem que lho expliquem? Três «não» = uma camada a retirar.

A sobriedade não é ingenuidade

Não se trata de escrever código simplista que ignora necessidades reais. Trata-se de esperar que a necessidade exista antes de a pagar. Um sistema sóbrio pode acolher complexidade — quando justificada por um caso real, integra-se de forma limpa. O que apodrece é a complexidade especulativa: estrutura o código à volta de cenários imaginários.