Encarando o desenvolvedor
Em busca da simplicidade perdida
Atribuem a Albert Einsten duas frases bastante interessantes:
· “Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction.” (“Qualquer tolo inteligente pode fazer coisas maiores, mais complexas e mais violentas. É preciso o toque de um gênio – e muita coragem – para andar na direção contrária”).
· “Everything should be made as simple as possible, but not simpler.” (“Tudo deve ser feito o mais simples possível, mas não simples demais”).
A mensagem das frases é clara: você deve procurar fazer as coisas da maneira mais simples que ainda resolve o problema. Por outro lado, complicar as coisas é muito fácil.
Einstein naturalmente se referia a teorias no ramo da Física, sua especialidade. No entanto, o ramo de software pode se beneficiar enormemente desta visão, pois cabe aos desenvolvedores, desde programadores até principalmente os arquitetos, criar a solução mais simples possível, mas que ainda atenda ao problema em questão.
No projeto de um sistema de software é muito fácil cair em armadilhas que causam um enorme aumento da complexidade de um projeto. Certas características podem parecer desejáveis à primeira vista, por exemplo:
· “Nosso aplicativo deve suportar todos os bancos de dados existentes;”
· “Teremos muita flexibilidade se usarmos uma arquitetura de N camadas” (escolha um N entre quatro e oito);
· “Devemos suportar todos os hardwares e/ou sistemas operacionais existentes em nosso usuários, inclusive os Windows 95 com 32 Mb de memória”;
· “Deveremos ter versões Web e Windows das mesmas funcionalidades.”;
· “O paradigma XPTO é a melhor invenção do mundo e devemos usá-lo sempre”. (XPTO é qualquer objeto de culto como por exemplo MVC, DataReaders ou bibliotecas de mapeamento OO-Relacional).
Todas as características acima podem ser a princípio desejáveis, mas elas sem dúvida complicam e oneram o desenvolvimento. Complicar quase sempre significa:
· Aumentar o custo;
· Aumentar o prazo de entrega;
· Exigir equipe de desenvolvimento mais qualificada e treinada
Ainda estou para conhecer um cliente que diga coisas como “O preço não importa”, “Temos todo o tempo do mundo” ou “meu objetivo é formar profissionais para que eles depois trabalhem nos meus concorrentes”. Apesar disso, encontro equipes de desenvolvimento que veladamente conspiram contra o sucesso dos projetos, ao prescrever coisas mais complicadas do que deveriam. Por exemplo, usar uma arquitetura de várias camadas ou “MVC (Model-View –Controller)” pode ser justificado em um projeto com muita gente e um ciclo de vida longo. Mas para o sorteio do amigo secreto ou para o controle de estoque da padaria da esquina, usar duas camadas com a grande produtividade dada pelo Visual Studio é muito melhor. Suportar vários bancos de dados é muito bonito, mas se 95% dos seus clientes adoram o Oracle, duvido que a complexidade adicional valha alguma coisa (é mais barato dar uma cópia Oracle de presente aos 5% que não o tem).
Devemos procurar atingir um equilíbrio entre os recursos realmente necessários, mantendo ainda a produtividade no desenvolvimento. Isto significa fazer coisas como:
· Se adaptar às ferramentas e componentes prontos, em vez de criar componentes exatamente do nosso jeito;
· Questionar seriamente a necessidade de suportar toda a gama de hardwares e softwares dos clientes;
· Desconfiar e questionar os dogmas, como “O MVC é a única boa maneira de trabalhar”.
No fundo, estamos falando a respeito de prescrever uma solução que se adapte bem ao problema, sem excessos. Às vezes é necessária alguma genialidade para fazer isso.
