Série de artigos sobre o livro As Regras da programação de Chris Zimmerman. O livro trata de 21 regras que ajudam programadores a criarem códigos melhores. Falarei um pouco sobre cada regra do meu ponto de vista trazendo alguns exemplos e opiniões sobre o livro, com o objetivo principal de consolidar e compartilhar o conhecimento.

Alguns programadores são verdadeiros fãs da otimização, geralmente isso tem a ver com fazer um sistema ser executado com mais rapidez. O motivo para isso é simples, é fácil medir o sucesso de uma tarefa como essa.

"Devemos nos esquecer de pequenas eficiências, digamos, cerca de 97% do tempo a otimização prematura é a reais de todo o mal." - Donald Knuth, 1974

É instintivo que os programadores se preocupem com os recursos, seja tempo, armazenamento ou largura de banda - e isso pode levar a tentativas de resolver problemas de desempenho antes que eles surjam.

Lições da otimização

A primeira lição da otimização é: não otimize. Simplifique o código o máximo possível, não se preocupe com a rapidez dele.

A segunda lição complementa a primeira: é fácil tornar um código simples rápido. Provavelmente na primeira vez que você examinar esse código vai entender claramente o que precisa ser otimizado. O autor ainda complementa dizendo que se você nunca otimizou algum trecho do código, pode torná-lo de 5 a 10 vezes mais rápido sem muito trabalho.

A terceira lição é interessante: não se preocupe se cometer erros, porque não haverá erros que você não possa corrigir. Erros complexos (que atrapalham os desempenho) não esperam para aparecer, então não se preocupe com isso. Eles serão óbvios.

5 etapas para otimização

Etapa 1: meça e atribua o tempo do processador

Meça quanto do tempo do processador está sendo gasto e atribua-o ás funções, aos objetos ou ao que for conveniente. Identifique o que está forçando seu navegador.

Etapa 2: verifique se não é um bug

É muito comum descobrirmos que o que parece um problema no desempenho na verdade é um bug. Se esforce para encontrá-los.

Etapa 3: avalie seus dados

A maioria das otimizações explora algum aspecto dos dados ou de como eles estão sendo usados. Você não conseguirá tomar boas decisões sobre otimização sem conhecer totalmente a forma de seus dados. Procure de onde vem o problema.

Etapa 4: planeje e crie um protótipo

Não comece a trabalhar em uma otimização até saber que ela faz parte de um plano que pode ser bem sucedido. Procure uma oportunidade de prototipar sua otimização. Crie uma versão "perfeita" para testar.

Etapa 5: otimize e repita

Após terminar as 4 primeiras etapas, você poderá começar a pensar em otimização. Já terá desenvolvido uma noção de quanto custarão várias partes do código, de acordo com o nível de lógica envolvido e com o volume de memória que será acessado. Talvez parte desse código ou do acesso à memória possa ser simplificado ou ignorado. Se não houver maneira simples de acelerar o código, procure algo que você possa explorar nos dados.

Não otimize de imediato, faça um plano.

Conclusão

Não é fazendo a mesma coisa mais rápido que melhoramos o desempenho. A maneira de tornar o código mais rápido é fazendo menos. Descubra o que o código está fazendo que não precisaria ser feito ou o que ele está fazendo várias vezes que poderia ser feito uma vez. Elimine esses trechos de código e tudo ficará mais rápido.

O autor conclui dizendo: "Confie nas lições da otimização. Escreva código simples e claro e esteja certo de que soluções aparecerão para qualquer problema de desempenho que você encontrar."