Categories
Engenharia de software Refactoring

Otimização prematura

Dando uma olhada em uns projetos que estavam no meu Eclipse encontrei um projeto antigo de uma empresa que eu trabalhei. Esse projeto teve o desenvolvimento mais curto da história: 1 dia! É sério, ele acabou no mesmo dia que começou por uma série de razões.

Mais isso foi só uma pequena introdução, a história de verdade não é essa. Dê uma analisada num trecho de código deste projeto que foi desenvolvido por alguém lá da equipe (detalhe: leia atentamente o comentário):

public class Usuario implements BussinessObjectModel {
 
    protected UsuarioDTO usuarioDTO;
 
    public void login() throws Exception {
        if(this.usuarioDTO == null || this.usuarioDTO.getSenha() == null || this.usuarioDTO.getUsuario() == null) {
            throw new Exception("Erro");
        }
 
        /**
         * TODO: codigo do login.
         * ir no banco de dados, decriptar a senha, comparar
         * com o cara. logar no JMS, mandar um SMS, atualizar
         * o cache de usuarios, fazer uma chamada ejb remota
         * dizendo que o usuario entrou.
         */
    }
}

Donald Knuth já dizia que a otimização prematura é a raiz de todo o mal. Mas acho que quando ele disse isso jamais imaginaria uma otimização TÃO prematura. Em toda a minha vida esse foi um dos maiores exemplos de overdesign que eu já ví!

Repare: era o primeiro dia do projeto. Nem sabíamos direito o que precisava ser feito e o cara já decidiu que a aplicação deveria ter DTOs, JMS, EJB e cache de usuários… Sem sequer pensar no problema o programador decidiu adicionar uma complexidade enorme e desnecessária ao sistema.

Quando se desenvolve um projeto de software, a primeira coisa que deve-se fazer é atender aos requisitos funcionais do cliente da forma mais simples e rápida possível. Em seguida faz-se refactoring do código para que ele seja melhorado e no futuro possa se adaptar melhor a eventuais mudanças. E só.

Isto significa que neste momento você não se preocupa com cache, por exemplo. Se por acaso algum dia houverem problemas de performance, aí sim, pensa-se em cache, distribuição da aplicação e etc. Neste caso esta aplicação estava prevista para ter pouco mais de 10 usuários simultâneos, uma quantidade de acessoss ridícula para se pensar em otimização.

Os desenvolvedores têm uma mania horrorosa de overdesign, especialmente os desenvolvedores Java. É preciso parar de tentar adivinhar o futuro e se concentrar mais nos problemas que precisam ser resolvidos agora. Deixe os problemas do futuro para serem resolvidos no futuro!

0 replies on “Otimização prematura”

Leave a Reply

Your email address will not be published. Required fields are marked *