A falácia da otimização prematura

“A otimização prematura é a raiz de todo o mal”. Quantas vezes você já ouviu essa frase? Eu mesmo já disse isso aqui nesse mesmo blog e já falei essa frase para várias outras pessoas. O problema, como já apontavam os sábios budistas, é que as pessoas acabam levando as coisas ao extremo… Para alguns desenvolvedores, como a otimização é a raiz de todo o mal ela deve ser evitada a qualquer custo e ao longo dos anos o sentido da frase acabou virando simplesmente “nunca otimize seu código”.

O criador dessa frase famosa foi Tony Hoare e Donald Knuth foi o responsável por torná-la popular. O que as pessoas não param para pensar é que quando essa frase foi dita, em 1975, o contexto era completamente diferente. O que Hoare e Knuth estavam realmente falando é que os engenheiros de software da época deveriam se preocupar com outras coisas mais importantes (como um bom design de algorítmos e boas implementações desses algorítmos) antes de se preocupar com micro-otimizações como a quantidade de ciclos de CPU que um determinado comando consome. A história toda é bem interessante e recomendo a leitura completa.

Hoje em dia os tipos de software que desenvolvemos são completamente diferentes. A capacidade computacional das máquinas é diferente, as arquiteturas dos sistemas, a quantidade de usuários… Temos bancos inteiros totalmente computadorizados com milhões de transações simultâneas acontecendo e essas trasações não podem falhar ou alguém perde dinheiro em algum lugar. Temos sistemas na internet que suportam milhões de usuários trocando mensagens o tempo todo. Enfim, precisamos considerar aspectos bem diferentes.

Eoin Woods, membro da IASA, publicou um artigo sobre o que ele acredita que sejam os 10 maiores erros de arquitetura cometidos em projetos. O item número 7 é “Assumir requisitos de performance e escalabilidade”. Ele acredita que você deve começar a considerar aspectos de performance e escalabilidade desde cedo porque isso ajudará a aumentar a sua confiança de que não há nenhum bicho de sete cabeças que na última hora vai arruinar qualquer possibilidade da sua aplicação ir para produção. Os requisitos de performance de uma aplicação devem ser conhecidos, estudados e levados em consideração desde o início do desenvolvimento.

Robert Annet do Coding The Architecture cita um outro exemplo do que pode acontecer quando você assume certas informações erradas no desenvolvimento. Ele também conclui que todos os desenvolvedores devem sempre estar cientes da arquitetura de um sistema e como isso afeta o que está sendo desenvolvido. Faz muita diferença, por exempo, se uma aplicação rodará em cluster ou não.

Resumindo, eu discordo de quem diga que um software não deve ser otimizado antes mesmo de ser desenvolvido. Há casos e casos. Veja a minha situação: quando eu desenvolvo sistemas na Globo.com, como é que eu posso ignorar o fato de que o sistema será acessado por milhões de usuários? No nosso último projeto, por exemplo, uma das premissas era que o player de vídeos fosse ultra-compacto (menor quantidade de bytes possível) já que ele seria baixado por qualquer usuário que fosse ver o vídeo e não poderia afetar o carregamento da página. Se não fosse isso poderíamos acabar tendo um daqueles arquivos Flash de 2 MB que quando você acessa a página tem que esperar 2 minutos para carregar – a experiência do usuário fica um lixo.

Porém também acho que temos que tomar cuidado para não exagerar na dose. Otimizações são boas quando elas são realmente necessárias.

Já cansei de ver desenvolvedores sacrificarem o design de uma aplicação por causa de performance ou otimizações que eram completamente desnecessárias. Quando você tem requisitos de performance claros como os que eu citei acima é óbvio que você tem que levá-los em consideração. Mas a grande maioria das aplicações certamente não atende milhões de usuários nem se você somar 10 anos de acesso! Então o que acaba acontecendo é que ao invés de se preocupar com desenvolver software de qualidade, bem testado, modular e com design decente muita gente acaba desenvolvendo software desnecessariamente otimizado e difícil de entender e modificar. A não ser que você tenha requisitos não-funcionais bem claros e definidos a prioridade sempre deve ser por um bom design, código legível, extensível e esse tipo de coisa.

Otimizar cedo ou não, sempre vai ser um assunto controverso. Normalmente esse tipo de coisa envolve julgar uma série de fatores técnicos e de negócio. Concluindo, é essencial que a equipe de desenvolvimento tenha bom senso ao tomar essas decisões. Nunca otimizar ou sempre otimizar são abordagens completamente equivocadas. Como dizem os budistas, “prefira sempre o caminho do meio”.

Tags: , , , , , , , , ,

13 Responses to “A falácia da otimização prematura”

  1. Muito bom o post Guillerme, me fez ver algumas coisas desde outro ponto. Concordo com você no teus análises.

  2. Alberto says:

    Olá Guilherme,
    Concordo com você!
    Ao meu ver, é impossível descartar o requisito “otimização” no processo inicial de desenvolvimento. Nem que este seja o MÍNIMO possível, de modo que se evite re-trabalho. Você citou um ótimo exemplo: Se não levasse em conta a quantidade de requisições no início do projeto, vocês teriam re-trabalho no player. E, re-trabalho em que?! Otimizá-lo. Então, por que não otimizá-lo já no início do projeto?!

    Ótimo post. Parabéns!!

  3. wesley viana says:

    Parabens pelo artigo! Gostei muito.
    Desculpe a ignorancia mas eu nao entendo o porque que nao podemos otimizar sempre!!
    Para min a otimização deve fazer parte de um projeto de software…
    Mas so muito novo ainda…. tenho que aprender muitas coisas..
    vlw..abraços

  4. carlos moscoso says:

    Considerar previamente questoes de performance não tem nada a ver com otimização prematura. Isso é o minimo que se deve esperar de qq um que se proponha a desenvolver qq sw nao trivial.

    Isto é fornece informacoes que lhe ajudam a organizar o sistema de forma que possa ser definido ‘aonde’ no sistema e ‘quando’ no processo de desenvolvimento havera otimizacao.

  5. [...] e forte! Foi muita coincidência ter acontecido isso porque há menos de dois dias eu escreví um post sobre a necessidade constante de nos preocuparmos com otimizações o tempo todo, antes mesmo d…. Felizmente estávamos preparados para essa pancada, afinal de contas todo ano damos um duro danado [...]

  6. Rodrigo Veiga says:

    Galvão Bueno disse outro dia no “Bem amigos”: “use o bom senso na maioria das suas decisões. Pena que só aprendemos isso depois de velho.” Concordo com seu post.

  7. André Pinto says:

    Com o disse o Rodrigo, considero que “bom senso” é um pré-requisito para softwares de boa qualidade… Infelizmente bom senso não tem medida… Nada demais em exagero, nada de menos faltando, é exatamente como você falou sobre os budistas, é a sabedoria de sempre tentar seguir o “caminho do meio”… Ótimo post!

  8. PicanhaComFritas devia ler esse artigo. Pedro ficaria feliz.

  9. Sensacional ponto de vista, é bom aprender com a experiência de quem está trabalhando com um ambiente tão gigantesco.

  10. Otimização prematura é a raiz de todo o mal. ok, não de tdo mas de muito dele. Existe uma diferença grande entre otimizar prematuramente e otimizar sabendo seus requisitos e é sobre isso que Knuth fala.

    Quando você cria um site sabendo que ele deve suportar X acessos em Y tempo você deve ter isto como requisito não funcional e deve fazer seu sistema pensando nisso desde o iníncio, isso não é prematuro. Prematuro é otimizar sem saber o quanto é necessário e, pior ainda, sem ter uma métrica do seu desempenho antes e depois.

  11. O ponto é que essa frase chegou num status de mito e as pessoas passaram a achar que é ruim otimizar. O ruim é otimizar por otimizar, porque muitas vezes acaba-se perdendo tempo para ganhar milisegundos totalmente dispensáveis. Melhor gastar esse tempo se preocupando com um bom design de código.

  12. Com certeza… Nada mais lógico do que fazer a coisa certa para a ocasião certa.. Vocês precisavam de desempenho e partiram pra esse lado. Mas isso se aplica a uma porcentagem bem menor de projetos. Essa sensibilidade e a liberdade de tomar essa decisão faz esse artigo ser importante.

  13. Opa! Apesar da “idade” do post, foi bastante útil… estava escrevendo um post sobre a importância da otimização (em alguns casos) e resolvi dar uma googleada… ótimo post!

    Concordo que a otimização deve ser pensada e “pesada” para ver se o trabalho vai valer a pena e não vai prejudicar futuramente, acho que, como tu mesmo disse, o “caminho do meio” muitas vezes acaba sendo o mais viável.

    Abraço!

Leave a Reply