Otimização prematura: A origem de todo o mal

Certa vez um colega de trabalho, um grande amigo meu me disse: "Cara a otimização prematura é a origem de todo o mal". O que esse mestre quis dizer foi o seguinte: devemos pensar duas vezes ou mais antes de fazermos uma rotina mirabolante que nem a pessoa que fez vai entender depois de um mês. Sempre devemos avaliar o quão será esse ganho para tal loucura. Como mensurar isso? Acredito que com duas coisas podemos fazer isso:



Conhecimento do Negócio: Conhecendo o contexto e sabendo se teremos muitos usuários acessando a aplicação, sabendo se a rede é rápida ou não,  sabendo se esse ponto é critico ou não.



Benchmark: Esse é o cara. Vai nos dizer o quão será esse ganho, podemos ter vários tipos de benchmarks, focando em diversos pontos como:

  • Gasto de memória
  • Tempo de lock em banco e outros recursos
  • REDE
  • Grau de complexidade para tal implementação
  • Tempo
Acredito que os fatores hoje em dia mais importantes são o tempo e o grau de complexidade. Não tem sentido optar por uma implementação mais complexa com ganhos insignificantes de performance, nesse caso se dá preferência para a elegância e a manutenibilidade.



Isso justifica a frase: "Cara a otimização prematura é a origem de todo o mal", logo é muito importante fazer o benchmark para ver o quão é esse ganho e o quão será necessário para aquele ponto da aplicação. Já vi muitos casos que o ganho foi tão insignificante que fazer tal algoritmo "mais rápido" além de trazer poucos benefícios em termos de performance agregou uma complexidade desnecessária a aplicação.



Esse conceito eu tenho usado seguido no meu trabalho. Não existe receita de bolo, cada caso é um caso, mas levando em conta essas informações acima citadas acredito que será mais fácil o seu trabalho. :)




Powered by ScribeFire.

Popular posts from this blog

C Unit Testing with Check

Having fun with Zig Language

HMAC in Java