Mature optimization versus Premature optimization

Aqui na Riopro, volta e meia nos vemos discutindo e ouvindo a seguinte frase: “mas isso é otimização prematura, deixa ver se isso realmente vai ser um gargalo”. É, isso é muito verdade. A preocupação extrema em otimizar e fazer tudo ficar muito rápido, muitas vezes dá trabalho e o ganho real é ínfimo. Além disso, pode trazer prejuízos reais, como tornar seu sistema menos testável e menos legível.

“Forget about small efficiencies, say about 97% of the time:
premature optimization is the root of all evil.”-Donald Knuth.

Ok, mas experiência tem que contar para alguma coisa, não é? Foi aí que lendo o ótimo artigo Scaling Rails, me deparei com a expressão que cabe corretamente para alguns problemas: Mature Optimization. No artigo, que é ótimo como um todo, ele fala uma coisa muito correta (tradução bem livre): “quando o custo da precaução for bem baixo ou, às vezes, dar o mesmo trabalho, por que não resolver logo”. E aí acrescento o comentário feito no primeiro parágrafo que diz que além do tempo, devemos também ponderar se estaremos comprometendo os testes o a leitura do fonte.

Isso, ao menos para mim, vale para gargalos clássicos como e-mail. Sei que podemos mandar um e-mail durante a requisição. Mas isso obviamente vai gerar um custo mesmo que só tenhamos 1 só usuário (ou você acha que mandamos um e-mail em menos de 2 segundos). Ou seja, faça o trabalho certo logo e coloque esse e-mail de forma assíncrona!

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *