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!